Hi Stephen,
Em Fri, 06 Nov 2015 20:29:34 +0000
"Finucane, Stephen" <stephen.finuc...@intel.com> escreveu:
> On 06 Nov 16:38, Mauro Carvalho Chehab wrote:
> > Em Fri, 06 Nov 2015 19:02:31 +0100
> > Johannes Berg <johan...@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-t...@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 <la...@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
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
