Re: testing and no release schedule
On Fri, Mar 26, 2004 at 04:58:37PM +0000, Colin Watson wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> > There are always reasons to say "hey, we managed to get A, B and C into
> > testing, and the next goals are getting D, E and F into testing". But is
> > this real progress towards the next stable release, or will after F is
> > achieved only G, H and I arrive?
>
> It is clearly frustrating for us when we manage to heave a huge pile of
> improvements into testing only to find that people say "oh, but you
> can't release stable yet because <major-project> <major-new-version> has
> just been released".
That's similar to my opinion that it's of limited value to fix bugs etc.
before the beginning of a freeze.
If there's a freeze announced early enough all maintainers know that
after this date no major changes are allowed. All "<major-project>
<major-new-version>" have to simply be ignored after this date.
> At the same time, we *have* to have a working installer; anything else
> is just not an option. To some extent, the exact details of what version
> of everything else we release with is a distraction, and is certainly
> much more easily solved. (Not meaning to demean anyone's efforts, of
> course, but I think it's clear that "our installer doesn't work yet"
> usually overrides "we don't have a new enough version of <foo>".)
That's clear.
Looking at the past, it might perhaps have been worth to check at the
time of the release of Debian 3.0 whether the new installer would be
ready in time for Debian 3.1, or whether this would have better been a
Debian 3.2 project with parallel work to get the woody installer working
in Debian 3.1. But that's a past experience that might be a worthwhile
experience for the future.
> > It's quite frustrating that there's no clear schedule towards Debian 3.1
> > that includes a date for the beginning of the freeze.
>
> I'm sorry that there hasn't been a schedule posted since the 15th. This
> is mostly because the release team have been working flat-out on other
> things (I've been trying to make d-i work releasably on powerpc, and I
> believe the same goes for Steve and d-i on alpha).
>
> A new announcement is being prepared now, and should be available by
> this weekend.
>...
Is it possible to either publically or privately discuss the
announcement with you before it's released?
The final decision is at the release manager, but I'd prefer to give
comments and critics before it's officially released instead of later.
> > After the beginning of a freeze, there need to be several months to
> > fix all bugs that get reported over time and to ensure that both new
> > installations of Debian 3.1 and upgrades from Debian 3.0 to Debian 3.1
> > work for everyone without problems.
>
> However, long freezes are also problematic. They impede development and
> cause much frustration: the potato freeze was a good example of this.
The woody freeze wasn't shorter.
The main question is perhaps what Debian's main focus is:
An always up-to-date unstable or a rock-solid stable?
You can't have both.
A rock-solid stable requires much testing (including many newly reported
bugs) after the beginning of the freeze.
Several months after the freeze are required with all Debian developers
focussing mostly on frozen to create a stable the is as good as Debian
users are used to.
> > The latest "Release update" [1] said "On or shortly after 15th March,
> > we'll see if these targets have been met and update the schedule
> > accordingly.". I sent on March 15th a suggestion of a "weak freeze" and
> > how I'd help within it for unstable [2] plus two additional mails to the
> > release managers and his assistants. I got one mail from you (Steve)
> > stating that "At a glance, I don't see anything in the plan that
> > conflicts with the Release Team's agenda." and that you wanted to answer
> > during the next days a week ago, but no other feedback until now.
> >
> > I'm not claiming that my suggestion of a weak freeze of unstable is the
> > only way to get closer towards Debian 3.1, but I'm a bit astonished that
> > although it was announced that "shortly after 15th March" there will be
> > an update of the release schedule, none of the release managers and his
> > assistants had the time to either send an updated release schedule or to
> > give an "yes" or a "no, we have a better plan" answer to my suggestion.
>
> See above. I'm sorry that "shortly" has slipped more than we intended.
> On the other hand, I'm not keen on the "I'll fix bugs when we freeze"
> attitude; this is a chicken-and-egg situation. Bugs need to be fixed
> *now* so that we can freeze with the confidence that we know
> approximately how long the freeze will need to last.
>...
Many bugs currently present aren't yet reported.
I wouldn't agree that the focus on the number of RC bugs in testing is
really the right metric to estimate the release date on.
Besides this, noone has counted the number of RC bugs that are present
only in testing since they were already fixed in unstable.
> > In the pre-testing times there was one release manager who announced a
> > freeze date, and at that date unstable was frozen and at about half a
> > year later there was a new stable release. Today, there are 4 people
> > that do release management, but it seems neither possible to do any
> > estimate when Debian 3.1 will release, nor does it seem that the
> > release speed improved.
>
> Remember that the difficulty of release management has increased very
> substantially since the old days, due to the many-times-over increased
> size of the distribution and the more and more labyrinthine nature of
> our dependency structure. This consumes a great deal of release
> management time, although the large-scale automation of testing makes
> the job possible.
First of all, I want to say that although I'm not a fan of freezing
testing, it's definitely possible to use testing to get to a new stable.
The "large-scale automation of testing" tracks some issues and solves
some problems, but it also creates new problems that weren't in
unstable. As an example, check the state of xfig/transfig in testing two
days ago that made both packages useless for most purposes.
And when looking at how much manual work is always required to keep
testing in a usable shape, I have yet to see a comparison that shows
that testing is really an improvement regarding the work required
and/or the time needed to get a new stable release.
> Cheers,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: