On 29/04/2011 14:21, Stefano Zacchiroli wrote: > On Thu, Apr 28, 2011 at 10:55:01PM +0000, Philipp Kern wrote: >> On 2011-04-28, Raphael Hertzog <hert...@debian.org> wrote: >>> But I don't plan to work on any of those if the project does not agree to >>> promote testing to something that can be advertised as usable by end-users >>> and as something that we strive to support on a best-effort basis. >> >> It's already the case that you can go and send a mail to debian-release@ that >> package X needs to be put into testing more quickly than the set urgency or >> asking for permission to upload to t-p-u to fix bugs if the upload is >> entangled. And apart from that it's supported on a best-effort basis already >> with bug fixes trickling from unstable into it and critical stuff being >> fixed faster. > > Sure. But the procedures you mention above all require work from the > maintainer + the release team, while they would require work only from > the maintainer in the (hypothetical) "rolling" scenario. Under heavy > load periods for the release team---not only freezes, but also periods > with a huge stack of transitions to be completed---the presence of an > extra participant might easily become a bottleneck inducing more work > (and stress) on everybody shoulders and more delays. >
In the (hypothetical) "rolling" scenario¹, one should still follow the same procedure to get the package speedy-migrated (or uploaded to r-p-u, if applicable). So, I don't see where you're winning. I could be missing something here though. ¹: which has, still, to be defined clearly. > […] > > So yes, you're right that _technically_ we can achieve the same with > current procedures, but I argue that the underlying procedure doesn't > scale (which is unsurprising, given it's been designed for a different > purpose). > It doesn't mean that it's a problem. Well, yes, it can be enhanced… but I'd say we didn't see periods where all Release Team members were really that busy to not be able to add an age-days hint or approve a t-p-u upload. I'm not sure we will see that day. And the same issue remains true with rolling scenario (existence of that bottleneck). Having that said, avoiding bottlenecks when possible is better. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dbab79a.1010...@dogguy.org