-----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----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
