python-django update to Django-1.6

Simo Sorce simo at redhat.com
Fri Feb 21 18:58:32 UTC 2014


On Fri, 2014-02-21 at 13:28 -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02/21/2014 01:14 PM, Matthias Runge wrote:
> > On Fri, Feb 21, 2014 at 10:36:24AM -0500, Simo Sorce wrote:
> >> +1 I still have an application that is slowly moving to 1.5 but
> >> not there yet and it is painful to have to keep an older Fedora
> >> Version running just because of that.
> > I hear you! My current plan would be, to provide at least a 
> > python-django-1.5 version.
> 
> 
> My suggestion would actually be that Fedora releases should ship ONLY
> with the latest supported upstream version and should be allowed to
> pick up the next one during its supported lifecycle.

This may not be possible, as it depends how long after upstream release
fedora is cut. In django case there is a long tail of applications that
needs porting so if you force 'lastest' you would end up breaking a
number of packages that do not support latest yet.

> So for F21, we'd ship with only Django 1.6 support and would pick up
> 1.7 when it arrives. The problem with shipping F21 with 1.5 and 1.6
> support is that when 1.7 lands (and upstream drops all support for 1.5
> at that time), we're stuck with only two choices:
> 
> 1) Attempt to assume the maintenance burden on the abandoned branch.
> 2) Retire it from Fedora and strand anyone who has been using it.
> 
> Neither of these are good choices.

Honestly I do not think we have good choices. Upstream simply moves too
fast and causes all these issues to start with. We can only try to do
damage control.

> Upstream Django has a nine-month release cycle, meaning that each
> version is only supported for 18 months. This is perfectly acceptable
> for Fedora, as long as we don't ship with a version that's already
> into its 17th month...

It would be perfectly acceptable if the whole ecosystem moved at that
speed, but that is not the case, which is why I find django's policy
annoying.

> Now, EPEL on the other hand gets even more troubling, since it has a
> much longer lifecycle...
> 
> 
> One other approach we might consider (though this is not currently an
> FPC-approved solution) would be to package Django as a software
> collection and all Django apps would depend on the appropriate
> collection. Since the 1.5 and 1.6 collections could coexist on the
> system, when an app updates to support the new one, it needs only
> change its Requires: to use the newer Django collection and it should
> Just Work(TM).

I think django should be moved completely out of the base distro and be
only a collection, keeping it in the distro is painful and never
satisfies everyone.

> Now, that's forbidden by policy at this point, but maybe we could at
> least experiment with this in a COPR repository for the time being. It
> would be nice to be able to come to the FPC with a working setup and
> ask them to bless it for us, rather than presenting them a problem
> statement and hoping that they can find a consensus.

Sounds like a decent plan :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list