On Tue, Apr 28, 2015, at 22:12, Anthony Towns wrote:
> 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?
This sort of breaches similar ground to something I was considering
proposing a talk at Debconf15 about, i.e. ways to increase the
maintainbility of debian-stable and the flow of fixes to stable, without
increasing the burden on the stable release manager to painful levels...
> 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...
I think I will put forward a proposal for the -stable side of this, but
it will be far more geared toward human processes than the automation
side of things.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond where
the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes
Holschuh <h...@debian.org>
