[PATCH v2 0/4] Remove support for Django 1.6

[Finucane, Stephen]

On 06 Nov 16:38, Mauro Carvalho Chehab wrote:
> Em Fri, 06 Nov 2015 19:02:31 +0100
> Johannes Berg <johannes at sipsolutions.net> escreveu:
> 
> > > If not, then we're going to have (a) roll back the Django 1.6 removal
> > > patches, (b) put together a roadmap for future Django version support and
> > > (c) avoid using non-stdlib libraries (outside of Django) going forward. As
> > > Damien pointed out, these actions come with some rather severe costs for
> > > us so I'd like to be absolutely certain of this before I take any actions.
> > > 
> > 
> > There's the obvious alternative of not caring about LTS installations
> > like kernel.org and simply continue developing the software as is
> > against upstream. *Eventually*, it's going to get to the users, perhaps
> > not as fast as the users (like me) would like.

I see where you're coming from, but many of the instances I care about -
kernel.org, dpdk.org and ozlabs.org, to name a few - are likely to be affected
by this. There are also many versions of patchwork that I don't personally use
but that are no doubt useful to many, many people. I would rather undertake the
extra effort with testing here and deal with the hassle of maintaining manual
migrations than completely rule out these sites getting upgraded any time soon
(if at all).

tl;dr: A harder to develop, but usable patchwork >>> a patchwork that no one
       can deploy

> Well, for that to happen, we would need to either have a tarball or
> (highly preferred) a branch with a patchwork version for us to pull
> once we hit the requirements for running such version.

I'm going to add stable branches as soon as we hit v2.0.0, which should be done
as soon as the series support is merged along with UI components and XML-RPC
endpoints (sadly necessary until we get a REST API*). I'm also putting together
a plan for maintaining Django support going forward. I'll send out an update on
how I envision both will work later today or over the weekend.

> Also, that would mean that we'll be running our own fork of patchwork,
> as we add some features that we may need to improve our workflow.
> 
> Right now, our tree is based on this changeset:
> 	c4e5d96 docs: We're targetting django 1.5 now
> 
> But we have a bunch of patches we did our own on the top of that,
> in order to have some features we need on our workflow (including
> patches that restore backward compatibility with Django 1.4, and
> a few fixup patches that I likely picked from upstream):
> 
> $ git lg origin/master..
> 3b2b253 (HEAD, master) Merge remote branch 'origin/django-1.4'
> 56e7b71 Read X-Patchwork-Delegate:
> 4876657 Restore compatibility with Django < 1.5
> 5edb8c3 Merge remote branch 'origin/master'
> fce6d9e Report if a patch is delagated and to whom
> 2db2a1a parser: Use full regexps for delegation rules paths
> ac66486 models: Add priority field to DelegationRule
> 7a4f2a6 forms: Allow the delegate field to keep its current value
> 42dca6c parser: Set the delegate using Delegation rules
> 8ecf299 parser: Add patch_get_filenames()
> 74062cc models: Add DelegationRule object
> fdd7e24 docs: Update PostgreSQL database configuration example
> f61ec38 Improve parsemail error handling logic a little bit
> b6fdf69 Add media-specific comments to patchwork's template.
> 7fa02d0 Linuxtv-specific setup
> 51000a4 (origin/django-1.4) requestcontext: Initialise 'messages' context var
> e36dbad settings: Use new class for auth context processor
> e5dbc32 settings: Use class-based template loading API

I'd love to get a few of these patches, should you have the time/inclination
to release them (either via patches or a public Git). I won't re-add Django
1.4/1.5 support myself, but if someone has the work done and it's zero-effort
to integrate them then I'd certainly consider this.

> > And I'm not suggesting at all that you should consider "LTS distro"
> > support of huge importance.
> 
> I guess it is: at least every time a new requirement is added, patchwork
> should have a "stable" branch with the older requirements. Otherwise,
> big projects that run on LTS severs will never be able to benefit from
> the changes done upstream.
> 
> > I think in a way part of the problem is that your user audience is also
> > developers (in a different space), so we users might be interested in
> > working on tools improvements ourselves (like the regex auto-delegation 
> > feature that Mauro/Laurent have), but there's less incentive to do that
> > if we can't actually benefit from it in a fairly short time frame (and
> > we're more likely to script our way around it instead.)
> 
> True. The autodelegation patches were not sent upstream because upstream
> has changed the Django's requirements, and we weren't unable to rebase
> to the newer version, due to the LTS requirements.

I think "sysadmins" (excuse the generic term) are a big, if not the biggest,
part of the audience here. As I said above, a patchwork that no one can
deploy is of no benefit to anyone. It's going to make our life harder and
doubt everyone will be happy with it, but we need to make patchwork as widely
available as possible.

Cheers,
Stephen