Personal experiences/anecdotes of the bzr review processes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
>>> 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.

It means that I only reviewed it because of a failure in our process, so
I'll pretend the failure and my review didn't happen.

>> 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.

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.

>> 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...

I think they are two points on a spectrum, with one end being "beautiful
and maintainable", and the other end being "ugly and unmaintainable".
But the reason I brought it up is that we're looking at changing the
process for one, and we might want to look at changing the other at the
same time.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2Q3F0F+nu1YWqI0RAriUAJ9b0tIhF1d1PEDNy/dhNzvH4mqp8gCdERcy
9Xf29xFf8Zh9DBdZY2Kh76I=
=MsGV
-----END PGP SIGNATURE-----