Release schedule

Release schedule

[Richard Stallman]

I have some changes to install in the manual and I probably can't
do it today.  Also, there are a few things that may need fixing.
Please don't start making a release until you hear from me.

Re: Release schedule

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> Also, there are a few things that may need fixing.

Please be specific.

Re: Release schedule

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 20 Apr 2007 17:53:49 -0400
> 
> I have some changes to install in the manual and I probably can't
> do it today.  Also, there are a few things that may need fixing.
> Please don't start making a release until you hear from me.

In that case, I think we should make another pretest.  We cannot just
release the code with untested patches that got installed since the
22.0.98 pretest.

Does anyone disagree?

Re: Release schedule

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 20 Apr 2007 17:53:49 -0400
>> 
>> I have some changes to install in the manual and I probably can't
>> do it today.  Also, there are a few things that may need fixing.
>> Please don't start making a release until you hear from me.
>
> In that case, I think we should make another pretest.  We cannot just
> release the code with untested patches that got installed since the
> 22.0.98 pretest.
>
> Does anyone disagree?

We know exactly what patches went into the tree, and that they are not
risky.  So I think the situation is OK.

On Monday, I will cut the branch and roll a candidate Emacs 22.1
tarball.  If no immediate problems are found with that tarball, I
think we can make that the official release.

Re: Release schedule

[Glenn Morris]

Chong Yidong wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
[...]
>> In that case, I think we should make another pretest.  We cannot just
>> release the code with untested patches that got installed since the
>> 22.0.98 pretest.
>>
>> Does anyone disagree?

Cleverly worded... :)

> On Monday, I will cut the branch and roll a candidate Emacs 22.1
> tarball.  If no immediate problems are found with that tarball, I
> think we can make that the official release.

This doesn't seem like a good idea to me. I suggest branching on
Monday, making an immediate final pretest from the branch, waiting a
few days (and not making _any_ changes unless Emacs is shown to
explode), then making a release.

I was hoping for a St George's day release, alas... :(

Re: Release schedule

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

>> On Monday, I will cut the branch and roll a candidate Emacs 22.1
>> tarball.  If no immediate problems are found with that tarball, I
>> think we can make that the official release.
>
> This doesn't seem like a good idea to me. I suggest branching on
> Monday, making an immediate final pretest from the branch, waiting a
> few days (and not making _any_ changes unless Emacs is shown to
> explode), then making a release.

In that case, why don't we simply branch and make a final pretest now?

Re: Release schedule

[Glenn Morris]

Chong Yidong wrote:

> In that case, why don't we simply branch and make a final pretest now?

The only reason I can see is whatever unspecified things rms wants to
do, and the fact that the last thing he said was to branch on Monday.

Re: Release schedule

[Nick Roberts]

 > > On Monday, I will cut the branch and roll a candidate Emacs 22.1
 > > tarball.  If no immediate problems are found with that tarball, I
 > > think we can make that the official release.
 > 
 > This doesn't seem like a good idea to me. I suggest branching on
 > Monday, making an immediate final pretest from the branch, waiting a
 > few days (and not making _any_ changes unless Emacs is shown to
 > explode), then making a release.

Sounds the same to me.

 > I was hoping for a St George's day release, alas... :(

Maybe an ANZAC day release then? :) (25th April).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Release schedule

[Glenn Morris]

Nick Roberts wrote:

> Sounds the same to me.

I guess my only point was, I don't think it's a good idea to call it
"22.1" until it really is released (but maybe I misunderstood the
original proposal).

Re: Release schedule

[Eli Zaretskii]

> Cc: rms@gnu.org, emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 21 Apr 2007 15:25:20 -0400
> 
> We know exactly what patches went into the tree, and that they are not
> risky.  So I think the situation is OK.

In software, you can never know such things for certain, and the more
changes you make, the less certain you are in the outcome.

So I think we need another pretest, but if I'm the only one, so be it.

Re: Release schedule

[Juanma Barranquero]

On 4/22/07, Eli Zaretskii <eliz@gnu.org> wrote:

> So I think we need another pretest, but if I'm the only one, so be it.

You're not the only one. It wouldn't be the first time that apparently
trivial changes bite us. Releasing without testing seems a bit
reckless, and it's not like a few days more will even be noticeable
against our quinquennial-release backdrop.

So I'm all for another pretest.

             Juanma

Re: Release schedule

[Kim F. Storm]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> So I'm all for another pretest.

Me too.

With the +++ / --- lines removed from NEWS, please!!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Release schedule

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> So I'm all for another pretest.
>
> Me too.

If only we'd manage to get a pretest cycle finished without somebody
noticing things that "really need to" get reorganized before the
release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Release schedule

[Romain Francoise]

storm@cua.dk (Kim F. Storm) writes:

> With the +++ / --- lines removed from NEWS, please!!

Don't panic, they've already been deleted! :-)

Re: Release schedule

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: rms@gnu.org, emacs-devel@gnu.org
>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Sat, 21 Apr 2007 15:25:20 -0400
>> 
>> We know exactly what patches went into the tree, and that they are not
>> risky.  So I think the situation is OK.
>
> In software, you can never know such things for certain, and the more
> changes you make, the less certain you are in the outcome.

OK.  I'll cut the Emacs 22 branch on Monday and make a 22.0.99 pretest
from the branch.

Re: Release schedule

[Richard Stallman]

    On Monday, I will cut the branch and roll a candidate Emacs 22.1
    tarball.  If no immediate problems are found with that tarball, I
    think we can make that the official release.

There are some discussions about bug fixes going on just now.
I don't recall whether all of them have been resolved yet.
Please verify that they have been, before you make that candidate
tarball.

Meanwhile, there is another issue.  The candidate tarball
must not have "22.1" as the version number!  It has to be
labeled as a pretest, not as a release.  If all goes well,
_the same source files_ can be the release.  But it can't
be the same tarball!

Re: Release schedule

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 22 Apr 2007 12:35:36 -0400
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> 
> If all goes well, _the same source files_ can be the release.  But
> it can't be the same tarball!

Actually, even the sources cannot be the same, since various files
have the version embedded in them, and the "Version 22.1 released."
thing needs to be added to all ChangeLog files.

But I'm quite sure Chong knows all this, since we discussed that in a
not very distant past.

Re: Release schedule

[Kenichi Handa]

In article <ufy6tgl7w.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > From: Chong Yidong <cyd@stupidchicken.com>
> > Date: Sat, 21 Apr 2007 15:25:20 -0400
> > 
> > We know exactly what patches went into the tree, and that they are not
> > risky.  So I think the situation is OK.

> In software, you can never know such things for certain, and the more
> changes you make, the less certain you are in the outcome.

> So I think we need another pretest, but if I'm the only one, so be it.

I agree with Eli on this matter.

---
Kenichi Handa
handa@m17n.org

Re: Release schedule

[Richard Stallman]

    If only we'd manage to get a pretest cycle finished without somebody
    noticing things that "really need to" get reorganized before the
    release.

It is a good thing someone noticed!

Re: Release schedule

[Stefan Monnier]

>     If only we'd manage to get a pretest cycle finished without somebody
>     noticing things that "really need to" get reorganized before the
>     release.

> It is a good thing someone noticed!

It's not.  I can easily come up with "something that needs reorganizing" or
even with plain bugs.  I don't know how long I could keep it up, but I'm
pretty sure I could delay the release by a few years this way.

Emacs is and has always be "approximate", allowing itself incorrect
behaviors in various "corner" cases, based on the expectation that the user
will notice it.  The result is "a big happy mess" that's also
tremendously useful.  Fixing it would amount to breaking it.


        Stefan

Re: Release schedule

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>     If only we'd manage to get a pretest cycle finished without somebody
>>     noticing things that "really need to" get reorganized before the
>>     release.
>
>> It is a good thing someone noticed!
>
> It's not.  I can easily come up with "something that needs
> reorganizing" or even with plain bugs.  I don't know how long I
> could keep it up, but I'm pretty sure I could delay the release by a
> few years this way.
>
> Emacs is and has always be "approximate", allowing itself incorrect
> behaviors in various "corner" cases, based on the expectation that
> the user will notice it.  The result is "a big happy mess" that's
> also tremendously useful.  Fixing it would amount to breaking it.

"Fixing" and "reorganizing" stuff eternally is not tantamount to
breaking Emacs.  It is tantamount to keeping Emacs to ourselves and
not let the users have it.

-- 
David Kastrup