Nathanael Nerode said:Another unfortunately common maintainer 'attitude problem' is the bug accumulation problem. That is "I'll fix this trivial-to-fix bug when I fix the other XXX bugs, and it's not worth uploading until I do." This leaves trivial-to-fix bugs open for months or even years longer than they need to be. It's simply the wrong way to operate. :-/ However, it seems to be firmly stuck in some people's heads. Remember the mantra: release early, release often? It applies here. I have no idea how to fix this mental block, however.
Matt Palmer wrote:
I do this, I think for conservation of version numbers, bandwidth, and archive resources. There's also the issue of propagating *something* to
> testing every now and then. <g>Yeah, actually this is quite reasonable behavior with 'minor' and 'normal' bugs, and even sometimes reasonable with 'important' bugs. If I'd specified "trivial-to-fix RELEASE CRITICAL bugs", would my point make more sense? :-)
It's not so much of an issue as long as
Quite right as well -- provided n isn't too large! :-) If n=100, this is probably not a good plan. ;-)there is a plan to upload in n days, and the maintainer lets people know what's going on - I use the pending tag for this.
This idea actually approximates what I was thinking of, although I guess I was thinking more conservatively. :-)On the larger matter of NMUs, one way to sharpen up everyone's act would be to say that an NMU to delayed-n can happen for any bug in the BTS with a patch against it which hasn't been "touched" for more than perhaps 10-n days, no notification needed. By "touched" I mean that there hasn't been maintainer activity on the matter - either a comment about the bug or the patch, or a pending tag. The 10-n bit means that you can upload to delayed-7 after 3 days, or just put it straight in after 10 days. And maintainers aren't allowed to complain in any way about the NMU. <g>