Re: Bits (Nybbles?) from the Vancouver release team meeting
On Sat, Mar 19, 2005 at 04:19:03AM -0800, Steve Langasek wrote:
>
> > Which delays are expected for etch, that are not only imposed by the
> > usage of testing for release purposes? [1]
>
> > I do still doubt that testing actually is an improvement compared to the
> > former method of freezing unstable, and even more do I doubt it's worth
> > sacrificing 8 architectures.
>
> If the proposal already gives porters the option to freeze ("snapshot")
> unstable to do their own releases, in what sense is this "sacrificing"
> architectures?
Well, producing a release from a "snapshot" of unstable in a way that's
at least roughly comparable with current stable releases on this
architecture are:
- release management
- security support
Freezing for one architecture from some snapshot of unstable is roughly
comparable to a complete release process you as a release team are
doing. But it's worse. One email from you to d-d-a "We will freeze in
two months, please don't do big changes and stabilize your packages
instead." results in an unstable (and therefore a testing) that's in a
relatively good shape at the start of the freeze [1]. And after the
start of the freeze, most maintainers will work on stabilizing the
frozen packages instead of putting new versions into unstable. Yes, this
doesn't work 100%, but it still distributes a serious amount of work
from the release team to all maintainers. How much of this work will be
distributed away from the porters if they announce: "The m68k team will
release based on an unstable snapshot taken two months from now."?
And assuming you want to use such port specific releases on computers
that have more than one user and/or that are connected to any network,
you need security support. Joey (who should know best) already explained
that for the security team it doesn't matter whether much they have to
support 2 or 20 architectures within a release, but every additional
distribution causes a lot of extra work for them. Whom do you want to
put the burden for security releases of the 8 sarge architectures you
expect to not release with etch on? Should the security team carry this
burden, or should every porter team form their own security team
releasing their own DSA's?
That's so much extra work for every single port that makes it nearly
impossible for architectures to achieve what they get if they are in the
regular release process that it's nearly impossible.
> It sounds to me like it's exactly what you've always wanted,
> to eliminate testing from the release process...
>...
Yes, I'm not a fan of testing.
But I do understand how testing works.
Both my previous emails in these threads and this emails aren't emails
simply "testing bashing" emails without real contents. I'm trying to
point at the weaknesses of a release process with testing - like every
other release process, it has both advantages and disadvantages.
Testing has it's advantages.
You know that all packages have there dependencies fulfilled [2], were
built on all architectures, and some kinds of bugs are less likely to
make it into testing.
There were many release updates the release team sent that mentioned as
a major success that transition A is now finally into testing and it was
hoped that transition B will go into testing soon. How many weeks did it
took altogether that were spent getting transitions into testing that
were already completed in unstable? And how many hours have members of
the release team spent for hints, coordinating between maintainers etc.
for getting these transitions into testing? These are extra costs of
testing.
And you explained in your announcement that removing approx. 8 of the
current architectures from the release process "... will drastically
reduce the architecture coordination required in testing, giving us a
more limber release process and (it is hoped) a much shorter release
cycle on the order of 12-18 months."
IOW:
You are saying the current release process with testing has problems
that make it impossible to achieve a release cycle on the order of 12-18
months with many architectures.
One possible solution for this problem you observed is reducing the
number of architectures.
Another possible solution for this problem is to switch to a release
process without testing.
cu
Adrian
[1] This was more effective if freeze announcements weren't sent 6 days
before the freeze, but it's your choice as release manager to not
take the full advantages of early announcements.
[2] but build dependencies are still not tracked
--
"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: