Charles Plessy <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
