Daniel van Vugt
daniel.van.vugt at canonical.com
Wed Jul 10 02:16:46 UTC 2013
I guess then, I would only ask mir-team to not be overconfident. We all
make mistakes and we all fail to see some mistakes in proposals. It's
best to have more pairs of eyes.
Waiting a bit longer won't affect throughput of landings, only latency.
On 10/07/13 10:12, Robert Ancell wrote:
> My thoughts on this are:
> - If you are in ~mir-devel you are trusted to push changes into lp:mir.
> You take responsibility for the changes you make.
> - We don't want to push directly since this doesn't guarantee that the
> test cases have been run for that commit, so we use merge proposals.
> - Merge proposals are a tool to increase quality, not roadblocks to
> getting changes in.
> - The person who sets the merge proposal to "Approved" is taking
> responsibility for that change. It can be a reviewer, or the proposer.
> - There's no fixed number of reviews required. It's the responsibility
> of the final approver to decide if there has been sufficient review of
> the change. If you're in ~mir-devel, you are considered capable of
> judging how much review is needed.
> On Tue, Jul 9, 2013 at 5:19 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com <mailto:daniel.van.vugt at canonical.com>>
> I noticed some people are regularly only waiting for a single
> approval on their MPs and then top-approve themselves.
> I think top-approving your own MPs is OK if there's already two or
> more reviews from others, and it's been idle for a few days. But
> merging with only one real review, on proposals which are not time
> critical, is probably not ideal. I think we should always be waiting
> for at least a second review, unless it's a time critical issue.
> Maybe others in mir-team disagree?
> - Daniel
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com <mailto:Mir-devel at lists.ubuntu.com>
> Modify settings or unsubscribe at:
More information about the Mir-devel