<tt><font size=2>> From: sgallagh@redhat.com</font></tt>
<br><tt><font size=2>> To: <devel@lists.fedoraproject.org></font></tt>
<br><tt><font size=2>> Date: 02/21/2014 14:41</font></tt>
<br><tt><font size=2>> Subject: Re: python-django update to Django-1.6</font></tt>
<br><tt><font size=2>> Sent by: devel-bounces@lists.fedoraproject.org</font></tt>
<br><tt><font size=2>> <br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
> <br>
> On 02/21/2014 02:06 PM, Stephen Gallagher wrote:<br>
> > On 02/21/2014 01:58 PM, Simo Sorce wrote:<br>
> >> On Fri, 2014-02-21 at 13:28 -0500, Stephen Gallagher wrote:<br>
> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1<br>
> >>> <br>
> >>> On 02/21/2014 01:14 PM, Matthias Runge wrote:<br>
> >>>> On Fri, Feb 21, 2014 at 10:36:24AM -0500, Simo Sorce
wrote:<br>
> >>>>> +1 I still have an application that is slowly
moving to<br>
> >>>>> 1.5 but not there yet and it is painful to have
to keep an<br>
> >>>>> older Fedora Version running just because of
that.<br>
> >>>> I hear you! My current plan would be, to provide
at least a <br>
> >>>> python-django-1.5 version.<br>
> >>> <br>
> >>> <br>
> >>> My suggestion would actually be that Fedora releases
should<br>
> >>> ship ONLY with the latest supported upstream version
and should<br>
> >>> be allowed to pick up the next one during its supported<br>
> >>> lifecycle.<br>
> > <br>
> >> This may not be possible, as it depends how long after upstream
<br>
> >> release fedora is cut. In django case there is a long tail
of <br>
> >> applications that needs porting so if you force 'lastest'
you<br>
> >> would end up breaking a number of packages that do not support<br>
> >> latest yet.<br>
> > <br>
> >>> So for F21, we'd ship with only Django 1.6 support and
would<br>
> >>> pick up 1.7 when it arrives. The problem with shipping
F21 with<br>
> >>> 1.5 and 1.6 support is that when 1.7 lands (and upstream
drops<br>
> >>> all support for 1.5 at that time), we're stuck with only
two <br>
> >>> choices:<br>
> >>> <br>
> >>> 1) Attempt to assume the maintenance burden on the abandoned
<br>
> >>> branch. 2) Retire it from Fedora and strand anyone who
has<br>
> >>> been using it.<br>
> >>> <br>
> >>> Neither of these are good choices.<br>
> > <br>
> >> Honestly I do not think we have good choices. Upstream simply<br>
> >> moves too fast and causes all these issues to start with.
We can<br>
> >> only try to do damage control.<br>
> > <br>
> >>> Upstream Django has a nine-month release cycle, meaning
that <br>
> >>> each version is only supported for 18 months. This is<br>
> >>> perfectly acceptable for Fedora, as long as we don't
ship with<br>
> >>> a version that's already into its 17th month...<br>
> > <br>
> >> It would be perfectly acceptable if the whole ecosystem moved
at <br>
> >> that speed, but that is not the case, which is why I find<br>
> >> django's policy annoying.<br>
> > <br>
> >>> Now, EPEL on the other hand gets even more troubling,
since it <br>
> >>> has a much longer lifecycle...<br>
> >>> <br>
> >>> <br>
> >>> One other approach we might consider (though this is
not <br>
> >>> currently an FPC-approved solution) would be to package
Django<br>
> >>> as a software collection and all Django apps would depend
on<br>
> >>> the appropriate collection. Since the 1.5 and 1.6 collections<br>
> >>> could coexist on the system, when an app updates to support
the<br>
> >>> new one, it needs only change its Requires: to use the
newer<br>
> >>> Django collection and it should Just Work(TM).<br>
> > <br>
> >> I think django should be moved completely out of the base
distro <br>
> >> and be only a collection, keeping it in the distro is painful<br>
> >> and never satisfies everyone.<br>
> > <br>
> >>> Now, that's forbidden by policy at this point, but maybe
we<br>
> >>> could at least experiment with this in a COPR repository
for<br>
> >>> the time being. It would be nice to be able to come to
the FPC<br>
> >>> with a working setup and ask them to bless it for us,
rather<br>
> >>> than presenting them a problem statement and hoping that
they<br>
> >>> can find a consensus.<br>
> > <br>
> >> Sounds like a decent plan :)<br>
> > <br>
> > <br>
> > <br>
> > I'm having a parallel conversation about this with Toshio on
<br>
> > #fedora-devel right now. He believes it may be possible to get<br>
> > Django to be parallel-installable on the base system without
SCLs<br>
> > and is running some tests. If he can make this work, that would<br>
> > make our lives a lot easier. More to come, stay tuned...<br>
> > <br>
> > <br>
> <br>
> Ok, so it turns out that Python Eggs are a lot smarter than I gave<br>
> them credit for. If you turn your attention to<br>
> </font></tt><a href=http://fedoraproject.org/wiki/Packaging:Python_Eggs><tt><font size=2>http://fedoraproject.org/wiki/Packaging:Python_Eggs</font></tt></a><tt><font size=2>,
you will find<br>
> that it describes quite well how to modify a Python compat package<br>
> (such as python-django14) to be parallel-installable with the newer<br>
> package.<br>
> <br>
> Toshio has been testing this implementation with ReviewBoard 1.7.21<br>
> (Django 1.4) and ReviewBoard 2.0beta2 (Django 1.5) this afternoon
and<br>
> so far it appears to work properly, with both python-django14 and<br>
> python-django installed on the same system.<br>
> <br>
> We need to do some more testing to be certain, but it seems this may<br>
> be the easy way forward. Hooray!<br>
</font></tt>
<br>
<br><font size=2 face="sans-serif">I love you guys! It's always a
treat to read how smart folks take something and just make it better like
this. I wish I had time to contribute more, but just wanted to say
thanks to all who are always working on these kind of goals. It's
my favorite thing about Fedora and FOSS in general.</font>
<br><font size=2 face="sans-serif"><br>
--<br>
John Florian</font>
<br>