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:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Hummer wrote: /devpad. canonical. com/~matsubara/ oops.cgi/ 2009-02- 06/CEMAIL5
> 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
merge status: inactive, queued, merged
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.
Aaron enigmail. mozdev. org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkm MWt0ACgkQ0F+ nu1YWqI22EACfad +Ksy0foLEJTuLVc Fa+L2BP JnJ78bJ99Mg+ HR69L
ULYAn0GNmRB3Ru6
=itMw
-----END PGP SIGNATURE-----