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
signature.asc
Description: Digital signature
