Django-1.5 build

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/2013 11:13 AM, Matthias Runge wrote:
> On 02/28/2013 02:16 PM, Stephen Gallagher wrote:
>> On Thu 28 Feb 2013 06:58:36 AM EST, Matthias Runge wrote:
>>> Dear list,
> 
>>> Django 1.5 was released about two days ago. I'd like to push a 
>>> build to rawhide, but I assume, that will break many dependent 
>>> packages.
> 
>>> The plan is, to delay the push, until other packages are
>>> fixed, or to push in about 14 days.
> 
>>> I have a scratch-build build ready, one might to try, it
>>> should install cleanly e.g. on Fedora 18.
> 
>>> http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm
>
>>> 
>>> 
>> How many Django-based packages are we talking about? Should we
>> be considering putting things together in a side tag before
>> landing in Rawhide?
> 
> Well, looking at my list of ~40 python-django packages, I know by 
> coincidence just a single package to be compatible with Django-1.5
> 

That speaks well towards my suggestion of splitting the source
packages, then.

>> Looking at the release notes[1], there is a sizeable number of 
>> backwards-incompatible changes present in this new version. I 
>> think it's going to bite us if we force it straight into Rawhide
>> at this point. Given the way that Django tends to operate 
>> (backwards-incompatible releases about every six months with
>> only the current and previous release supported for bugfixes and 
>> security), I'm wondering if we shouldn't just drop the 
>> 'python-django' package entirely and go with 'python-django14', 
>> 'python-django15', etc. from here until eternity, retiring 
>> unsupported versions only between upstream releases. This is a 
>> policy that would probably also work acceptably for EPEL (CCed).
> That seems to be a good proposal for me. Review request is
> here[1], based on the current python-django package. Shouldn't be
> an issue. For EPEL, we have the Django14 package. This shouldn't
> change there, but we can think about introducing provides:
> python-django14 there.
> 

I'm unclear (based on this and your other reply to the list which came
in about ten minutes later). Are you agreed that we should drop the
'python-django' package and go to versioned ones exclusively, or are
you proposing that we would eventually turn python-django15 into
python-django (e.g. when python-django16 arrives).

I don't like that idea, personally. I think it's probably a better
idea to just keep the strictly-versioned names in Fedora so that
packagers can migrate when *they* are ready to do so. Then they will
only be forced into it when python-django15 eventually gets removed
from the distro (because upstream no longer maintains it).

> Also, IMHO the number of incompatible changes became less and less 
> disruptive in the past, and I see this as maturing of the project.
> 

Sure, I don't disagree. But until the number of incompatible changes
is *zero*, we need to handle things appropriately.


>> Also, Django 1.5's release notes[2] indicate that it now has 
>> support for Python 3.2 and later. I'd strongly recommend that we 
>> should be dual-building python3-django15 as well here.
> 
> Yes, I was thinking about a python3-django feature for F20, as
> it's absolutely too late for this as a feature for F19, right?
> 

It's up to you whether you want to release it in F19 or not. It's not
a problem, traditionally (especially since it's basically a
leaf-node). I'd say that if you want to do the work in F19, go ahead.
We can just leave it there quietly in F19 and announce in F20 if you
prefer.

In general, I like the idea of having it available in Rawhide sooner
rather than later. It gives other packagers more time to prep it.

> As there is at least /usr/bin/django-admin provided by the package,
> we should decide, if that should be coming from the python3
> package, if the python3 version should carry a python3 (or just a
> 3) in it's name, or what to do else.
> 

That's an interesting question... perhaps we should have both
sub-packages install into %{_libexec} and use the alternatives system
to decide which one gets /usr/bin/django-admin. That's probably a good
question for packaging at lists.fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEvicsACgkQeiVVYja6o6MSwACeIutdMVXbdHw/+pIYSiqO/Ux7
O4oAoKL/fW1ZsvsXijvWGfbe4iSEaVAZ
=uJJ3
-----END PGP SIGNATURE-----