[RFD] Merge proposals and code reviews too private
mbp at canonical.com
Wed Aug 19 23:52:53 BST 2009
2009/8/20 James Westby <jw+debian at jameswestby.net>:
> Matthew D. Fuller wrote:
>> 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.
> One thing I think is missing is being able to subscribe to code review
> for the project. If we use series as I believe LP intends, cherry-picks
> for critical bugs would have targets of the series branch. As the
> subscription you propose is based on subscribing to branches, it would
> require you to subscribe to each release branch as it was created to
> receive all code review mail.
> I agree with the other points Matthew made in his mail.
A few more thoughts:
It seems like Launchpad ought to support "I want to subscribe to all
merge proposals for this project" without necessarily being a member
of the team that's responsible or trusted for doing the reviews. I'm
not sure if that's possible at the moment, and if it's not perhaps we
should not wait for it but rather work within the facilities that are
Maybe we could set the default review team to ~bzr-reviewers and make
that open membership?
Sending reviews to a mailing list would mean all the mail was archived
and it could possibly be fed into gmane or similar things.
However as Aaron points out, if people reply only to the list their
comments wouldn't go back into the review and that could be confusing.
People have said a few times that they find the main bazaar list too
high-volume and they wish it was smaller. I'm fine with splitting it,
but we need to do it in a way that the lists will be sustainable, and
I suspect just making a -users one is a poor option compared to the
answer tracker. Ian's initiative to create separate platform lists
does seem good, because there are ongoing communities of interest for
each one. We've discussed before that there may be people who are
quite interested in Bazaar's evolution but not want to follow every
code review. Therefore sending reviews to a single separate list
might be good.
Whatever we do, we should update the hacking guide, web site, etc.
Perhaps just doing that would be enough.
More information about the bazaar