Re: Bits from the release team: the plans for etch
Thomas Bushnell BSG <tb@becket.net> wrote:
> Olaf van der Spek <olafvdspek@gmail.com> writes:
>
>> On 10/17/05, Thomas Bushnell BSG <tb@becket.net> wrote:
>>> Simon Richter <Simon.Richter@hogyros.de> 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
Reply to: