Re: Release update: minor delay; no non-RC fixes; upgrade reports
On Fri, May 27, 2005 at 11:57:52PM +0200, Andreas Barth wrote:
>...
> Timeline
> --------
>...
> 1 June 2005
> ~15 RC bugs (excluding security bugs)
> 0 RC bugs not tagged "sarge"
>...
How do you measure RC bugs?
If you only look at the output of the BTS - that's horribly wrong.
Why?
Because many bugs that are already fixed in sid and therefore closed are
still present in sarge.
Finding these issues is one of the prices for freezing testing
instead of unstable [1].
Since it seems noone of the release team bothered to pay this part of
the price for the testing release process, I'm sometimes using one or
two spare hours to go a bit through update_excuses and report half a
dozen of such issues.
Steve saw this, and before the latest release update he sent (which was
the one before yours), he asked me in a private mail about a prediction
how many such RC bugs I'd expect in sarge for inclusion in his release
update.
It seems my prediction about the number of such issues didn't match his
wishes regarding the state of sarge, and he did therefore neither answer
my email nor mention this in the release update nor does it seem he
assigned a member of the release team to do this work properly.
If you are using the testing release process, please do the work that is
required for doing it properly.
And if you'd have done it in time these issues were no longer present
now that you announce the release date was only a few days ahead.
> Cheers,
> Andi Barth
TIA
Adrian
[1] And no, version tracking in the BTS wouldn't prevent this problem.
In my experience, there are so many of these issues reported with
a wrong version or manually closed or even without any bug report in
the BTS that claiming version tracking might eliminate this problem
sounds like a bad joke.
--
"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: