python-django update to Django-1.6

Fri Feb 21 19:06:17 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/21/2014 01:58 PM, Simo Sorce wrote:
> 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 :)
> 

I'm having a parallel conversation about this with Toshio on
#fedora-devel right now. He believes it may be possible to get Django
to be parallel-installable on the base system without SCLs and is
running some tests. If he can make this work, that would make our
lives a lot easier. More to come, stay tuned...