Django-1.5 build

[Matthias Runge]

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-...
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Stephen Gallagher]

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

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-...
How many Django-based packages are we talking about? Should we be
considering putting things together in a side tag before landing in
Rawhide?

Also, I know at least Review Board is incompatible with 1.5 at this
time. They're planning to have a 1.5-compatible release sometime in the
next month or so.

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

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.

[1]
https://docs.djangoproject.com/en/1.5/releases/1.5/#backwards-incompatibl...
[2] https://docs.djangoproject.com/en/1.5/releases/1.5/#python-3-support
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEvWJcACgkQeiVVYja6o6OJNQCdGDMix23UbQaBt54/8qm2pZHH
> PCMAoIwUySlkccFtXorJH2iJQcAzdtLf
> =RXfG
> -----END PGP SIGNATURE-----

[Michael Cronenworth]

Stephen Gallagher wrote:
>  How many Django-based packages are we talking about? Should we be
>  considering putting things together in a side tag before landing in
>  Rawhide? 
Add cobbler to the list. Cobbler was forgotten about in Fedora 17 and an
update to support Django in Fedora 17 is /still/ sitting in updates-testing.

Please make sure all dependent packages have made themselves compatible
before you push.

[Rahul Sundaram]

Hi


On Thu, Feb 28, 2013 at 6:58 AM, 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.
>  
You should introduce a python-django15 package instead and let dependent
packages slowly move over.   We cannot handle this within a single release
timeframe.   Every release introduces incompatibilities and upstream
projects aren't willing to deal with too many Django versions at a time and
move forward slowly.

Rahul

[Matthias Runge]

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

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

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

Also, IMHO the number of incompatible changes became less and less
disruptive in the past, and I see this as maturing of the project.
>  
>  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?

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.


Matthias


[1] https://bugzilla.redhat.com/show_bug.cgi?id=916676
- -- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRL4IzAAoJEOnz8qQwcaIWygcIAJ+7J4B+nabmV4eSaMguNmXM
> F81PcSf/HjLQQSeFi2n3CFfM+ZcYnTbBJ+rDKXmIUDLGRRu6tgtOduX8s4x9oQto
> 4BshL7njsBK3fEKUFJYY2xoJyEC8fmZbzaQ5uZyM1Tqa88vjo/SSYPluiRUWrtL8
> pTt3U/7HN3bU/8byzxLyWxtyaf0z+GJvYYGjZlVN+s+aCOeGbYoi3JFLQZ8ZFI7i
> sz+96VVxYWY8hm7uHn7xUzuh3LoDsYFvsNuGfmT2zliHkSmGnO5RI18w/kW9sbtG
> gPWtHhWpV/kIWiJhLxakImWQ0XNZx72T0wXWA+usVqJ7HVe6nhDGl09E+jXasU0=
> =pDV1
> -----END PGP SIGNATURE-----

[Matthias Runge]

On 02/28/2013 03:57 PM, Rahul Sundaram wrote:

>  You should introduce a python-django15 package instead and let
> dependent
>  packages slowly move over.   We cannot handle this within a single
>  release timeframe.   Every release introduces incompatibilities and
>  upstream projects aren't willing to deal with too many Django versions
>  at a time and move forward slowly.   
I see your point not to touch any
Django-package to change the
requirements, but also this will make things more confusing:
Django (as F17) is 1.4.x
python-django is 1.4.x
python-django15 is 1.5

what about Django-1.6? So I'd prefer to have python-django as moving
target and fix the release by appending the version.

Matthias
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Rahul Sundaram]

Hi

On Thu, Feb 28, 2013 at 11:22 AM, Matthias Runge wrote:

>  I see your point not to touch any Django-package to change the
>  requirements, but also this will make things more confusing:
>  Django (as F17) is 1.4.x
>  python-django is 1.4.x
>  python-django15 is 1.5
>
>  what about Django-1.6? So I'd prefer to have python-django as moving
>  target and fix the release by appending the version.
>  
Well, if the current python-django in Fedora is renamed to python-django14
and appropriate provides are added to the EPEL version such that django
dependent packages don't have to bother with if else in spec files, you
wouldn't need any moving targets at all.   The version number will be right
there in the package name and it will be obvious which version it is.   If
Django stops breaking compatibility, we can revisit this.

Rahul

[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-...
>
> >> 
> >> 
> > 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(a)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-----

[Matthias Runge]

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

On 02/28/2013 05:46 PM, Stephen Gallagher wrote:
> > 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). 
Actually, I was proposing to have python-django as package to include
every version number, and to introduce a package
python-django%{version-1} package when a new %{version} comes out.

Now, I'm more attracted to rename the python-django package (yeay,
another Django-rename) to python-django14 and to submit a new package
python-django15 for review. When 1.6 comes out, python-django14 will
get deprecated and python-django16 will be submitted for review.
But still, currently, we're carrying provides like this:
Provides:       django = %{version}-%{release}
Provides:       Django = %{version}-%{release}
and also provide python-django. The question remains, what to do here,
ie. which package should carry those provides. (probably the then
renamed python-django14 package, to make sure, not to break anything.


>  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(a)lists.fedoraproject.org
>   
Will do so.
- -- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRMFu1AAoJEOnz8qQwcaIWUGMIAI5gMvDMb2iwcaLWxwZZsRTN
> aVedreypqeUOQzxfqhLkTf6Th6UzYhmZiVAeDE/iZmkZ43ktwemPJwMKBoxvnQEJ
> oPuM5ieCi5bT/5EIcV9bnHalqINMTexNpTYqezhM+cseIRd2R2wWFAyWdXfzNQTL
> MFDMAdKvSBXmIT+1gQfS3y8nuOnK4IgktlDaWgZJ3Jr5QIctm5riuLJ5HsWHB7/t
> Qs0AcXGgI1HfxH+677CZfh0bi4MiLayW/y0Ze+vRxsKLMI4Gz/ZKaes10wF4tYlw
> HXd6roWW2kh+LLODwxTdSKogUi6/20eoz7e+Cm3JfDp5COjUtQvEbozVWgtUjPA=
> =ZGOC
> -----END PGP SIGNATURE-----

[Bohuslav Kabrda]

----- Original Message -----
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 02/28/2013 05:46 PM, Stephen Gallagher wrote:
>  >> 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).
>  
>  Actually, I was proposing to have python-django as package to include
>  every version number, and to introduce a package
>  python-django%{version-1} package when a new %{version} comes out.
>  
>  Now, I'm more attracted to rename the python-django package (yeay,
>  another Django-rename) to python-django14 and to submit a new package
>  python-django15 for review. When 1.6 comes out, python-django14 will
>  get deprecated and python-django16 will be submitted for review.
>  But still, currently, we're carrying provides like this:
>  Provides:       django = %{version}-%{release}
>  Provides:       Django = %{version}-%{release}
>  and also provide python-django. The question remains, what to do
>  here,
>  ie. which package should carry those provides. (probably the then
>  renamed python-django14 package, to make sure, not to break anything.
>   
I have to disagree with you here. Ideally, we should just have one package, python-django,
that would be the latest upstream. If that is undoable, let's also provide older
packages as python-django14 etc. But we should still keep the newest Django (whichever
version that is) in Fedora named python-django.
So my proposal:
- Don't introduce Django 1.5 in Fedora 19, the freeze is too close and breakages too
many.
- Right after branching, push Django 1.5 (package python-django) to new rawhide (future
Fedora 20) with python3-django subpackage.
- Work with upstreams to get dependent packages fixed before Fedora 20 freeze.
- If some packages fail to be compatible with Django 1.5 before Fedora 20 freeze, just
introduce python-django14 package and let them use that.
 
>  
>  > 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(a)lists.fedoraproject.org
>  > 
>  Will do so.
>  - --
>  Matthias Runge <mrunge(a)matthias-runge.de&gt;
>                 <mrunge(a)fedoraproject.org&gt;
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.13 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >  
> >  iQEcBAEBAgAGBQJRMFu1AAoJEOnz8qQwcaIWUGMIAI5gMvDMb2iwcaLWxwZZsRTN
> >  aVedreypqeUOQzxfqhLkTf6Th6UzYhmZiVAeDE/iZmkZ43ktwemPJwMKBoxvnQEJ
> >  oPuM5ieCi5bT/5EIcV9bnHalqINMTexNpTYqezhM+cseIRd2R2wWFAyWdXfzNQTL
> >  MFDMAdKvSBXmIT+1gQfS3y8nuOnK4IgktlDaWgZJ3Jr5QIctm5riuLJ5HsWHB7/t
> >  Qs0AcXGgI1HfxH+677CZfh0bi4MiLayW/y0Ze+vRxsKLMI4Gz/ZKaes10wF4tYlw
> >  HXd6roWW2kh+LLODwxTdSKogUi6/20eoz7e+Cm3JfDp5COjUtQvEbozVWgtUjPA=
> >  =ZGOC
> >  -----END PGP SIGNATURE----- 
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Matthias Runge]

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

On 03/01/2013 08:41 AM, Matthias Runge wrote:

>  But still, currently, we're carrying provides like this:
> Provides:
>  django = %{version}-%{release} Provides:       Django =
>  %{version}-%{release} and also provide python-django. The question
>  remains, what to do here, ie. which package should carry those
>  provides. (probably the then renamed python-django14 package, to
>  make sure, not to break anything. 
Na! Nonsense, should be handled by the rename.

- -- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJRMF9dAAoJEOnz8qQwcaIWBUQH/RgyKvyMZkzKM9jjFkh62y/S
> T5moxLJJU0kpjGlg+XoSvv2bpEcYyyEjKNkdBo3rkYFZPn7A6y0LpmhjkyZbECXq
> Et7j2UG9MV3gElhFGggyDB82flCvaPvKPT1MkhvtqZ16Zwbjb4dyrLCbW5DOOSwX
> TLKI9kt/5GthZhg7aHVYbxCn6j+Sv50efIqYBLAUzaA5ug/E7nJtpGvL4iUBVjm2
> wNMkcvKbvuZOayJ4MOuRtEbXQlJNW2LlQN37wx1gT7h8Zxvm3iZ64ne4RrkuBAg8
> BcDBa3ZzqUimE3fRgTND5xvHltAry4O2KEAwY2T0NZMqXxN1SJTJ4Tp1+McPizU=
> =DXnX
> -----END PGP SIGNATURE-----

[Stephen Gallagher]

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

On 03/01/2013 02:56 AM, Bohuslav Kabrda wrote:
>  ----- Original Message ----- On 02/28/2013 05:46 PM, Stephen 
>  Gallagher wrote:
> >>>> 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).
>  
>  Actually, I was proposing to have python-django as package to 
>  include every version number, and to introduce a package 
>  python-django%{version-1} package when a new %{version} comes out.
>  
>  Now, I'm more attracted to rename the python-django package (yeay,
>   another Django-rename) to python-django14 and to submit a new 
>  package python-django15 for review. When 1.6 comes out, 
>  python-django14 will get deprecated and python-django16 will be 
>  submitted for review. But still, currently, we're carrying
>  provides like this: Provides:       django = %{version}-%{release}
>  Provides: Django = %{version}-%{release} and also provide
>  python-django. The question remains, what to do here, ie. which
>  package should carry those provides. (probably the then renamed
>  python-django14 package, to make sure, not to break anything.
>  
>  
> > I have to disagree with you here. Ideally, we should just have
> > one package, python-django, that would be the latest upstream. If
> > that is undoable, let's also provide older packages as
> > python-django14 etc. But we should still keep the newest Django
> > (whichever version that is) in Fedora named python-django. So my
> > proposal: - Don't introduce Django 1.5 in Fedora 19, the freeze
> > is too close and breakages too many. - Right after branching,
> > push Django 1.5 (package python-django) to new rawhide (future
> > Fedora 20) with python3-django subpackage. - Work with upstreams
> > to get dependent packages fixed before Fedora 20 freeze. - If
> > some packages fail to be compatible with Django 1.5 before Fedora
> > 20 freeze, just introduce python-django14 package and let them
> > use that.
>  
>   

Well, I'm also looking at EPEL here (though I suppose we could just
implement a different solution on that side as well). EPEL has a much
longer life than Fedora releases (and much, much longer than the
Django upstream release maintenance period). So we need to have a plan
in place for how to keep EPEL moving forward sanely. In my humble
opinion, we should break things *once* so that packages learn to make
a dependency on a specific Django version (by doing a Requires:
python-django14) and drop the historical "Django" and unversioned
"python-django" Provides from any of the packages.

Historically, no Django-consuming package that I am aware of has
*ever* successfully moved to the next major Django release without
patching. I'd rather that we always maintain both upstream-supported
releases in Fedora and EPEL. When a package is ready and prepared to
move to the next version, they can change the Requires: line in their
spec file. If we maintain the latest as always being the
"python-django" package, we are resigning ourselves to dealing with
breakage in every cycle.


I agree that it's too late in the Fedora 19 cycle to introduce Django
1.5 as "python-django". The breakage would be enormous. However, it's
still early enough to accept the one-time breakage of retiring
"python-django" and replacing it with "python-django14" and fixing
the
packages that require it to pick its Requires. Then we could land
"python-django15" cleanly.


> >>> 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(a)lists.fedoraproject.org
> >>> 
>  Will do so.
> > -- devel mailing list devel(a)lists.fedoraproject.org 
> > https://admin.fedoraproject.org/mailman/listinfo/devel
>   
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEwsYwACgkQeiVVYja6o6OwFgCeLlSOkhci+9iseAXAzjErt3bY
> lLoAnRHQqcCcvJzkvr++UwuFHVdWyEt5
> =NVWf
> -----END PGP SIGNATURE-----

[Bohuslav Kabrda]

----- Original Message -----
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 03/01/2013 02:56 AM, Bohuslav Kabrda wrote:
>  > ----- Original Message ----- On 02/28/2013 05:46 PM, Stephen
>  > Gallagher wrote:
>  >>>>> 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).
>  > 
>  > Actually, I was proposing to have python-django as package to
>  > include every version number, and to introduce a package
>  > python-django%{version-1} package when a new %{version} comes out.
>  > 
>  > Now, I'm more attracted to rename the python-django package (yeay,
>  >  another Django-rename) to python-django14 and to submit a new
>  > package python-django15 for review. When 1.6 comes out,
>  > python-django14 will get deprecated and python-django16 will be
>  > submitted for review. But still, currently, we're carrying
>  > provides like this: Provides:       django = %{version}-%{release}
>  > Provides: Django = %{version}-%{release} and also provide
>  > python-django. The question remains, what to do here, ie. which
>  > package should carry those provides. (probably the then renamed
>  > python-django14 package, to make sure, not to break anything.
>  > 
>  > 
>  >> I have to disagree with you here. Ideally, we should just have
>  >> one package, python-django, that would be the latest upstream. If
>  >> that is undoable, let's also provide older packages as
>  >> python-django14 etc. But we should still keep the newest Django
>  >> (whichever version that is) in Fedora named python-django. So my
>  >> proposal: - Don't introduce Django 1.5 in Fedora 19, the freeze
>  >> is too close and breakages too many. - Right after branching,
>  >> push Django 1.5 (package python-django) to new rawhide (future
>  >> Fedora 20) with python3-django subpackage. - Work with upstreams
>  >> to get dependent packages fixed before Fedora 20 freeze. - If
>  >> some packages fail to be compatible with Django 1.5 before Fedora
>  >> 20 freeze, just introduce python-django14 package and let them
>  >> use that.
>  > 
>  > 
>  
>  
>  Well, I'm also looking at EPEL here (though I suppose we could just
>  implement a different solution on that side as well). EPEL has a much
>  longer life than Fedora releases (and much, much longer than the
>  Django upstream release maintenance period). So we need to have a
>  plan
>  in place for how to keep EPEL moving forward sanely. In my humble
>  opinion, we should break things *once* so that packages learn to make
>  a dependency on a specific Django version (by doing a Requires:
>  python-django14) and drop the historical "Django" and unversioned
>  "python-django" Provides from any of the packages.
>  
>  Historically, no Django-consuming package that I am aware of has
>  *ever* successfully moved to the next major Django release without
>  patching. I'd rather that we always maintain both upstream-supported
>  releases in Fedora and EPEL. When a package is ready and prepared to
>  move to the next version, they can change the Requires: line in their
>  spec file. If we maintain the latest as always being the
>  "python-django" package, we are resigning ourselves to dealing with
>  breakage in every cycle.
>  
>  
>  I agree that it's too late in the Fedora 19 cycle to introduce Django
>  1.5 as "python-django". The breakage would be enormous. However, it's
>  still early enough to accept the one-time breakage of retiring
>  "python-django" and replacing it with "python-django14" and fixing
>  the
>  packages that require it to pick its Requires. Then we could land
>  "python-django15" cleanly.
>   
What about all the django extension packages? Will there also be python-django-foo[14,15]?
Keeping the old versions around is a huge burden. And even if you admit that it's
going to be just for the necessary time, someone will come and complain that he needs more
time. Also, what about these packages in EPEL? We would have to maintain them for much
longer there...
I don't see a solution for EPEL now, but appending versions to names for Fedora seems
too hacky to me. Also it means that you need to do review for each of those packages (and
the extension packages!) and you need to retire them after some time... I don't really
think that we should go this way.

>  
>  >>>> 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(a)lists.fedoraproject.org
>  >>>> 
>  > Will do so.
>  >> -- devel mailing list devel(a)lists.fedoraproject.org
>  >> https://admin.fedoraproject.org/mailman/listinfo/devel
>  > 
>  
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.13 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >  
> >  iEYEARECAAYFAlEwsYwACgkQeiVVYja6o6OwFgCeLlSOkhci+9iseAXAzjErt3bY
> >  lLoAnRHQqcCcvJzkvr++UwuFHVdWyEt5
> >  =NVWf
> >  -----END PGP SIGNATURE----- 
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel 
-- 
Regards,
Bohuslav "Slavek" Kabrda.

[Miloslav Trmač]

On Fri, Mar 1, 2013 at 8:56 AM, Bohuslav Kabrda <bkabrda(a)redhat.com&gt; wrote:
> > Now, I'm more attracted to rename the python-django package
> (yeay,
> > another Django-rename) to python-django14 and to submit a new package
> > python-django15 for review. When 1.6 comes out, python-django14 will
> > get deprecated and python-django16 will be submitted for review.
> > But still, currently, we're carrying provides like this:
> > Provides:       django = %{version}-%{release}
> > Provides:       Django = %{version}-%{release}
> > and also provide python-django. The question remains, what to do
> > here,
> > ie. which package should carry those provides. (probably the then
> > renamed python-django14 package, to make sure, not to break anything.
> >
>
>  I have to disagree with you here. Ideally, we should just have one package,
> python-django, that would be the latest upstream. If that is undoable, let's also
> provide older packages as python-django14 etc. But we should still keep the newest Django
> (whichever version that is) in Fedora named python-django. 
Yes.  That's also what
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packag...
describes.

(In the recent years, the number of upstreams and packagers that can't
or won't support a smooth upgrade path and want to have several
versions of the same package installed has noticeably increased, and
we may need to react to this by designing a different parallel
installation setup and packaging guidelines - but let's not do it by
ignoring the current guidelines one package at a time.)
    Mirek

[Miloslav Trmač]

On Fri, Mar 1, 2013 at 2:47 PM, Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:
>  Well, I'm also looking at EPEL here (though I suppose we could
> just
>  implement a different solution on that side as well). EPEL has a much
>  longer life than Fedora releases (and much, much longer than the
>  Django upstream release maintenance period). So we need to have a plan
>  in place for how to keep EPEL moving forward sanely. In my humble
>  opinion, we should break things *once* so that packages learn to make
>  a dependency on a specific Django version (by doing a Requires:
>  python-django14) and drop the historical "Django" and unversioned
>  "python-django" Provides from any of the packages. 
Note that the provides/requires are not necessarily tied to package
names.  There is sufficient prior art - quite a few languages have
special ABI/API "marker" provides/requires while still having an
unversioned package name.
    Mirek

[Matthias Runge]

On 02/28/2013 12:58 PM, 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-...
>   
To get this more coordinated, I started a wiki page[1], including all
django packages. As far as I knew, if that package is django-1.5 ready,
I also made a remark.


I still don't like the idea to rename the current python-django package
to python-django14 and to make a new package python-django15. The latter
may not provide python-django or Django for compatibility reasons.

I'd stick with
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packag...

and still try to get python-django14 as new package accepted[2]. I can
offer support in changing requirements from python-django/Django to
python-django14.

Matthias


[1] https://fedoraproject.org/wiki/User:Mrunge/django15
[2] https://bugzilla.redhat.com/show_bug.cgi?id=916676
-- 
Matthias Runge <mrunge(a)matthias-runge.de&gt;
               <mrunge(a)fedoraproject.org&gt;

[Nicolas Mailhot]

Le Ven 1 mars 2013 17:41, Miloslav Trmač a écrit :

>  (In the recent years, the number of upstreams and packagers that
> can't
>  or won't support a smooth upgrade path and want to have several
>  versions of the same package installed has noticeably increased, and
>  we may need to react to this by designing a different parallel
>  installation setup and packaging guidelines - but let's not do it by
>  ignoring the current guidelines one package at a time.) 
IMHO the compat-foo naming convention is much better, as it clearly states
the package is ultimately going to the killing block, so people need to
migrate away now, while fooxy implies xy is here for the long run and
people needn't worry.

-- 
Nicolas Mailhot