-----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... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMHo6kACgkQeiVVYja6o6P5NQCfVH0gyT10aYqOhRNKnv+1vRxo Ll0An2pNZZkdDcEF9dquuxlyn6pMO6f0 =+owm -----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
