Re: Django-1.5 for F19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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).

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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFmsxYACgkQeiVVYja6o6M3XwCgpBFRHo1DD9infeSqxq3ud/AK
ViQAn1gXa4vcu8F0MsXVuEvTn9pyki8Y
=J3mc
-----END PGP SIGNATURE-----
-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux