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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]