Personal experiences/anecdotes of the bzr review processes

[Mark Hammond]

> On Tue, 2008-09-23 at 11:39 -0400, Aaron Bentley wrote:
> >
> >
> > That approach seems extreme to me.  I would not be comfortable
> > accepting  something with bad style into the codebase just because
> the
> > HACKING file was not prescient enough to predict that particular
> > problem.
> 
> Agreed. I think process guidelines are just guidelines. Just because
> something isn't pinned down does not make it unrecognisable.

But it also runs the risk of allowing an individuals personal style to get
too wound up in the process.  It shouldn't be a case of "I'll ask XYZ to
perform a review because I know they aren't going to ask me to re-paint it
green."

There should be confidence that the same basic review response will come
regardless of who actually performs it.  For an example of what I would
consider a highly constructive review, see Ian's review I mentioned at the
start of the thread (concise, focussed on what mattered, re-reviewed the
requested tweaks in a timely fashion then voted 'approve')

Maybe it could be phrased something like "Tweaks relates to style issues
will only be requested when it is believed every bzr core developer would
raise the same objection.  In other words, unless it is felt there is clear
consensus about the style, a patch should not need re-tweaking due to the
style.  Further, patches are not the place for debating such style - either
there is clear consensus (so it *must* change) or there is not (so it *must
not* hold up review)"

I hope my intent is clear - enforcing *personal* style that isn't
necessarily a project wide requirement can be counterproductive for everyone
involved.

Cheers,

Mark