My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 1354: Lock upload of a new patchset
5 people starred this issue and may be notified of changes. Back to list
Status:  Submitted
Owner:  nas...@codeaurora.org
Closed:  Nov 9
Cc:  mf...@codeaurora.org


Sign in to add a comment
 
Reported by ion.albe...@gmail.com, Apr 25, 2012
So that a new patchset is not uploaded between the validation
of one patch and its merge, 
the ability to lock the upload of a new patchset
would be welcome. 
This lock would be released after the patch is merged, or after the validation of the patch failed.
The need for this lock comes from this problem:
ex:
1.changeN/PatchSet1 is sent to the integration process to be merged,
2.a mistaken developer uploads changeN/PatchSet2,
3.changeN/PatchSet2 is taken as input of the integration, instead of
changeN/PatchSet1, which raises issues.

This mechanism could be implemented by sending a -2 code review, 
however, the following use case goes against it:
1.changeN/PatchSet1 is sent to the integration process to be merged,
2.changeN/PatchSet1 is locked by sending a -2 code review,
3.an overbooked developer sees a critical 
bug in the patchset. It sees there is a -2 on it, and therefore does not upload its code review. If he is aware of the -2 lock mechanism,
he has not any remaining way to block the merging of the patchset,
4.changeN/PatchSet1 is mistakenly merged.





Nov 7, 2015
#1 sop@google.com
Talked with Martin Fick about this today. He suggested using a special label to mean the change is "locked". Supporting this would just need an extra field in the label configuration that indicates a non-zero value for the label means the change is locked and cannot be modified.

The advantages to using a label are huge:

- configurable ACL, who can lock a change
- multiple users can place overlapping locks
- locks can be broken by removing the label
- lock breaking is ACL configurable
- different types of locks are configurable with different labels
- easy to view in the UI and REST API who has which locks

A few places in the server need to look for locks and avoid making changes if set. But this is a small enough set that we could get all of them with small effort.
Cc: mf...@codeaurora.org
Nov 7, 2015
Project Member #2 nas...@codeaurora.org
I started porting this from 2.5 to tip recently but didn't finish. I'll finish it in the next week.
Status: Started
Owner: nas...@codeaurora.org
Nov 9, 2015
Project Member #3 nas...@codeaurora.org
https://gerrit-review.googlesource.com/72174
Status: ChangeUnderReview
Nov 9, 2015
Project Member #4 nas...@codeaurora.org
Missed the cutoff for 2.12, but it'll be in 2.13.
Status: Submitted
Nov 9, 2015
#5 ion.albe...@gmail.com
Thanks !
Sign in to add a comment

Powered by Google Project Hosting