[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 21.2.90 pretest, 21.3, 21.4...
From: |
Eli Zaretskii |
Subject: |
Re: 21.2.90 pretest, 21.3, 21.4... |
Date: |
Tue, 05 Nov 2002 22:17:25 +0300 |
> 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.)
- Re: 21.2.90 pretest, 21.3, 21.4..., (continued)
- Re: 21.2.90 pretest, 21.3, 21.4..., Miles Bader, 2002/11/06
- Re: 21.2.90 pretest, 21.3, 21.4..., Francesco Potorti`, 2002/11/07
- (no subject), Kenichi Handa, 2002/11/07
- Re: (no subject), Richard Stallman, 2002/11/08
- Re: 21.2.90 pretest, 21.3, 21.4..., Francesco Potorti`, 2002/11/07
- Re: 21.2.90 pretest, 21.3, 21.4..., Richard Stallman, 2002/11/09
- Re: 21.2.90 pretest, 21.3, 21.4..., Juanma Barranquero, 2002/11/06
- Re: 21.2.90 pretest, 21.3, 21.4..., Kai Großjohann, 2002/11/06
- Re: 21.2.90 pretest, 21.3, 21.4..., Eli Zaretskii, 2002/11/06
- Re: 21.2.90 pretest, 21.3, 21.4..., Stefan Monnier, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4...,
Eli Zaretskii <=
- Re: 21.2.90 pretest, 21.3, 21.4..., Stefan Monnier, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4..., Eli Zaretskii, 2002/11/06
Re: 21.2.90 pretest, 21.3, 21.4..., Eli Zaretskii, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4..., Juanma Barranquero, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4..., Eli Zaretskii, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4..., Juanma Barranquero, 2002/11/05
- Re: 21.2.90 pretest, 21.3, 21.4..., Eli Zaretskii, 2002/11/06
Re: 21.2.90 pretest, 21.3, 21.4..., Richard Stallman, 2002/11/05
Re: 21.2.90 pretest, 21.3, 21.4..., jasonr, 2002/11/06