Re: 21.2.90 pretest, 21.3, 21.4...

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> > > 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