Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Olaf van der Spek <[EMAIL PROTECTED]> writes: > >> On 10/17/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: >>> Simon Richter <[EMAIL PROTECTED]> writes: >>> >>> > That is why I ask that before an NMU, someone should show me the patch, >>> > and if I reply "I don't have time right now, okay to NMU that if you >>> > like" then it's fine (and in fact it is going to be the answer you will >>> > hear most from me ATM). >>> >>> What if you don't reply at all? That's the problem in my experience. >>> Not you particularly, of course; but I rarely get told "no, I have a >> >> Can't the patch be posted to the BTS and NMUed after two days if >> there's no response (in general)? > > Yeah, but golly, sometimes there is no patch because the patch is > blindingly obvious.
No, no, no. Please not. There's always a patch, and if it's only the changelog entry. It is extremely annoying if the first mail you find in your "package foo" mail folder is the message by katie (or who is it?) that a bug you didn't fix for one or the other reason has been fixed in an upload, but you never heard that anybody intended to NMU, what they did, and maybe why. Yes, even "why", since although I know that some bug in a postrm script is RC, I might not know that it breaks the autobuilders, and might decide that I can as well first thoroughly test the other changes I made meanwhile. Yes, "what they did", since even for obvious fixes there are different ways to do it; especially when you keep the package in a version control system you want to either incorporate the NMUer's fix in HEAD, or create a branch, so that you won't be surprised if you later get a bug report with code you don't recall to have published (because you haven't). > Or, worse yet, "please install the new upstream > version" when that is necessary to fix an RC bug in some other > package. A new upstream version should usually not be NMUed; an NMU should keep changes as minimal as possible. If it cannot be avoided, then the patch is even more important: It shows the maintainer how intensely the NMUer has studied the upstream changes, if and what changes to the packaging were necessary, and so forth. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
