In article <[EMAIL PROTECTED]> you wrote: : We need to think about what kinds of thing need to happen to a package : or to a distribution before we release it as `stable'.
Yes. I find it impossible to completely divorce the conceptual model from any reference to details of the present or any proposed implementation, but I'll give it a try. One of the difficulties we have right now is that, whether we admit it or not, we have a three-phase distribution mechanism. The first is "pre-unstable" which is currently made up of the Incoming directory, and files that get parked on a number of sites around the world because some users want these packages, and the delay through Incoming for a new package is large. The second is 'unstable', which as many have pointed out is often not very unstable at all... but it can get that way from time to time. The third is the 'stable' tree, which has value for folks who want to press CD's, but is not of much interest to anyone I've met who is net-connected. The problem with 'frozen' is that it's a release candidate whose rules for formation and maintenance are such that for a time, at least, it was far less stable than 'unstable'! It is also unfortunate, but predictable, that with our current process for freezing and releasing from 'unstable' that we end up with this release-candidate sitting around for many months... which is insane. In one of the proposals that is floating around, that incorporates some ideas I posted earlier along these lines, this three-phase nature of what we do becomes more explicit. The 'unstable' tree becomes just what it says it is. Any new package from a registered developer moves instantly from Incoming to unstable. What we have called 'unstable' in the past gets a new name, like 'unreleased' or 'pre-release' and in effect is a continuously-available release candidate that all developers would be expected to be running and which therefore would get lots of ad-hoc testing. Incoming -> unstable -> unreleased -> stable The "Incoming -> unstable" transition is instant. The "unstable -> unreleased" transition applies all the structural rules for a stable release (dependencies, lintian rules checks, etc), and requires that the version in unstable have been present without new bug reports for some period of time. The "unreleased -> stable" transition is performed by the release engineer when the unreleased tree is in a good state and the clock ticks the appropriate hour. Thus, the release process from 'unreleased' to 'stable' would be a much less momentus event... and would, for the most part, be the act of freezing a snapshot of the current release candidate, perhaps tweaking the one or two items like installation media which tend to get last-minute attention before a stable release. Everybody wins! Those who want/need bleeding edge stuff don't have to look so hard for it. Those who want a stable release that doesn't break structural expectations get that. The testing job gets easier because more people are helping. The release manager has an easier job because there's always a release candidate around in good condition. I'm already on record as being willing to help code some of the process changes that a scheme like this would require... but I think we ought to get hamm out the door, first... and soon. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]