Gervase Markham wrote:
>
> > [...] these
> > aren't "bitrotting waiting for review" so much as "bitrotting waiting
> > for minor fixups that somebody considers essential before they're
> > checked in".
>
> Then why is that anyone's problem other than the patch authors? It's
> certainly not staff or reviewers' problem. If the patch has been
> abandoned, feel free to grab it and drive it to checkin.
I should have clarified that I wasn't intending to criticise anyone on
staff or reviewers - just trying to open a debate on whether anything
can be improved here. If the answer turns out to be "no" for good
reasons, that's fine.
The problem is, IMHO, that when somebody writes a patch to "scratch an
itch", they get it to the point where it solves *their* immediate
problem or itch, and thereafter their problem is solved: they can
continue to use the same patch in their local copy of mozilla forever
(or at least until it bitrots). This is especially true for 87428
because it is available as an XPI: I've been using it in my mozilla for
two milestones now :) This is good, but it reduces the motivation to
take the patch further - the original submitter's itch is scratched, and
he's[1] submitted it back to the project out of goodwill. He may also
have an itch to get it included in the main distribution, but then
again, he may not. He may want to see it in but not enough to push
through a review process and make a bunch of changes he doesn't even
necessarily agree with. He may have the desire but not the time due to
changes in external circumstances (especially in this business climate).
Either way, the submitter himself doesn't suffer much if it doesn't get
in.
But for those of us who want to see the mozilla project be the best it
can be, we do suffer, because we have an open bug that isn't fixed, or a
feature that isn't available, in the official mozilla distribution. So
for optimal results (not necessarily practical, but optimal), patches in
this situation should be identified quickly and touched up before they
bitrot. Although it can be argued that this situation will work itself
out because the people who care about the issue will jump on it, and if
not then the resources are better spent anyway, this doesn't take into
account the prospect of bitrot: something that would take a couple of
hours if done now might take a day or more in a month's time when it
makes it's way up to the top of somebody else's list of priorities. And
the increase in the amount of work will also serve to make people less
likely to want to do it.
So, having described the problem, I don't know if I can offer any
solutions. Short of having people who have this as their explicit job,
or some contributor specifically making a commitment to doing so, the
project can't really do anything about the problem. I certainly don't
think anybody's being negligent here, just that the model of "everybody
works in their own best interest and the optimal thing magically
happens" doesn't necessarily produce the optimal results when there's a
long and complicated (to an outsider - I know because it took me a month
to get a trivial patch applied) review process and a significant
likelihood of bitrot if patches aren't applied quickly.
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.
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.
It should also be possible, at least, to identify outstanding patches
that would conflict (in the cvs sense) with a given checkin, so that
anyone making any change would at least know which outstanding patches
they're bitrotting.
> I have taken a strong personal interest in that pair of bugs, as you
> know - I even took over the patch when the previous owner said he was
> unwilling to make the requested changes. I do not remember any time when
> there was a delay which was caused by lack of review or attention from
> anyone other than the current author.
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, and to wonder whether there would be
procedures that could mitigate this effect (even in the absence of
telling every contributor "you have to drive your patch as well as just
writing it", because some still won't, and it's the project that suffers
when they don't).
I should also say that I greatly appreciate your work on 84728: as you
know, I've been a longtime follower and advocate of that bug, but only
had minimal time to actually work on it and no experience in the areas
that still need improvement. I'm immensely grateful that there's someone
out there who has the time and knowledge as well as the motivation.
Hopefully it will be possible to get this in soon.
Stuart.
[1] Sorry for male pronouns, it was just easier to write that way.
