On Mon, 31 Jul 2006 10:29:57 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
> The point of the delayed queue is so that you don't have to remember > to act if the maintainer doesn't respond. That can be pretty > difficult, it's easy to remember to do something if the maintainer > *does* respond -- you get a cue in the form of the maintainer > responding; but when they don't, you have to remember spontaneously > yourself, even though by that time you may have any number of other > things distracting you. Well, if you forget, then the patch must not really have been that important to begin with. ;) Yeah, I can see that there may be cases where it would be nice to reduce the NMUer's workload (e.g. if they're doing mass-NMUs, and so have a whole pile of packages to worry about), but I think that should be done as a special case, rather than a general rule. Then again, if the NMUer isn't responsible enough to remember to upload after [appropriate delay], can s/he be trusted to follow up on the bugs resulting from the NMU? [...] > And if the maintainer's response is to include the patch (or a better > one) and upload it, the DELAYED upload will be REJECTed, and it will > be as if there was never a DELAYED upload in the first place. Not having used the DELAYED queue before, is it possible for the maintainer to reject an upload without making their own upload? e.g. if the NMU is broken, but it will take me more than a week to test a proper fix. Or if I decide that the package shouldn't be changed after all. etc. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
