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 :) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
