----- 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
