On Fri, Jan 11, 2008 at 12:00:23PM -0200, Margarita Manterola wrote: > > Motivation: > For some time now, one of the things that the Release Team has had to > deal with are complex transitions. One of the requirements for making a > transition work is that maintainers of involved packages must not > upload. However, for whatever reasons, some maintainers do upload, and > thus a lot of time is wasted. > > Proposal: > Implement a new file, that works similarly to the hints file, but that > causes uploads to unstable for selected packages to be rejected. Thus, > if a maintainer uploads, it won't get through so that it won't get in > the way of the transition. > > I talked about this with Dato and Ganneff. They suggested the file > should be a yaml file, listing source packages, and the reason for the > blocking (i.e. the transition they are involved in). > > Ganneff volunteered to prepare the patch after the format of the file is > decided. > > So, what do you think about it? > Interestingly, I also was thinking about this today, and had a chat with AJ. 11:44 <Maulkin> Want a patch for dak that allows RMs to use hint file type things to prevent unstable uploads? 11:44 <Maulkin> IIRC, it was wibbled about at the BoF 11:44 <aj> i was thinking diver them to experimental 11:44 <aj> divert 11:44 <aj> but a REJECT with "upload to experimental for the moment, biatch" could work 11:44 <Maulkin> Unless there's something >= already in experimental. 11:45 * Maulkin nods 11:45 <Maulkin> Well, it could try experimental, and if not, then REJ :) 11:46 <aj> dunno, i'm kind-of thinking REJECT would be least-surprising 11:46 <aj> alternative you could implement a delayed queue :) 11:46 <aj> (and have it sit in that until thehint disappears) 11:47 <Maulkin> How about simply an ignore file? 11:47 <aj> (the delayed queue could then also be used for DELAYED/10-day uploads, yay) 11:47 <Maulkin> ie: don't process stuff in incoming if it's in $foo? 11:47 <aj> delayed queue should act like BYHAND -- ie notify the uploader it's been delayed 11:47 <Maulkin> Well, that's probably more useful :) 11:48 <aj> then it's just a matter of reprocessing stuff in q/delayed every so often to see if it should no longer be delayed 11:48 * Maulkin nods 11:48 <Maulkin> Could do a DELAYED/n-day uploads. Probably better than doing a fixed number. 11:49 <Maulkin> So then release can do a delayed hint for 999 days, and it'll work :P 11:49 <Maulkin> Or specify minimum datestamps 11:49 <aj> minimum datestamps are better, yeah 11:50 <aj> so your test is: 11:50 <aj> if datestamp < now or block_unstable_hint[package]: delay; else: process 11:50 * Maulkin nods 11:50 <aj> oh, i was thinking just a list of things to delay currently 11:51 <aj> if it's in the list, it stays delayed indefinitely 11:51 <aj> if it's not, it gets processed now 11:51 <aj> datestamp just lets us replace the DELAYED queue on gluck or wherever 11:51 <Maulkin> Yeah. 11:52 <Maulkin> Meh, just the 'in hintfile' thing will do for now then. I'll take into account that it may have datestamps at some point(tm) :) 11:52 <aj> yeah 11:52 <aj> it just needs code for a general "should_i_delay_this()" function 11:52 <aj> then whatever can be added later 11:58 <aj> ifupdown (0.6.8) unstable; urgency=low,delay=10 11:58 <aj> could be made to work;then it's just checking .changes for Xs-Delay: or Delay: and adding that to Date: 13:31 <Maulkin> Ooh, got ya. That would be nice. Thoughts? Neil -- <moray> hm, maybe wearing a black t-shirt while dusting my bedroom for the first time in years wasn't such a good idea
Attachment:
signature.asc
Description: Digital signature