python-django update to Django-1.6

[Stephen Gallagher]

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

On 02/21/2014 02:41 PM, Stephen Gallagher wrote:
> On 02/21/2014 02:06 PM, Stephen Gallagher wrote:
>> 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...
> 
> 
> 
> Ok, so it turns out that Python Eggs are a lot smarter than I gave 
> them credit for. If you turn your attention to 
> http://fedoraproject.org/wiki/Packaging:Python_Eggs, you will find 
> that it describes quite well how to modify a Python compat package 
> (such as python-django14) to be parallel-installable with the
> newer package.
> 
> Toshio has been testing this implementation with ReviewBoard
> 1.7.21 (Django 1.4) and ReviewBoard 2.0beta2 (Django 1.5) this
> afternoon and so far it appears to work properly, with both
> python-django14 and python-django installed on the same system.
> 
> We need to do some more testing to be certain, but it seems this
> may be the easy way forward. Hooray!
> 


So, as it turns out, this seems to be working flawlessly!

I had to make two minor changes to the ReviewBoard package to support
the parallel-installable version of python-django14. One I have
submitted back upstream (https://reviews.reviewboard.org/r/5520/diff/)
and the other was Fedora-specific (I needed to be less total about the
modifications I made to the requires.txt in the ReviewBoard python egg).

I suspect we'll need to make similar modifications to other Django
apps in Fedora to support this, but it's very low-impact, so I'd
suggest that this is clearly the approach we want to take.

Toshio is going to send out the diff he created of the python-django14
package to this list as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMHxaMACgkQeiVVYja6o6OKIQCdGvnqM5GPGtfFxlCqRL4i7+/9
Wt8AoIZnVl140r4aQZksVXcFga3uQQcO
=T3Qx
-----END PGP SIGNATURE-----