Re: Two proposals for a better Lenny (testing related).
Gustavo Franco wrote:
Let me outline the 'testing' pros and cons from my point of view:
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.
Packages won't transition if they are not ready. This can mean: not built on
all release archs, not installable in testing, making other packages in
testing uninstallable, having more RC bugs in unstable than in testing or not
waiting long enough in unstable. The Release Team can force packages in, block
packages from going in, change the waiting time and hint some packages to go
in together.
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
Which would remove a testing ground which doesn't influence the releasability
of a package. People are urged to upload to experimental if the version
they're uploading is not meant to transition to testing. I don't see what
advantage removing experimental has?
* Switch unstable (release) for not automatic updates
They are only automatic as far as the Release Team wants them to be as
explained earlier...
[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.
This might be better solved by CUT IMHO.
2) The 'remove testing' proposal
* Add enough experimental autobuilders for our target architectures
There are experimental autobuilders for all archs.
* 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
This is more or less what unstable is meant for at the moment...
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.
That's a status quo AFAICS.
As a Release Team we are thinking about solutions to improve testing migration
like using versioning instead of less RC bugs, better udeb handling, automate
easy hinting, ease library transitions etc. which would IMHO help CUT.
Cheers
Luk
Reply to: