Re: Bug#625449: Permanent BSP patch
Charles Plessy <plessy@debian.org> writes:
> I already received patches that were half-mailquoted, and therefore
> impossible to apply without human editing. I also received dpkg “3.0”
> patches that consist on dozen of lines, just for modifying a single line
> in the upstream sources. Once a NMUer was more helpful and commited his
> changes, but forgot to “svn add” his patch.
I agree, this would be really frustrating. It's unfortunate that people
are not correctly using our existing tools, like nmudiff, which will
ensure these sorts of problems don't happen. Maybe we should encourage
those more strongly in the Developer's Reference to reduce the number of
malformed patches we get?
> Another time (not recently, I admit) I was rushed into uploading changes
> that were confirmed a couple of days later by Upstream to be not
> appropriate.
This is definitely always a risk. Sometimes the RC bug fix, which is
rushed because it's RC, will end up introducing some other bug. It's hard
to anticipate when this might happen, and I'm not sure what to do about
it. I do think this is the strongest argument against 0-day NMUs for RC
bugs, but I'm not sure I find it sufficient to outweigh the benefits in
making transitions faster.
> Another time, my package was NMUed while I was working on the new
> upstream release that fixed the problem.
This is the sort of problem that, hopefully, the seven-day maintainer
response period could assist with, since you could say that you were
working on this and people might hold off. Although, also, I still would
encourage you to not see this as a problem. The NMU would go out, and
then some time later you'd upload the new release (which also reverts the
NMU). That's an okay work flow. Nothing was really lost in that
situation.
> Since we are short of manpower, why would we recommend in the DevRef to
> not coordinate with active maintainers ?
I think that's the intention of requiring that the issue go seven days
without a response. That's encouraging coordination. If one doesn't hear
back from the maintainer, it's difficult to coordinate.
> Unless the issue is urgent, and I strongly thing that not all RC bugs
> are equally urgent, we should aim at minimising the overall work load.
> I know that I am over-reacting, but I can not help feeling the pushy
> attitude to be confrontational, top-down and divisive.
My concern is the impression that NMUs are a confrontation. They're
really meant to just be a temporary patch when the maintainer is too busy,
which the maintainer can then later either pick up, rework, or drop as
they see fit. It's load-sharing: it lets other people fix self-contained
issues that are affecting either other parts of the project or some users
until the maintainer has a chance to take a look.
I wish we could get to a place socially where that sort of assistance
isn't perceived as a confrontation or as divisive or pushy.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: