[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Stetch goal: improvements to testing-proposed-updates / experimental?



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 <aj@erisian.com.au>

Reply to: