On Sun, Mar 04, 2007 at 08:19:44AM -0500, Theodore Tso wrote: > On Sat, Mar 03, 2007 at 09:06:23PM -0800, Steve Langasek wrote: > > It's acceptable to me; the final d-i images haven't been spun yet for etch, > > and anyway a one-line change for a shlibs fix isn't exactly a big delta so I > > don't see a reason to respin even if we did have version skew. (I.e., the > > source requirements are still satisfied for d-i as much as they are for any > > random other package that might happen to be built against a previous > > version of libblkid1, no?)
> Yes, very true. > Which I guess brings me to another question, and I'll *completely* > understand if the release team says NO. If I'm going to do an uplod, > and if the d-i images are going to be respun anyway, would you mind if > I also slipstream in the following very low-risk patch: > http://thunk.org/hg/e2fsprogs/?cs=1619c81226d1 Hmm, I think I'm going to say no to this one; it's a low-risk patch, yes, but it's also a low-impact bug, so I'd just as soon not fiddle with it. > After all, the function of release managers is to counteract > developers' natural desire to fix "one last bug" or add "one last > feature" when it might end up delaying the release, no? :-) Exactly. :-) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
