myk at mozilla.org
Fri Oct 25 17:52:57 UTC 2002
>I fail to see how this justifies not receiving peer review. Peer review
>is at the core of the good volunteer projects and is why they produce
>good software. The logical extension of your argument is to never talk
>about designs at all, since someone might complain and bog the bug down.
This has nothing to do with peer review, which I absolutely agree with.
It's about whether or not everyone should get involved in each review.
>It is not "design by committee" if someone holds a big stick and is
>willing to use it quickly. You also have not offered any proof that we
>are worse off in the long run through having the discussion on mail,
>even if it did get bogged down for a while.
If you agree with my assertion that all the alternatives were at least
good enough (and, fwiw, the participants in the debate seemed to feel
this way last time I checked with them) and that the fix would be better
than not having it, then it's clear that we are worse off now than we
would have been if one of those fixes had gone in.
>When things get "shunted
>through", you often are sacrificing your long term quality for short
But I'm not talking about "shunting" anything through at all. I'm
talking about patches that get reviewed (sometimes repeatedly) by one or
more experienced hackers before going in and that provide significant
benefit to the code, even if they sometimes have flaws (which we also
didn't catch back when we were doing two reviews).
>If Bugzilla had been designed from the start to be templatised,
>internationalised, fully field value customisable, run in taint mode,
>back end separated, blah blah blah, we would have been where we are
>today a lot earlier.
More likely we wouldn't have been anywhere at all (cf: Bugzilla 3.0).
Only huge engineering projects (f.e. rockets to the moon) can be built
this way, and only by expending an incredible amount of resources
beforehand, disproportionately large relative to the size of the
project. Bugzilla is certainly getting larger, but it isn't nearly
> Obviously there were time constraints placed on
>Terry by mozilla.org that led to these decisions. But most of us now
>are individual developers who don't have to continue to make these sorts
>of decisions. A little time invested now pays off big in the long run.
I contend that reviewers and regular "viewers" regularly invest that
time now, often more than is necessary, to ensure that the code that
goes in takes our future plans and current standards into account.
Overexuberance in this regard is, in fact, one of the reasons (although
not the major one) why our reviews take so dang long.
And you also have to consider the law of diminishing returns. There's
only so much discussion you can have before it stops being useful and
you're better off implementing your current best guess and fixing any
problems down the road.
>Also note that you're much more likely to notice deadlocked design
>discussions on this list because historically they're generally already
>deadlocked by the time they get onto the list, as they have started on
>IRC or on bmo, and escalated. They're also longer, more memorable
>threads because of the argument. Hence I think the argument factor is
>quite an exaggeration.
I think an increasingly common case is that someone posts a message and
then everyone jumps into the discussion with their opinion. Over time
the opinions start to take on weight and harden, and then it becomes too
important for everyone's opinion to be taken into account in the final
design. The first half of this dynamic--the jumping in with
opinions--has already happened today with Christian's CVS integration.
Hopefully the second won't.
More information about the developers