I would like to ask you interested in our next release to stop and look at 'testing' for a while. I believe that now, during the start of a development cycle and during debcamp/debconf we've a interesting opportunity to review pros and cons of our current approach.
We believe that 'testing' means that things shouldn't break as badly as in unstable or experimental. That's important understand the automatic update concept of unstable and the experimental non-automatic nature. In other words use unstable means that upgrade is dangerous, use unstable and experimental means that you pick how much more of the danger you want from there (experimental). Let me outline the 'testing' pros and cons from my point of view: pros ----- * testing is under control of release team, it's supposed to be harder to a random developer break our next release * testing is our 'daily updated' release snapshot cons ----- * testing metric is too simple, packages are allowed to enter testing only after a certain period of time has passed no matter if much people tested it before that and just when they don't have release-critical bugs filed against them. * developers and most active contributors are pretty much using only stable or unstable and not testing. I've two different proposals to address the cons trying to avoid as much as possible create new cons, they are: 1) The 'remove experimental' proposal * Warn developers and contributors[0] * Remove experimental * Switch unstable (release) for not automatic updates [0] = This warning should contain the hint for contributors switch from unstable to testing and those who want to pick unstable stuff do like we do today with experimental. The benefit of the approach above from a RM point of view is that we will have more eyeballs over testing and it doesn't mean that we will have less people using unstable pieces. 2) The 'remove testing' proposal * Add enough experimental autobuilders for our target architectures * Warn developers and contributors that experimental is for transitions and adopt a sort of 'if in doubt upload to experimental' approach. It's really important The developers and contributors might keep using unstable and some pieces of experimental. Things will get harder during freeze, but I believe it's still better than we've today unless developers and contributors don't cooperate out of freeze and ignore the 'experimental if in doubt' approach. Note that it reduces RM team power during the development cycle, the first suggested approach doesn't. be cool, -- stratus http://stratusandtheswirl.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]