> If all we can do about this is say "yeah, it sucks", that's fine, but we
> should still recognize that it sucks, rather than pretending that it's a
> "feature not a bug" of the mozilla.org process.
It sucks in a way. But the alternative is sub-optimal code getting
checked in, and no-one wants that either.
> One thing we could do to reduce the possibility of bitrot would be to
> arrange a way for somebody who has a widespread change (like
> s/button/toolbarbutton/g) to be able to identify patches in open bugs
> that would be affected, and automagically update them in the same way.
> That would be very difficult to do in a general way, though.
No. Why should they? When the inconvenience of maintaining your patch
outweighs the inconvenience of driving it to checkin, the patch author
will do the latter. We don't want to make it easier for people not to
drive to checkin.
> Yes, sorry, I should have been clearer: the problem in these cases (and
> others) is that useful patches are written and (for whatever reason)
> *not* driven by their authors,
If other contributors want to step up, or even make stepping up their
job, then that's great. That's all we can say. If you want to establish
and maintain a meta bug which is a list of abandoned patches, and then
publicise that info, that would be great.
Gerv
