Re: Two proposals for a better Lenny (testing related).
On 6/11/07, Joey Hess <joeyh@debian.org> wrote:
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.
Yes, let me make clear it wasn't a statement against RM team work or
the amount of time invested coding testing related scripts. It was a
call to evaluate the results.
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/
Sorry, i forgot CUT it looks like a 0 proposal since it came first.
How and when do you plan to start a team for that and have you
considered who from other teams will need to join/agree on the idea?
> * developers and most active contributors are pretty much using only
> stable or unstable and not testing.
What's your data?
I'm asking around since 2004 and just a few said that they're using
testing on their desktops or laptops, a rarely used test machine
running testing doesn't count, IMHO. For example faw said 'yes, I'm
running testing since I found out that just a few contributors and
developers are actually really using testing'.
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
(...)
(For bonus fun, someone could graph how these change over time..)
Any idea on how to collect more reliable data in a opt-in base? Does a
survey on pentabarf (or public acessible) during debconf makes sense?
> 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.
Wrong, if I'm asking for experimental removal I'm assuming that
there's not a lot of people using that. Considering the rest of your
argument, definitely a lot of people will use testing instead this
'new unstable'. Do you see?
If you want more users to use testing, see CUT.
Looks like a interesting proposal too.
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.
You're missing the "I'm on the edge" feeling. People won't use testing
just because testing is testing even if you've tons of tools to
develop and test everything over unstable. I pretty much believe
that's possible today, but I'm yet to hear somebody that moved from
unstable to testing because there's a possibility to test testing and
develop for sid.
> 2) The 'remove testing' proposal
Amoung many other problems this postpones most work on the installer until
the release it will install is frozen.
Could you or somebody else please list some of them?
thanks,
-- stratus
http://stratusandtheswirl.blogspot.com
Reply to: