Re: testing and no release schedule
On Fri, Apr 02, 2004 at 05:05:52PM +1000, Anthony Towns wrote:
> On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> > Before testing was invented, it was also a goal that testing should be
> > always in a releasable state. Practice has shown that this goal was
> > never reached.
>
> Uh, the phrase is "has not been reached".
>
> There are two main reasons for that: one is it's essentially impossible
> to install testing, although we might see that one solved after sarge
> is released with d-i. The other is that there's no security support
> for testing, and there's still no prospect of that changing.
The first issue you mention isn't an issue for people who upgrade from
the current stable.
And even many people who don't care that much about security were not
always happy about testing since it still often has problems.
There are other problems that are not external but problems with testing
itself:
E.g. for some time, there was an unusable mixture of GNOME 1 and GNOME 2
in testing.
And there are far more serious bugs in testing than in stable, e.g. I
personally know a person who had serious mail loss because of #220983,
and the cyrus-imapd/libc6 combination causing this problem was in
testing at this time.
>...
> > I have yet to see any objective evaluation whether testing really is an
> > improvement.
>
> potato's release was held up by RC bug fixing -- b-f's was working
Not only RC bugs fixing.
There were also two months spent in three test cycles. During the first
two test cycles several bugs were discover that were fixed before
Debian 2.2.
This wasn't "bug fixing", it was "bug finding", and the thorough
testing contributed to the good quality of potato.
>...
> > It's quite frustrating that there's no clear schedule towards Debian 3.1
> > that includes a date for the beginning of the freeze.
> >
> > When talking about a clear schedule, I'm not talking about something
> > unrealistic like the schedule that told Debian 3.1 would be released on
> > Dec 1st 2003 that included dates that were not based on any realistic
> > estimates (esp. the installer dates).
>
> Any estimate that predicts how development work goes isn't going to be
> accurate; the only way you get good schedules is by letting yourself
> make the schedule /independent/ of whether development gets completed
> in a timely manner or not. testing aims to do that for most of the distro:
I'm wondering why the Debian 3.1 schedule is so tightly coupled on _one_
external source (the Debian installer), but lets nearly no time for
testing after actual freeze.
> it lets people who can make stuff work quickly keep uploading on their own
> schedule, and people who can't get dropped and kept out of the release until
> they fix their bugs.
>...
The many package removals are not something I'm a fan of.
During the potato freeze, it was always clear which package might be
removed long before.
With testing, packages get removed every day because their maintainer is
lazy or MIA (which says nothing about whether there are users requiring
this package) or even only to make a library transition possible.
I'm not concerned about "very important" packages like Gimp. I'm more
concerned about one package here and one package there like users are
asking "Why is gnuchess not in Debian 3.0?". I have sometimes the
impression removing packages should in some way punish the maintainer.
But in the end it only punishes the users of Debian, and this in turn
punishes Debian.
Things are even worse if packages that might require security fixes and
that were present in earlier stable releases are no longer present
since this could result in people silently loosing security upgrades
(when doing a dist-upgrade you don't notice if a few packages aren't
upgraded). In potato there was one such case (smail), and it was
explicitely covered in the release notes.
> > Fixing bugs is not very effective as long as
> > there'a no freeze and new upstream versions with new bugs flood into
> > testing every day.
>
> If you think this is a major problem work on ensuring programs with bugs
> are found and fixed in unstable, or beforehand.
This doesn't reduce the continous stream of new bugs and problems
introduced by new upstream versions. And it often takes a month or two
until some serious bug is discovered and reported.
> Cheers,
> aj
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: