Gustavo Franco wrote:
> * 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.
Of course we have a team of RMs who are able override that and apply as
complex a metric as you'd like on a special-case basis. As well as
urgency=high in the changelog.
The tendency of dependency chains can block transitions, and keep RC
bugs open unduely long in testing is a much worse problem with speed of
testing migration. Testing also needs periodic snapshots and guaranteed
upgradability to be useable by more users, amoung other points I discuss
at http://kitenet.net/~joey/code/debian/cut/
> * developers and most active contributors are pretty much using only
> stable or unstable and not testing.
What's your data?
A fun though not entirely reliable data source is the "APT prefers"
lines inserted by reportbug in bug reports. A quick grep[1] of the BTS
gives:
51988 APT prefers unstable
30351 APT prefers testing
2076 APT prefers stable
420 APT prefers experimental
373 APT prefers testing-proposed-updates
220 APT prefers oldstable
190 APT prefers proposed-updates
60 APT prefers dapper-updates
50 APT prefers dapper
30 APT prefers breezy-updates
24 APT prefers edgy-updates
17 APT prefers breezy
16 APT prefers feisty-updates
13 APT prefers edgy
10 APT prefers hoary-updates
10 APT prefers feisty
10 APT prefers breezy-security
7 APT prefers sarge
7 APT prefers etch
7 APT prefers dapper-security
(For bonus fun, someone could graph how these change over time..)
> 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.
This assumes that experimental is used by a lot of people, which I
doubt, especially given the default apt pins and the numbers above.
Experimental is already only rarely uploaded to -- 1 in 20 packages have
a version in experimental (some of them outdated). I've seen plenty of
cases of developers complaining that they uploaded to experimental and
got too little additional testing from doing so. Moving the line between
experimental and unstable might drive some people to testing, but I
don't feel it will be many, especially as many developers upload even
risky changes to unstable already.
If you want more users to use testing, see CUT.
If you want more developers to use testing, I firstly don't entirely see
the point, but providing better tools for developers to develop for
unstable while using testing might help.
> 2) The 'remove testing' proposal
Amoung many other problems this postpones most work on the installer until
the release it will install is frozen.
--
see shy jo
[1] joeyh@merkel:/org/bugs.debian.org/spool/db-h>find -name \*.log | xargs grep 'APT prefers' | uniq | sed -e 's/.*: *//' -e 's/ *$//' | sort | uniq -c | sort -rn
Attachment:
signature.asc
Description: Digital signature