[rfc] time to switch to Launchpad reviews

[Aaron Bentley]

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

Martin Pool wrote:
> 2009/4/24 Aaron Bentley <aaron at aaronbentley.com>:
>>>>> - Maps tightly to Bazaar project's workflow
>>>>>  - merge request status is determined fully automatically
>>> Should be done in lp.
>> One of the design requirements for Code Review was to avoid forcing a
>> particular workflow on projects.
> 
> I interpreted this as "is it merged yet or not" but I guess you meant
> "does it have enough votes yet", which obviously will vary between
> projects.

Yes.  Launchpad's approach isn't "fully" automatic.  It detects merges,
but not approvals or rejections.

> I don't see that as a big deal though; if it has a good
> summary of the votes it should be clear which ones have enough review.

That raises an interesting question.  Our voting assumes that reviewers
who submit a merge directive are implicitly approving the merge, and so
they only need one additional review.  This predates Bundle Buggy, but
BB does this automatically.

Are we going to continue to require "two votes, but you may vote for
yourself", or are we going to require "one vote for reviewers, two votes
for everyone else"?

>>> You should probably file a bug for that too.  In particular it should
>>> provide a List-Id so gmail can filter on that.
>> Interesting.  So the List-Id would be for a particular merge proposal?
> 
> Actually I think it would be best to act as if there's a list of
> reviews for that project, since that's closest to the granularity at
> which it would normally be done on a list.  I believe you can only
> check the list-id field for exact equality.

So it's like a mailing list that you may only get some of the messages for.

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

iEYEARECAAYFAknyGT4ACgkQ0F+nu1YWqI2z6gCffkMszvIfEY6KM5H/sklo4s7K
A8MAn0GZgbYBO4o5SLe1lPm9XfeiLodZ
=b1aM
-----END PGP SIGNATURE-----