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

Mauro Carvalho Chehab mchehab at osg.samsung.com
Sat Nov 7 05:38:17 AEDT 2015

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.

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.

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

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


More information about the Patchwork mailing list