-----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 (
)
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-----