Re: 21.2.90 pretest, 21.3, 21.4...

Re: 21.2.90 pretest, 21.3, 21.4...

[jasonr]

> > IMO, a feature freeze on the trunk at the current state would be OK!

Currently image support on MS-Windows is very incomplete and unstable.
I checked in what I had several months ago in the hope that someone
else would be interested in working on it once the major work of
getting started was done. But this has not happened, and I have not
had time to do any further work myself, and am not likely to have
time in the near future. So if a feature freeze is imminent and
noone can do the work to complete it, may need to disable image support
on Windows again.

21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

21.1 was released on 2001-10-20, more than a year ago.

21.2 was released on 2002-03-16, almost eight months ago.

We're just on the second pretest of 21.3. I think it's fair to assume
it'll be still a few months (at least two or three) before 21.3 hits the
streets.  Even if we feature-freeze 21.4-to-be at this moment and start
pretesting it like mad, it'll be almost two years since the last
feature-packed release was introduced to the public.  22.1 with Unicode
will be much further yet along the way.

OK, I know that:
 - we don't *have* to be faster than that
 - we prefer quality releases 
 - people really interested in features vs. stability can access the CVS

Still, I wonder if we should try to pack less punch in each release, and
release a bit faster than we're doing today.  I fear that this (totally
apparent, but public perception counts) stagnation can lead people to
other editors, or (worse, although more improbably) more Emacs branching.

Also, it's tough trying to evangelize people when I know that some
much-appreciated features are just in the HEAD and won't see the light
in a year or two...

Of course, I don't know what we should do, other than attracting more
people to Emacs development. Perhaps a tentative schedule like the one
in GCC would be a first step, but I'm not sure.

Or perhaps the problem is only on my mind; in that case, sorry for
taking your time.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> We're just on the second pretest of 21.3. I think it's fair to assume
> it'll be still a few months (at least two or three) before 21.3 hits the
> streets.  Even if we feature-freeze 21.4-to-be at this moment and start
> pretesting it like mad, it'll be almost two years since the last
> feature-packed release was introduced to the public.  22.1 with Unicode
> will be much further yet along the way.
[...]

I obviously agree since I called for a feature freeze a few weeks
(months?) back already.  I also think that 21.2 should have been taken
from the trunk rather than from the RC branch and same thing for 21.3.

This way we'd get new features more quickly into release and we'd get
the trunk code tested more thoroughly as well.

As Dave has explained the bug-fix release 21.3 will still be riddled with
bugs that we have fixed on the trunk months ago.  Maybe it will be a bit
more stable from one particular point of view because it doesn't use any
new code that might introduce new bugs, but I'm definitely not convinced
that it outweighs the number of unfixed non-trivial bugs.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Mon, 4 Nov 2002, Stefan Monnier wrote:

> I obviously agree since I called for a feature freeze a few weeks
> (months?) back already.

IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
not to release from the branch anymore.  Since there was a decision to 
release 21.3 from the branch, the decision not to feature-freeze followed 
almost automatically.

> I also think that 21.2 should have been taken
> from the trunk rather than from the RC branch and same thing for 21.3.

For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
eliminate bugfix releases, which I think would be wrong: users will have 
no stable versions to rely upon.

> As Dave has explained the bug-fix release 21.3 will still be riddled with
> bugs

FWIW, I think ``riddled with bugs'' is a grave exaggeration.

> Maybe it will be a bit
> more stable from one particular point of view because it doesn't use any
> new code that might introduce new bugs, but I'm definitely not convinced
> that it outweighs the number of unfixed non-trivial bugs.

So do you really think that introduction of significant new features 
doesn't destabilize Emacs?

That is, do you suggest to skip branch releases because they are not more 
stable _in_principle_, or just because we are too inept to make them 
significantly more stable?

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> For 21.3, maybe.  But for 21.2, I disagree.

With 21.1 and 21.2 you can destroy your files easily (even RMS was
bitten once[1]); the ordinary user isn't able to those encoding related
problems on his own.  Thus, please release 21.3 ASAP -- 21.3 is _very_
important for European users.  I don't understand why it takes that
long to release a version fixing these encoding related problems.

I know, resources are limited, but this must not mean to ignore or delay
serious problems.  I also put some time in testing the RC and said it is
better than the previous version; but I cannot test a bug fix release
again and again; I need some features from HEAD for my daily work.

Bug fix releases must happen in a timely manner -- otherwise they take
away to many resources from all of us.

________________
[1] Cf.:
From: Richard Stallman <rms@gnu.org>
Subject: Several serious problems
To: handa@etl.go.jp, spiegel@gnu.org, savannah-hackers@gnu.org
Cc: emacs-devel@gnu.org
Reply-To: rms@gnu.org
Date: Mon, 22 Jul 2002 11:11:35 -0600 (MDT)
Message-Id: <200207221711.g6MHBZo02496@aztec.santafe.edu>

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 08:02:42 +0100, Karl Eichwalder <keichwa@gmx.net> wrote:

> I also put some time in testing the RC and said it is
> better than the previous version; but I cannot test a bug fix release
> again and again; I need some features from HEAD for my daily work.
> 
> Bug fix releases must happen in a timely manner -- otherwise they take
> away to many resources from all of us.

To me, that's the crux of it. Yes.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Tue, 05 Nov 2002 08:02:42 +0100
> 
> I don't understand why it takes that
> long to release a version fixing these encoding related problems.

What's there to understand?  Something needs to do the job of
preparing the tarballs and making decisions which bugs to fix on the
branch and how.  The available resources (manpower and free time) are
obviously not enough to make timely releases.

In addition, I've lost most of my free time since May and my gnu.org
account a couple of months ago.  Thus a very long gap between the last
pretest and the one before that.  Lately, Francesco kindly agreed to
take over, so we finalyy have another pretest.

> I know, resources are limited, but this must not mean to ignore or delay
> serious problems.

Nobody ignores serious problems, please don't assume such things.

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> What's there to understand?

There are no patch sets to fix a special problem -- all fixes are done
incrementally.  Having patch sets could theoretically allow to fix on
to of 21.2 the encoding problem only.

> Something needs to do the job of preparing the tarballs and making
> decisions which bugs to fix on the branch and how.  The available
> resources (manpower and free time) are obviously not enough to make
> timely releases.

Sure.  I don't want to blame you (or any other release manager)
personally, by no means!  Pre-release candidates should be available
more visibly.

> Nobody ignores serious problems, please don't assume such things.

Yes, but if a problem is rated as serious it might be appropriate to
work on such a problem first and to try to solve it for _all_ Emacs
users.  Maybe, that's just my very personal opinion.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Karl Eichwalder wrote:

> There are no patch sets to fix a special problem -- all fixes are done
> incrementally.  Having patch sets could theoretically allow to fix on
> to of 21.2 the encoding problem only.

Sorry, I don't think I understand what do you mean by ``patch sets''.

AFAIK, Emacs has never released any patches (is there a project that 
does?), only tarballs of new versions where some problems are fixed
(and new exciting ones are added ;-).

> Pre-release candidates should be available more visibly

That already happened, I think: the directory on alpha.gnu where we put 
the pretests is no longer secret or unreadable.  And on top of that, 
there's anon CVS access.  Isn't that enough?

Re: 21.2.90 pretest, 21.3, 21.4...

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Sorry, I don't think I understand what do you mean by ``patch sets''.

1 patch or 1 patch set to fix something well defined that's said to be a
bug; examples out of the blue: disabling fringes, enabling encoding
unification, prevent crash on architecture 'foo', and the like.

> AFAIK, Emacs has never released any patches (is there a project that
> does?),

Linux kernel hackers?

> only tarballs of new versions where some problems are fixed

Yes.  My idea is to prepare those patches mainly for internal release
management purposes (but it wouldn't hurd to make them available on
alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
serious problem with the already released version pops up, fix just
this problem and release a fixed version immediately.  Than apply the
patch sets again and continues the usual pre-release testing cycle.

Also, there are fixes that don't require extensive testing; either
because they are trivial or because they could affect only a small
fraction of users (does not compile on architecture 'bar').  I'd like
to see released those fixes rather timely.

Hope it's clear what I meant.  If not, just forget about it ;-)

> the directory on alpha.gnu where we put the pretests is no longer
> secret or unreadable.

I wasn't aware of this change, great!  I recommend to announce things
like this more publicly.  PITA, that the gnu announce group is empty
since ages -- as long as you (not you personally) don't fix the
announce channels you don't have a right to complain about the lack of
manpower.

Others wihtin this thread already said: the more activity (useful
releases) you will show to the user and hacker crowed the more you will
attract helpful hands.

Okay, talk is easy.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.gnu.franken.de/ke/                            |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Wed, 6 Nov 2002, Karl Eichwalder wrote:

> My idea is to prepare those patches mainly for internal release
> management purposes (but it wouldn't hurd to make them available on
> alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
> serious problem with the already released version pops up, fix just
> this problem and release a fixed version immediately.

You assume that in the meantime no changes were done in the CVS, which is 
normally not the case.

Also, an entirely new tarball for each bug sounds excessive (each one is 
20MB compressed, remember?).

> PITA, that the gnu announce group is empty
> since ages -- as long as you (not you personally) don't fix the
> announce channels you don't have a right to complain about the lack of
> manpower.

I didn't complain.  Someone needs to step forward to fix gnu.announce as 
well.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 6 Nov 2002, Karl Eichwalder wrote:
>
>> My idea is to prepare those patches mainly for internal release
>> management purposes (but it wouldn't hurd to make them available on
>> alpha, too).  Prepare pre-releases as usual, do testing.  Now, when a
>> serious problem with the already released version pops up, fix just
>> this problem and release a fixed version immediately.
>
> You assume that in the meantime no changes were done in the CVS, which is 
> normally not the case.

Maybe it could work like this: version 21.4 is released.  A bug
regarding mumblefoo is found.  Somebody takes 21.4 and fixes the bug
and releases a mumblefoo patch against 21.4.  A bug regarding
frobnicating is found.  Somebody else takes 21.4 and fixes the bug
and releases a frobnicating patch against 21.4.

Each such patch is also applied to the head.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

    1 patch or 1 patch set to fix something well defined that's said to be a
    bug; examples out of the blue: disabling fringes, enabling encoding
    unification, prevent crash on architecture 'foo', and the like.

This would be extra work, and since we are short-handed, I won't make
any commitment to do this or lead the users to expect this.  If people
want the very latest sources, they can always get them from CVS.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 5 Nov 2002 08:05:29 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> not to release from the branch anymore.  Since there was a decision to 
> release 21.3 from the branch, the decision not to feature-freeze followed 
> almost automatically.

OK, but then, as soon as 21.3 hits the streets, we *should* create a new
release branch, feature-freeze it and start pretesting it. If we want a
shinny new-features release sometime before 2004, I mean. And it's my
*strong* believe we should want it. Like it or not, users and developers
are more attracted if it seems there's movement. I'd bet people out
there things Emacs development is glacial.

> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

I cannot talk on behalf of Steffan, but at least I, who started the
thread, *don't* suggest such a thing. I suggest schedules.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> Date: Tue, 05 Nov 2002 09:02:01 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> OK, but then, as soon as 21.3 hits the streets, we *should* create a new
> release branch, feature-freeze it and start pretesting it.

Yes, I agree.  But I'm no longer involved in the development enough
to make my opinion on this matter count too much.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

I do not suggest to eliminate bugfix releases, but IMVHO it would be
useful for the stable branch not to deviate too much from the
development branch (aka head).  Maybe this can be achieved by making
"smaller" releases, where each new release has fewer new features.
(But I realize that this is difficult for the new unicode branch.)

But then, I'm not an experienced developer for big projects like this.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
> Date: Tue, 05 Nov 2002 13:02:12 +0100
> 
> I do not suggest to eliminate bugfix releases, but IMVHO it would be
> useful for the stable branch not to deviate too much from the
> development branch (aka head).

I agree, but the only good way to achieve that is to release the
bugfix versions faster.

> Maybe this can be achieved by making
> "smaller" releases, where each new release has fewer new features.

That requires a higher degree of control than we have now over what
changes are installed on the trunk.  As long as each change does not
need to be approved before it's installed, I think we cannot guarantee
that some new features are postponed.

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > Maybe this can be achieved by making
> > "smaller" releases, where each new release has fewer new features.
> 
> That requires a higher degree of control than we have now over what
> changes are installed on the trunk.  As long as each change does not
> need to be approved before it's installed, I think we cannot guarantee
> that some new features are postponed.

That's not true.  We can and do declare feature freezes and we can
impose them pretty effectively by shaming the poor soul who disobeys
and undoing his change.  It works very well in practice.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Stefan Monnier wrote:

> > > Maybe this can be achieved by making
> > > "smaller" releases, where each new release has fewer new features.
> > 
> > That requires a higher degree of control than we have now over what
> > changes are installed on the trunk.  As long as each change does not
> > need to be approved before it's installed, I think we cannot guarantee
> > that some new features are postponed.
> 
> That's not true.  We can and do declare feature freezes and we can
> impose them pretty effectively by shaming the poor soul who disobeys
> and undoing his change.

Feature freeze means there are _no_ new features until the thaw; Kai 
suggested a finer control (allow some new features, but not others).

I also have a clear impression that reverting changes is something we 
do only as the last resort (and for a number of good reasons; I don't 
suggest doing that more often!).  I don't remember a single change that 
was reverted because we thought it would destabilize the code, I think 
the few cases of chnage revrsal were all due to known bugs they caused, 
not because we were afraid of unknown bugs.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kim F. Storm]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Feature freeze means there are _no_ new features until the thaw; Kai 
> suggested a finer control (allow some new features, but not others).

IMO, a feature freeze on the trunk at the current state would be OK!

There are now so many new features and fixes compared to 21.[1-3], that
starting a pretest cycle for 21.4 from the trunk would be a _good thing_
to start getting all those new features tested (before we add even more
features).

Admittedly, it would halt "development" on the trunk for, say 2-3
months, but what's the purpose of such developments anyway if we
(virtually) never make a release containing those new features?

So I suggest that we announce a date (e.g. Dec 1st) for a trunk
feature freeze and make the first pretest for 21.4 soon thereafter,
with the goal of releasing 21.4 no later than Mar 1st, 2003!

In my experience, the trunk has been very stable for a very long time
[with a few hickups of course], so after the first few pretests, I
would assume that the software would be stable enough for a release,
or at least stable enough that we could make a 21_4 release branch for
ironing out the final issues with the 21.4 release and remove the
feature freeze on the trunk before Mar 1st (or whenever 21.4 will
actually be ready).

Are anyone of you aware of any significant stability (or redisplay)
related bugs that we need to fix before 21.4 ?

Are there any of the on-going tasks which *must be* completed before
we release 21.4 ?

I know we need some work on the manuals for the new features; maybe
the goal of releasing 21.4 soon will also move our focus towards
writing proper documentation for the new features (I know I still have
a few pending tasks in that area).

WDYT ??

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

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On 06 Nov 2002 13:40:18 +0100, storm@cua.dk (Kim F. Storm) wrote:

> IMO, a feature freeze on the trunk at the current state would be OK!

I agree.

> So I suggest that we announce a date (e.g. Dec 1st) for a trunk
> feature freeze and make the first pretest for 21.4 soon thereafter,
> with the goal of releasing 21.4 no later than Mar 1st, 2003!

I think those are reasonable goals. Dec 1st for the freeze leaves time
enough for those who really *want* to include something in the 21.4 (at
least, if that "something" is not big, and if it is, it would be better
to wait for 21.5 anyway, IMO). That's four months of pretesting at the
bare minimum.  And we can always slip past the deadline... :)

> In my experience, the trunk has been very stable for a very long time
> [with a few hickups of course], so after the first few pretests, I
> would assume that the software would be stable enough for a release,
> or at least stable enough that we could make a 21_4 release branch for
> ironing out the final issues with the 21.4 release and remove the
> feature freeze on the trunk before Mar 1st (or whenever 21.4 will
> actually be ready).

Yes. I agree wrt stability of the trunk. I use 21.3.50 daily in my
production environment.  I don't remember the last time I had a crash;
many months ago. Several times I wasn't able to compile or bootstrap,
but if it compiles, it is rock-solid.

> Are anyone of you aware of any significant stability (or redisplay)
> related bugs that we need to fix before 21.4 ?

I know of two problems. At least one of them is Windows-specific, but I
don't know how to fix it: if you use w32-select-font and get an
*-iso10646-1 font, pasting it into the Registry
(HKLM\Software\GNU\Emacs\Font) garbles Emacs display. It looks like
Emacs isn't aware it's using an Unicode font. That happens both in the
RC and HEAD branches.

The other, related to some changes by Richard a few months ago, is that
the scroll line-by-line doesn't work when you're displaying the
ruler (or any other thing that makes Emacs show partially-visible lines).
In that case scroll always recenter the cursor irrespective of the value
of `scroll-conservatively'. It's a redisplay bug, but minor. Happens
only on the trunk.

> WDYT ??

FWIW, I think that any reasonable mesure to take the new features out to
the public light is good.


                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On 6 Nov 2002, Kim F. Storm wrote:

> IMO, a feature freeze on the trunk at the current state would be OK!
> 
> There are now so many new features and fixes compared to 21.[1-3], that
> starting a pretest cycle for 21.4 from the trunk would be a _good thing_
> to start getting all those new features tested (before we add even more
> features).

That means 2 pretests at once (as long as 21.3 is not released).  I don't 
think we can handle that.

> Admittedly, it would halt "development" on the trunk for, say 2-3
> months, but what's the purpose of such developments anyway if we
> (virtually) never make a release containing those new features?

That's what we did before branches.  I'm not sure we should go back to 
that model.

The reason for the branch was that many developers are interested in 
development much more than they are interested in pretest and other 
mundane tasks which are important for fast releases after the freeze.  
The branch was supposed to give those people an opportunity to check in 
changes even as the pretest was under way.

> Are anyone of you aware of any significant stability (or redisplay)
> related bugs that we need to fix before 21.4 ?

Emacs 21.1 was stable for me more than a year before it was released.  
The pretest phase found problems none of the developers ever saw.  Moral: 
don't make decisions about stability based on what people who read this 
forum tell you.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Wed, 6 Nov 2002 16:25:04 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> The reason for the branch was that many developers are interested in 
> development much more than they are interested in pretest and other 
> mundane tasks which are important for fast releases after the freeze.  
> The branch was supposed to give those people an opportunity to check in 
> changes even as the pretest was under way.

Sure. But perhaps we should *always* have a pretest active. We are
pretesting 21.3 and developing 21.4. As soon as 21.3 is released, the
very same day, we branch for 21.4 with feature-freeze. Then each people
can decide if they want to help in getting out a "features" version or
continue hackin' new features (or both). And the day 21.4 is announced
we branch for 21.5, etc.

> Emacs 21.1 was stable for me more than a year before it was released.  
> The pretest phase found problems none of the developers ever saw.

Sure. Still, that's unavoidable, so the more time it takes releasing a
pretest, the more it'll be delayed the definitive release.

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Miles Bader]

On Wed, Nov 06, 2002 at 04:25:04PM +0200, Eli Zaretskii wrote:
> > Are anyone of you aware of any significant stability (or redisplay)
> > related bugs that we need to fix before 21.4 ?
> 
> Emacs 21.1 was stable for me more than a year before it was released.  
> The pretest phase found problems none of the developers ever saw.  Moral: 
> don't make decisions about stability based on what people who read this 
> forum tell you.

For me too (and I normally update from CVS _every single day_), but it's
still a good question I think, because every once in a [long] while a nasty
bug shows up which not everyone may notice, like the scrolling-sometimes-
trashes-the-screen problem that's come and gone for a while (I _think_ that's
fixed, currently, but since it's come back from the dead several times, I'm
ever-so-slightly nervous).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: 21.2.90 pretest, 21.3, 21.4...

[Francesco Potorti`]

>That means 2 pretests at once (as long as 21.3 is not released).  I don't 
>think we can handle that.

We could do that as soon as 21.3 is released.

Re: 21.2.90 pretest, 21.3, 21.4...

[Francesco Potorti`]

>IMO, a feature freeze on the trunk at the current state would be OK!

Not a bad idea.

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

I see no reason to aim for a 21.4 release very soon.

Re: 21.2.90 pretest, 21.3, 21.4...

[Kai Großjohann]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> From: kai.grossjohann@uni-duisburg.de (Kai =?iso-8859-1?q?Gro=DFjohann?=)
>> Date: Tue, 05 Nov 2002 13:02:12 +0100
>> 
>> I do not suggest to eliminate bugfix releases, but IMVHO it would be
>> useful for the stable branch not to deviate too much from the
>> development branch (aka head).
>
> I agree, but the only good way to achieve that is to release the
> bugfix versions faster.

What's the problem with doing more releases from the head and fewer
from the branch?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Wed, 6 Nov 2002, Kai =?iso-8859-1?q?Gro=DFjohann?= wrote:

> > I agree, but the only good way to achieve that is to release the
> > bugfix versions faster.
> 
> What's the problem with doing more releases from the head and fewer
> from the branch?

The desire to have a stable version out there from time to time?

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 22:00:09 +0300, "Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> That requires a higher degree of control than we have now over what
> changes are installed on the trunk.  As long as each change does not
> need to be approved before it's installed, I think we cannot guarantee
> that some new features are postponed.

Well, that's a matter of self-discipline. Perhaps I'm too optimistic,
but I'd think that just asking for no new features to be checked in for
a while should suffice...

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > I obviously agree since I called for a feature freeze a few weeks
> > (months?) back already.
> 
> IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> not to release from the branch anymore.

Why is that ?
Even if we feature freeze it now, 21.4 will not be out before the end
of 2003.  I.e. long after 21.3.

> > I also think that 21.2 should have been taken
> > from the trunk rather than from the RC branch and same thing for 21.3.
> 
> For 21.3, maybe.  But for 21.2, I disagree.  You effectively suggest to
> eliminate bugfix releases, which I think would be wrong: users will have 
> no stable versions to rely upon.

Rather I suggest that we don't have the manpower to have several
active branches at the same time and do a good job with it.
So if we wanted 21.2 to be a really good bug-fix release, we should
have concentrated on bug-fixing while keeping it on the trunk so
that everyone was working on bug-fixing exclusively.

> > As Dave has explained the bug-fix release 21.3 will still be riddled
> > with bugs
> FWIW, I think ``riddled with bugs'' is a grave exaggeration.

It all depends on what you consider as a bug, so I stand by my claim
that it will be riddled with bugs.  Most of them are not of the kind
that segfault and most of them cannot be trivially fixed (i.e.
fixed without a significant risk of introducing other bugs) so even if
we spend another 10 years on "bugfixing" the RC branch, those bugs
will still be there (even tho they might have already been fixed on the
trunk months ago).

> > Maybe it will be a bit
> > more stable from one particular point of view because it doesn't use any
> > new code that might introduce new bugs, but I'm definitely not convinced
> > that it outweighs the number of unfixed non-trivial bugs.
> 
> So do you really think that introduction of significant new features 
> doesn't destabilize Emacs?
> 
> That is, do you suggest to skip branch releases because they are not more
> stable _in_principle_, or just because we are too inept to make them
> significantly more stable?

They are only more stable in cases where there really is a significant
new feature that destabilizes the code base.  E.g. the new redisplay in
Emacs-21, or a unicode-based internal encoding for Emacs-22.
The kinds of changes that took place on the trunk since Emacs-21.1
don't justify the burden of branch-releases.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
> Date: Tue, 05 Nov 2002 13:39:40 -0500
> > 
> > IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> > not to release from the branch anymore.
> 
> Why is that ?
> Even if we feature freeze it now, 21.4 will not be out before the end
> of 2003.  I.e. long after 21.3.

If you suggest to have two pretests running in parallel, I don't think
we can manage that with the available resources.

> Rather I suggest that we don't have the manpower to have several
> active branches at the same time and do a good job with it.
> So if we wanted 21.2 to be a really good bug-fix release, we should
> have concentrated on bug-fixing while keeping it on the trunk so
> that everyone was working on bug-fixing exclusively.

That'd be a step back to the previous development model, I think:
there was no branches, and development would actually stop while bugs
in a major release were fixed.  It's possible to argue that we should
go back, but I thought the current model was supposed to make the
development faster and releases more frequent.

> > > As Dave has explained the bug-fix release 21.3 will still be riddled
> > > with bugs
> > FWIW, I think ``riddled with bugs'' is a grave exaggeration.
> 
> It all depends on what you consider as a bug, so I stand by my claim
> that it will be riddled with bugs.

My objection was to the ``riddled'' part, not to the ``bugs'' part.  I
don't think it's a fair description of the state of the code.

> > That is, do you suggest to skip branch releases because they are not more
> > stable _in_principle_, or just because we are too inept to make them
> > significantly more stable?
> 
> They are only more stable in cases where there really is a significant
> new feature that destabilizes the code base.  E.g. the new redisplay in
> Emacs-21, or a unicode-based internal encoding for Emacs-22.

I think this is too extreme: many changes on the trunk have enough
potential to destabilize the code.  So we obviously disagree.

Look, I'm not against faster development, I just think that with the
current manpower and without a full-time head maintainer we won't be
able to do much better.  We could improve the development on the trunk
or on the branch, but not both.  When I was working on the branch
releases, I felt that the trunk is favored more than the branch, which
IMHO is one reason why the bug-fix releases didn't happen frequently
enough.  (My hope was that we could release 21.2 a month or two after
21.1 and 21.3 a month after 21.2.)

Re: 21.2.90 pretest, 21.3, 21.4...

[Stefan Monnier]

> > > IMHO, it doesn't make sense to feature-freeze the trunk unless we decide 
> > > not to release from the branch anymore.
> > 
> > Why is that ?
> > Even if we feature freeze it now, 21.4 will not be out before the end
> > of 2003.  I.e. long after 21.3.
> 
> If you suggest to have two pretests running in parallel, I don't think
> we can manage that with the available resources.

feature-freeze != pretest.

> > Rather I suggest that we don't have the manpower to have several
> > active branches at the same time and do a good job with it.
> > So if we wanted 21.2 to be a really good bug-fix release, we should
> > have concentrated on bug-fixing while keeping it on the trunk so
> > that everyone was working on bug-fixing exclusively.
> 
> That'd be a step back to the previous development model, I think:
> there was no branches, and development would actually stop while bugs
> in a major release were fixed.  It's possible to argue that we should
> go back, but I thought the current model was supposed to make the
> development faster and releases more frequent.

Quite right.  I think we should go back, unless we find enough people
to volunteer.  Although, now that I think about it again, I disagree with
what I said before.  I can't remember precisely enough what stage we were
at when we started 21.2.  So maybe the way we did 21.2 was OK, because
21.1 was major enough to justify a bug-fix-only release.

But for 21.3, if it had been forked from the trunk rather than from RC could
have been overall just as stable as 21.3 is.
So I just think that all releases should be forked from the trunk
rather than from a previous release branch.  I.e. each release branch
leads to one and only one release (barring emacs-19.34 and 19.34a kind
of things, obviously).
That might have made the 21.3 debugging&pretest a bit longer but
would have made it more useful (we would have found some bugs which are
still right now in the trunk, unbeknownst to us) and people would
able to use some of the new features that were implemented two years ago.

The above reasoning might also apply for 21.2, but I can't remember
enough to be sure.

> > > That is, do you suggest to skip branch releases because they are not more
> > > stable _in_principle_, or just because we are too inept to make them
> > > significantly more stable?
> > 
> > They are only more stable in cases where there really is a significant
> > new feature that destabilizes the code base.  E.g. the new redisplay in
> > Emacs-21, or a unicode-based internal encoding for Emacs-22.
> 
> I think this is too extreme: many changes on the trunk have enough
> potential to destabilize the code.  So we obviously disagree.
> 
> Look, I'm not against faster development, I just think that with the
> current manpower and without a full-time head maintainer we won't be
> able to do much better.  We could improve the development on the trunk
> or on the branch, but not both.  When I was working on the branch
> releases, I felt that the trunk is favored more than the branch, which
> IMHO is one reason why the bug-fix releases didn't happen frequently
> enough.  (My hope was that we could release 21.2 a month or two after
> 21.1 and 21.3 a month after 21.2.)

Complete agreement.  I just think it's more important to concentrate
our manpower on the trunk than on the branch.


	Stefan

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Stefan Monnier wrote:

> > > Even if we feature freeze it now, 21.4 will not be out before the end
> > > of 2003.  I.e. long after 21.3.
> > 
> > If you suggest to have two pretests running in parallel, I don't think
> > we can manage that with the available resources.
> 
> feature-freeze != pretest.

Well, perhaps I misunderstood: what good is it to freeze the trunk unless 
we start a pretest?

> But for 21.3, if it had been forked from the trunk rather than from RC could
> have been overall just as stable as 21.3 is.

IIRC, it was a judgement call, and at the time it sounded like we could 
have 21.3 out the door in less than a month.  Given that assumption, it's 
not clear to me whether the decision was wrong.  (To make it perfectly 
clear, the decision was not mine.)

> So I just think that all releases should be forked from the trunk
> rather than from a previous release branch.

I could agree with that in principle.  But in reality, it could happen 
that the first release you make from the branch is not stable enough, 
and that in the meantime the trunk got several new significant changes 
that make it inappropriate for the next release.

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Mon, 4 Nov 2002, Juanma Barranquero wrote:

> Still, I wonder if we should try to pack less punch in each release, and
> release a bit faster than we're doing today.

As someone who was involved in pretest releases up until 21.2.90, I can 
assure you that the schedule for the releases was not determined by the 
desire to put ``more punch'', but simply by the availability of free time
to make the pretests and solve bugs reported by the pretesters.

> Also, it's tough trying to evangelize people when I know that some
> much-appreciated features are just in the HEAD and won't see the light
> in a year or two...

As long as we keep the scheme whereby bug-fix releases precede the
next development release, the time until the next release from HEAD
is largely determined by the amount of bugs we deem severe enough to
fix, and the available resources to fix them.  The only way to speed that 
up is to have more people working on the release branch.

> Of course, I don't know what we should do, other than attracting more
> people to Emacs development. Perhaps a tentative schedule like the one
> in GCC would be a first step, but I'm not sure.

Personally, I think it'd be a sad day when the quality of the released 
Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
think there was a released version without a couple of major bugs.  With 
all its limitations, I'd vote for what we have now in Emacs any time.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 5 Nov 2002 07:58:56 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> As someone who was involved in pretest releases up until 21.2.90, I can 
> assure you that the schedule for the releases was not determined by the 
> desire to put ``more punch'', but simply by the availability of free time
> to make the pretests and solve bugs reported by the pretesters.

In the case of the 21.2 and 21.3-to-be releases that's pretty clear, as
they carry no punch (meaning "features") and to all practical effects
apport just stability. (And no, I'm not understressing the immense value
of stability). Also, please don't think I don't value the effort you and
others put in each release. I do.

> As long as we keep the scheme whereby bug-fix releases precede the
> next development release, the time until the next release from HEAD
> is largely determined by the amount of bugs we deem severe enough to
> fix, and the available resources to fix them.  The only way to speed that 
> up is to have more people working on the release branch.

Well, yes. I think the most serious problem right now is the man-power
shortage; I'm not sure how many people is actively contributing, even in
small ways as I do, but we are few (or that's my highly subjective
perception).

Still, we're pretesting 21.3 since... when? March or April, at least?
There's really so big a list of problems with the pretests that we're
taking six months for a bug-fix release?

> Personally, I think it'd be a sad day when the quality of the released 
> Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
> think there was a released version without a couple of major bugs.  With 
> all its limitations, I'd vote for what we have now in Emacs any time.

Copying some of the procedures does not necessarily mean copying the
errors. Still, I believe that preplanning tentative schedules, even if
we miss then, should help a little. That, and of course convincing
people to focus their attention in the release branch and not the
development one while the release branch is in pretest time... :)

                                                           /L/e/k/t/u

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> Date: Tue, 05 Nov 2002 08:56:59 +0100
> From: Juanma Barranquero <lektu@terra.es>
> 
> Still, we're pretesting 21.3 since... when? March or April, at least?
> There's really so big a list of problems with the pretests that we're
> taking six months for a bug-fix release?

I explained elsewhere in this thread that mundane practical problems
caused this delay, in addition to real issues.  I'm sorry that I was
part of the reasons for the delay, but I do have a life.

I'm sure everyone knows that the way to speed up things is to
volunteer to make them happen.

> > Personally, I think it'd be a sad day when the quality of the released 
> > Emacs versions will be anywhere near GCC's.  Since GCC 3.0, I don't 
> > think there was a released version without a couple of major bugs.  With 
> > all its limitations, I'd vote for what we have now in Emacs any time.
> 
> Copying some of the procedures does not necessarily mean copying the
> errors.

I think it does mean that.  But this is a different discussion, so I
suggest we drop it for now.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 21:54:22 +0300
"Eli Zaretskii" <eliz@is.elta.co.il> wrote:

> I explained elsewhere in this thread that mundane practical problems
> caused this delay, in addition to real issues.  I'm sorry that I was
> part of the reasons for the delay, but I do have a life.

If I´ve made it sound like I was looking for a culprit or disregarding
in any way yours or anyone´s contribution or (sometimes huge) amount of
work in this project, I´m really sorry.  It´s not so.

> I'm sure everyone knows that the way to speed up things is to
> volunteer to make them happen.

Yes, of course. But sometimes it´s not clear what can you volunteer for.
I alredy fix bugs I think I know how to fix, for example.

> I think it does mean that.  But this is a different discussion, so I
> suggest we drop it for now.

OK.

-- 
Juanma Barranquero <lektu@terra.es>

Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

On Tue, 5 Nov 2002, Juanma Barranquero wrote:

> > I explained elsewhere in this thread that mundane practical problems
> > caused this delay, in addition to real issues.  I'm sorry that I was
> > part of the reasons for the delay, but I do have a life.
> 
> If I´ve made it sound like I was looking for a culprit or disregarding
> in any way yours or anyone´s contribution or (sometimes huge) amount of
> work in this project, I´m really sorry.  It´s not so.

It's true that I sometimes take offense where others don't, but in this 
case, you have nothing to apologize for: your wording didn't come 
anywhere near any disregard.

I simply wanted to explain why the delay happened.  I truly _am_ sorry 
that my personal life interfered.

> > I'm sure everyone knows that the way to speed up things is to
> > volunteer to make them happen.
> 
> Yes, of course. But sometimes it´s not clear what can you volunteer for.

There are a few mundane tasks involved in a pretest: making the tarballs 
and xdelta's, testing and uploading them, tracking the reports by 
pretesters (like on which systems they built successfully, what 
outstanding bugs are still unsolved, etc.).  When there's a major 
modification in the manuals, there's typically a need to record what 
pages were reviewed and how many times, to ensure coverage.  Etc., etc.

> I alredy fix bugs I think I know how to fix, for example.

If we want more frequent releases from the stable branch, bugs on the 
branch should get priority, or at least there should be enough people 
working on them to ensure they are fixed almost immediately.

Ideally, there should be a new pretest once a week.  We are still very 
far from that goal, I think; anything that helps us move toward that is a 
welcome change.

Re: 21.2.90 pretest, 21.3, 21.4...

[Richard Stallman]

I think 21.3 may be just a few weeks away.

      I fear that this (totally
    apparent, but public perception counts) stagnation can lead people to
    other editors, or (worse, although more improbably) more Emacs branching.

It is easy enough for people to see in CVS what we are working on.
I don't think this is a real problem.

Re: 21.2.90 pretest, 21.3, 21.4...

[Juanma Barranquero]

On Tue, 05 Nov 2002 23:49:50 -0500, Richard Stallman <rms@gnu.org> wrote:

> I think 21.3 may be just a few weeks away.

I'm glad to hear that.

> It is easy enough for people to see in CVS what we are working on.

I couldn't count with both my hands the amount of friends I have that use
Emacs routinely, but have never been nowhere near the Emacs CVS, and
*do* have the perception that Emacs releases are few and far between...

Still, I don't know if that's a problem or not. What *is* a problem is
the fact that we are unable (or at least relatively unsuccessful) to
attract more people.

                                                           /L/e/k/t/u