Personal experiences/anecdotes of the bzr review processes

[Mark Hammond]

> > I hope I did.  Does that mean you will?  It would be appreciated.
> 
> Yes, I think I will, on the assumption that John would have approved
> this new version, and so I wouldn't have had a chance to review it.

I'm not sure what that qualification means, but thank you regardless.

> >> I'm sorry that's been your experience.  We definitely want to
> >> improve the process.  Do you have any suggestions?
> >
> > I'd also suggest that a formal "style guide" (aka pep8 with bzr
> > specific requirements) be adopted

> I'm not sure what you're saying.  The "Coding Style Guidelines" section
> of HACKING is meant to support this.  Do you mean:
> - - It's not complete enough?
> - - It's not formal enough?
> - - It needs to be split out into a separate document?

I'm suggesting that unless reviewers can point to a *specific* requirement
in that document, then style issues must not hold up approval.  For example,
unless that document describes the exact threshold when a function is "too
long" and needs to be split, then any observations that a function "may be
too long" be declared irrelevant to the technical issue being discussed, and
if the reviewer feels strongly enough about it, they should open a launchpad
bug to address their concerns and have their style implemented as they can
best manage.

> We're currently discussing reducing the strength of the requirement for
> "design clarity", and perhaps style issues should be addressed the same
> way.

I'm not sure the 2 are related.  "design clarity" is far more important IMO
than the specific exception a unittest happens to raise for a feature no-one
expects to exist anywhere but Windows in the first place...

Cheers,

Mark.