On Sat, 07 Feb 2009 04:44:44 Aaron Bentley wrote:
> Paul Hummer wrote:
> > So I did a code review for Entertainer and sent it, then immediately
> > merged the branch into trunk and pushed up to launchpad. The scanner
> > apparently marked the BMP as merged before my review with ' status
> > approved' could get handled. This resulted in this oops:
> > https://devpad.canonical.com/~matsubara/oops.cgi/2009-02-06/CEMAIL5
>
> It's possible for something to be merged that is not approved, and it's
> possible for something to be approved that isn't merged. So I think
> that our model is slightly wrong. The ideal model would have two status
> flags:
>
> code review status: inactive, pending, approved, disapproved
s/disapproved/rejected/ :)
> merge status: inactive, queued, merged
Would we still want to somehow record merge_failed? As in we tried to merge
but failed due to either conflicts or test failures.
> If our model reflected this, then setting the review status to approved
> would not change the merge status, and we could not get errors like this.
On Sat, 07 Feb 2009 04:44:44 Aaron Bentley wrote: /devpad. canonical. com/~matsubara/ oops.cgi/ 2009-02- 06/CEMAIL5
> Paul Hummer wrote:
> > So I did a code review for Entertainer and sent it, then immediately
> > merged the branch into trunk and pushed up to launchpad. The scanner
> > apparently marked the BMP as merged before my review with ' status
> > approved' could get handled. This resulted in this oops:
> > https:/
>
> It's possible for something to be merged that is not approved, and it's
> possible for something to be approved that isn't merged. So I think
> that our model is slightly wrong. The ideal model would have two status
> flags:
>
> code review status: inactive, pending, approved, disapproved
s/disapproved/ rejected/ :)
> merge status: inactive, queued, merged
Would we still want to somehow record merge_failed? As in we tried to merge
but failed due to either conflicts or test failures.
> If our model reflected this, then setting the review status to approved
> would not change the merge status, and we could not get errors like this.
Now that's a damn fine idea.