Django-1.5 for F19

[Bohuslav Kabrda]

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu 11 Apr 2013 02:56:16 AM EDT, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >> 
> >> On 04/11/2013 04:27 AM, Toshio Kuratomi wrote:
> >>> On Wed, Apr 10, 2013 at 07:53:28AM -0400, Stephen Gallagher
> >>> wrote:
> >>>> 2) The python-django14 package should add: Obsoletes:
> >>>> python-django < 1.5 Conflicts: python-django >= 1.5
> >> 
> >>>> Adding Toshio to the CC list explicitly to check my logic :)
> >>> 
> >>> Conflicts will run afoul of the guidelines.  I thought these
> >>> were parallel installable?
> >>> 
> >>> -Toshio
> >>> 
> >> No, they're not installable in parallel, they're conflicting by
> >> using the same files.
> >> 
> >> So I think, python-django14 should Obsoletes: python-django < 1.5
> >>  and since the packages are conflicting, we can avoid
> >> Conflicts:....
> >> 
> >> Right?
> > 
> > I think that the problem is that this would allow you to install
> > both django 1.4 and django 1.5 in the same way as you install with
> > easy_install or pip - e.g. non-parallel installs, that both have
> > files in %{python_sitelib}/django. So they either have to conflict
> > or (and I'd prefer this) we should rather concentrate our efforts
> > on helping upstreams migrate do Django 1.5. Or we could possibly
> > provide django14 as parallel installable, which would however
> > require patching all the depending packages.
> > 
> 
> 
> Not all upstreams are willing to migrate to Django 1.5. For an
> example, here's the feedback I got from ReviewBoard:
> https://groups.google.com/forum/?fromgroups=#!topic/reviewboard-dev/QOMtUjfbJ0g
> 
> Specifically note the part:
> "The Django guys keep making decisions to deprecate things and change
> things that severely impact us and make it really hard to migrate to.
> Things like their recent changes to how user profiles work (they're
> getting rid of them and all API around them). It's fixable, but we end
> up jumping through hoops just to change things for the sake of
> changing things."
> 
> 
> The core of the problem is that Django upstream has absolutely zero
> understanding of how to produce a stable development infrastructure
> and zero interest in maintaining more than two versions simultaneously
> (even for security updates).
> 

I wouldn't take that as far as saying "zero understanding". They break things, yes, but they have pretty good policies for deprecating/changing things [1], so you know almost 2 of their release cycles (=18 months) in advance, that something's going to be changed. There are exceptions, sure, but generally I think Django upstreams can get prepared soon enough. (That doesn't mean I'm saying that ReviewBoard did a bad job, they didn't. They have a large codebase and don't like when many things change, that's understandable - although they could have seen this coming.)

> What we really need to do is start trying to educate the Django
> upstream about long-term supportability guarantees and product
> lifecycles that other projects can rely upon.
> 
> Perhaps we can point them at the Mozilla Foundation's ESR releases as
> an example. I don't have any contacts in the Django upstream, but
> maybe Matthias does?

I agree that this would be a good start. We should also keep this effort balanced with the other one - helping other Django upstreams understanding why Django is developed this way and helping them migrate.

[1] https://docs.djangoproject.com/en/1.5/internals/release-process/#minor-releases

-- 
Regards,
Bohuslav "Slavek" Kabrda.