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

[Mauro Carvalho Chehab]

Hi Stephen,

Em Fri, 06 Nov 2015 20:29:34 +0000
"Finucane, Stephen" <stephen.finucane at intel.com> escreveu:

> 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.

We're upgrading our servers to the latest Debian LTS (version 8.2).

It comes with Django 1.7.7, but only for Python 3:
	$ dpkg -p python3-django
	Package: python3-django
	Priority: optional
	Section: python
	Installed-Size: 15654
	Maintainer: Debian Python Modules Team <python-modules-team at lists.alioth.debian.org>
	Architecture: all
	Source: python-django
	Version: 1.7-2~bpo70+1
	Depends: python3 (>= 3.2.3-3~), python-django-common (= 1.7-2~bpo70+1)

The latest version of Django for Python 2.7 is 1.4.5:
	$ dpkg -p python-django
	Package: python-django
	Priority: optional
	Section: python
	Installed-Size: 51004
	Maintainer: Chris Lamb <lamby at debian.org>
	Architecture: all
	Version: 1.4.5-1+deb7u8
	Depends: python (>= 2.6.6-7~), python (<< 2.8)

It seems, however, that patchwork doesn't work yet with Python 3,
right? If so, we should stick with patchwork running with Django 1.4,
or make patchwork to work also with python3.

> 
> > > 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 ported the autodelegation patches to the latest version of patchwork,
but I'm unable to test (because of the conflict mismatch between python
and django).

If you want, I may submit those untested patches, in the hope that
someone would test them before applying.

> 
> 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