[cut-team] Ideas for the rolling release

[Lucas Nussbaum]

On 16/08/10 at 14:16 -0500, Anthony Towns wrote:
> I /think/ Lucas's concern is more along the lines of "it's perfectly
> usable, but it's boring because neat new stuff takes too long to get
> there".

Not really. I'm fine with the current tradeoff in testing, with a few
exceptions. For example, a workaround to get chromium earlier in testing
would have been nice. That's the kind of changes I would have liked to
see done in rolling compared to current testing. The message that would
be sent to maintainers when testing is not frozen would be:
"rolling normally uses the same packages as testing, but if your package
doesn't migrate to testing for some reason, talk to us and we might get
it in (through a rebuild against rolling to workaround a transition, or
by forcing it in, causing a breakage on some architectures)."

> Well, I expect that they'd accept patches, and I'm pretty sure I could
> still put some together -- I just don't have any ideas on new metrics
> to apply to testing that would be particularly
> interesting/informative/whatever.
> 
> Having a new suite is fine -- but without the metrics how do you tell
> it's actually doing better? How will you show people it's not just a
> matter of it being your baby, and therefore you think it's the cutest
> thing ever?
> 
> (For testing, we had the criteria of RC bug count and individual
> package installability, you can compare the green and red lines on
> bugs.debian.org/release-critical to see how bug count worked out, and
> britney generates uninstallability counts and puts them under
> http://release.debian.org/britney/ so you can track the other)

Interesting question. Since rolling is a tradeoff between up-to-dateness
and usability, we need metrics on both sides.
For up-to-dateness, we could use something DEHS-based to measure how far
we are from the current upstream state, and from unstable (see
http://dehs.alioth.debian.org/stats.html).
For usability, we would need to combine EDOS results and the RC bug
count.

- Lucas