Re: It is time for a feature freeze (it is NOW or never).

[Stefan Monnier <monnier@iro.umontreal.ca>]

> (1) Release the current RC branch as 21.4.

I don't consider it very useful, but if people want to spend their time on
it I can't stop them.

> (2) Feature freeze on HEAD.
> (3) Merge HEAD into RC branch, and make it 21.4.50.
> (4) Merge Unicode branch into HEAD, and make it 22.0.0.
> (5) Start pretest of 21.5 based on RC.
> (6) Release RC branch as 21.5.
> ...
> (7) Feature freeze on HEAD (i.e. Unicode version)
> (8) Merge HEAD into RC branch, and make it 22.0.50.

I'd offer a very slightly different schedule:
(2) Feature freeze on the trunk NOW
(3) Start pretest from the trunk (maybe after fixing known bugs, but there
    doesn't seem to be many of those, so it seems unnecessary).
(4) When bug-fixing starts to slow down such that some developers feel bored,
    make a new RC branch and move the bug-fixing and pretesting there.
    Those people who are bored can start playing on the trunk again.
(5a) Finish bug-fixing RC and finally Release.
(5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the
    trunk.  Branches basically don't get any testing and waste too much of
    our energy with merging, so we should only keep them for code that's
    really unstable or that we don't know whether we'll ever include.
    E.g. if bidi only crashed when you set enable-bidi-display, then it's
    ready for inclusion.
    I'd also like to see the emacs-xft (anti-aliasing) merged in, but AFAIK
    it's not ready yet.
(6) Almost immediately after that: goto number (2).

Note that the plan above tries to reduce the amount of "parallel
development" for two reasons:
- we need to make sure people focus on fixing bugs during the pretest.
- we don't have the manpower to work and test many branches at the same time,
  let alone keep them uptodate w.r.t the trunk.

> Do you intend to skip (1)?  Perhaps, that will be better
> because we can avoid disappointing users who exepect new
> features in the release of this long delay.

Agreed.

> I agree.  But, I think bug-fixing work for 21.5 (or 21.4)
> must be done on RC branch so that (4) can be done promptly
> and we can have more users of Unicode version, which boosts
> the release of 22.1.

You have a point but I think we should only do it when the bug-fixing
frenzy slows down (hopefully this will happen very quickly).
But of course, as soon as the bugs left over are "none of your business",
you'd better start merging rather than twiddle your thumbs.


        Stefan