Hi,

(I'm attempting to bcc: -release, but leave discussion on -devel)

Back during the freeze, there was a discussion on -private ("Please respect
Freeze Policy") about uploading new stuff to unstable (vs experimental or
testing-proposed-updates). I'm going to summarise the overall goal as "are
there any good ways in which unstable can be more pleasant during the
freeze for people who want to keep running unstable" -- eg, "I run unstable
so I can keep up with cool upstream stuff, but people stop uploading cool
upstream stuff during the freeze". Obviously, in improving things here, it
shouldn't make things harder for people working on the release (either the
release team or the other developers working on related packages).

A few ideas were proposed, including:

 - RM approval should be required before packages get into
testing-proposed-updates, rather than only for the testing-proposed-updates
to testing step

 - uploads to t-p-u should have their bug fix claims checked (ie, that one
of the bugs the uploads claims to fix is an RC bug that's present in
testing; that all the bugs have already been fixed in an upload to unstable)

 - testing users should be encouraged to run apt-listbugs and include t-p-u
in their sources.list

 - packages should be able to be migrated from experimental to unstable,
rather than requiring a separate upload

 - during the freeze, uploads to unstable that bump sonames should be held
for RM review (or that will otherwise prevent new uploads of other packages
to unstable from being suitable for promotion to testing)

​ - add automated testing for t-p-u (piuparts, ci.d.n?)

 - remove uploads from t-p-u if an RC bug is found in them?

​Do folks think those things are worth investigating further, and in
particular, would ftpmaster and the release team ​be interested in
reviewing/accepting patches along those lines or are there showstoppers
with the ideas themselves?
​
​I guess the other interesting questions are something like:

 - "are there any obvious ways in which the freeze could be shortened?"
 - "are there any obvious ways the freeze brought on earlier, without being
lengthened?"
 - "are there any obvious ways in which the ​release team's workload during
the freeze can be reduced?"

I was wondering if maybe it'd be possible to do some sort of statistical
review of uploads accepted to testing during the freeze (how many RC bug
fixes required more RC bug fixes, how long it took for library transitions
to get in sync, etc) and get some ideas for those things. Otherwise,
nothing much jumped out at me...

Cheers,
aj

-- 
Anthony Towns <a...@erisian.com.au>

Reply via email to