Re: 21.2.90 pretest, 21.3, 21.4...

[Eli Zaretskii]

> From: "Stefan Monnier" <monnier+gnu/address@hidden>
> 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.)