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

Re: Idea for dealing with transitions

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

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.

<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

Reply to: