Re: python-2.1 for unstable?
Sorry guys for the silence. I had to go through upgrading my hardware,
upgrading my line setup to a new provider with a flat fee, and finally, some
real world work kept me busy.
On Mon, May 21, 2001 at 10:35:15PM +0200, Tom Cato Amundsen wrote:
> On 21 May 2001 20:57:34 +0200, Matthias Klose wrote:
>
> > I really would like to see 2.1 in the next Debian release. I'd like to
> > ask Gregor (the maintainer) for an upload schedule, so that other
> > maintainers can rely on this to get their packages ready for the next
> > release as well. Are there still license issues which will be resolved
> > in upcoming releases? Should we skip 2.1 and hope that 2.2 gets
>
> I don't think 2.1 is much better than 2.0 when it comes to GPL
> compatibility. But the roumurs say that there will be a 2.1.1 release that
> is fixes this and a few other bugs. I think the new (2.1.1) license was
> blessed by rms... Sorry, I don't remember where I read this.
Here's a quick update:
I talked to RMS, Eben Moglen and GvR. The bad news: According to RMS+Moglen,
the license used in Python 2.1 still is not yet compatible with the GPL. The
good news: The PSF decided to drop the choice of law clause. A modified
license is in CVS, and, according to Guido, will be used for the maintenance
releases 2.0.1 and 2.1.1. The bright news: Moglen himself told me that the
license text in CVS is compatible with the GPL.
Guido asked for our release plan. He'd like to inform the release managers
of 2.0.1 and 2.1.1, and seemed to be quite interested to make sure that the
next release of Debian will contain a fixed version:
On Tue, May 08, 2001 at 04:32:13PM +0200, Gregor Hoffleit wrote:
> On Tue, May 08, 2001 at 09:48:38AM -0500, Guido van Rossum wrote:
> > That would be great! When should 2.1.1 be out in order for it to be
> > the default version? If I have a specific date I can put some
> > pressure on the folks responsible for assembling the release!
>
> The earlier, the better, is all I can say ;-)
>
>
> According to our release manager, Anthony Towns <ajt@debian.org>, the
> critical dates for the next release or like this:
>
> > * Policy goes into debugging mode on 1st June, and no further
> > changes may be made after about 20th June.
> >
> > * Base packages must have all release-critical bugs fixed by
> > 1st July, and no further changes may be made after about 20th
Jul$> >
> > * Boot-floppies, standard packages, task packages, and packages
> > included in tasks or in boot-floppies need all their
> > release-critical bugs fixed by 1st August, and no further
> > release-critical bugs fixed by 1st August, and no further
> > changes may be made to them after about 20th August.
> >
> > * The remaining packages (optional, extra) need their
> > release-critical bugs fixed by 1st September, and no further
> > changes may be made to them after about 20th September.
> >
> > * We release early to mid October.
> >
> > Again this is still fairly optimistic, and not necessarily going to
> > happen. (Hi Slashdot.)
>
>
> Looks like plenty of time, but due to the big tree of dependencies, the
> timeframes are still quite tight.
>
> python is now a 'standard' package in Debian. Therefore I should not make
> any critical changes on the default Python packages after August 1.
> Currently, the 'default' Python packages are built from Python 1.5.2. A
> problem is that it would take some time of preparation after the release of
> Python 2.1.1 to change the default Python to 2.1.1 (coordinating uploads of
> packages with new dependencies, testing of the dependencies, etc. pp.).
>
>
> Given that the above dates all hold true: If Python 2.1.1 is out by July 1,
> it should be possible to include it as default Python version in the next
> release. (And, it would be ready in time for the European Python Meeting in
> Bordeaux ;-).
>
> If it's out by mid-September, it still could be included, but only as second
> choice. Python 1.5.2 would then be default.
>
>
> Still, I would very much appreciate if it was released earlier, since that
> would allow for a much smoother transition and for a better testing.
Reply to: