Merge lp:~ursinha/bzr-pqm/auto-approve into lp:bzr-pqm
Proposed by
Ursula Junque
Status: | Rejected |
---|---|
Rejected by: | Aaron Bentley |
Proposed branch: | lp:~ursinha/bzr-pqm/auto-approve |
Merge into: | lp:bzr-pqm |
Diff against target: |
60 lines (+26/-0) 2 files modified
lpland.py (+11/-0) tests/test_lpland.py (+15/-0) |
To merge this branch: | bzr merge lp:~ursinha/bzr-pqm/auto-approve |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Aaron Bentley | Disapprove | ||
Jelmer Vernooij (community) | Abstain | ||
Diogo Matsubara | Pending | ||
Review via email: mp+43521@code.launchpad.net |
Description of the change
This branch changes the behavior of the plugin by making it mark the merge proposal status as Approved (queue_status), if it already has any approved code votes. The added method itself doesn't check the mp votes, but the checking is done by other method before this one is called.
This change has been implemented so people won't need to set their mp's to Approved manually.
To post a comment you must log in.
Unmerged revisions
- 77. By Ursula Junque
-
adding set_status_approved method to do what it says.
- 76. By Ursula Junque
-
adding setStatus to FakeLPMergeProp
osal; adding test to check set_status_ approved.
This seems like the wrong time to set the proposal to approved. This should ideally be done by the (last) reviewer as part of their review. By the time you lp-land it, it will be set to "Merged" in a few minutes, so I don't think that there's great value to setting it "approved" in the meantime.
This also assumes that the person landing the code is on the review team of the target branch. This is usually the case, but our design for merge proposals is that non-reviewers can land code if such code has been approved by a reviewer.
Doing lp_save as part of set_status_approved seems like a bad pattern, because it means that each change costs a roundtrip, instead of allowing multiple changes to be made in a single roundtrip.