Asa Dotzler wrote:
>
> Chris Hoess wrote:
>
> > To veer off-course a bit, while improving the ease of code contribution is
> > a Good Thing, I'd like to see some additional assurance put in place to
> > help make sure contributed code gets reviewed. I've seen a lot of code
> > rotting in Bugzilla
>
> Please post bug numbers. Generalities don't get us anywhere. I don't
> know many people that spend more time in Bugzilla than I do and I don't
> see "a lot of code rotting in Bugzilla".
http://bugzilla.mozilla.org/show_bug.cgi?id=22056
http://bugzilla.mozilla.org/show_bug.cgi?id=22687
http://bugzilla.mozilla.org/show_bug.cgi?id=53597
http://bugzilla.mozilla.org/show_bug.cgi?id=87428 (was 2800 - this one's
bitrotted at least 3 times over and is probably about to again with the
<toolbarbutton> changes).
Note: Each of these patches, individually, has a good reason for not
being checked in as is - eg some aspect of the code needs to be fixed,
or a feature is missing, or it's a sub-optimal implementation - so these
aren't "bitrotting waiting for review" so much as "bitrotting waiting
for minor fixups that somebody considers essential before they're
checked in". But this is just the items in my "interests" list (which is
only 22 bugs long - look for me as the reporter or cc if you're
interested) so it does seem to me that there's some kind of pattern of
bitrotting code in bugzilla.
What to do about this kind of issue is less clear: if there's a real
problem with the patch then it obviously *shouldn't* be checked in, and
in a volunteer project it's not possible to tell people that they "must"
follow up on these kinds of issues. Also sometimes the problem requires
specialist knowledge, which only a few people might possess and those
people may be unable or unwilling to help (eg see bug 53597 above,
although someone with style knowledge did volunteer eventually).
I suppose the only solution is to encourage contributors (or
contributors' employers) to specifically prioritize "minor fixups to an
existing patch before it bitrots" over other work, even if the
particular patch in question isn't a high priority to that contributor.
Unfortunately, I don't see it happenning, or the monster 2800/87428
would have been checked in shortly after 6.0 was released.
Stuart.
Stuart.
