[RFD] Merge proposals and code reviews too private

[Matthew D. Fuller]

On Tue, Aug 18, 2009 at 08:20:12AM -0400 I heard the voice of
Aaron Bentley, and lo! it spake thus:
> 
> Code review is easy to subscribe to, for those interested.  Perhaps
> we should make that clearer.

We should.  *I* didn't know it existed, and I wouldn't have had any
idea where to go look for it if I suspected it did.


> It is reasonable to separate code review from other forms of
> discussion.

OTOH, it's also reasonable to have the development-related discussion
in one place.

This is especially true since we have a cultural norm of using
whatever code review system we're using at the time not just for
reviewing the code, but for all discussion around changes.  We've told
people many times not to submit patches as RFC's to the list, but to
make them [MERGE] requests for the tracking, and discussed everything
from the details of the code to the general desirability and shape of
the feature in discussions spawned from that.  While it may make sense
to have the former only happen with a relatively small list of people
who've explicitly sought out extras, it does not for the latter.  And
the way we organize the workflow shunts both into the same place.

And now that that's pushed off onto LP reviews, those discussions
never touch the list.  For "fix another test under 2a default", that
probably doesn't matter, because it's of no inherent interest to
anybody but devs, and anybody likely to have a useful opinion on the
matter is going to be getting the reviews anyway (as well as plenty of
people who aren't likely to, like me).

OTOH, to take an example off my list, the DWIM revspecs need review on
the code, BUT also deserve at least some discussion on the feature
itself.  And a lot of people can have opinions on that that should be
given a chance to air, who aren't going through extra undocumented and
practically unmentioned steps to subscribe to the REAL dev discussions
("this time for sure!").


> Code review is not designed to interoperate with mailing lists.  For
> example, unlike BB, code review could not read mail addressed to
> bzr.dev without substantial redesign.

But it's perfectly capable of having the list subscribed to it, and
the Reply-To on the mails would ensure that comments by people on the
list ended up in the review history.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.