Two proposals for a better Lenny (testing related).
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
Reply to: