This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to keep Reviewed-by lines in git commits with gerrit.


On Tue, 12 Nov 2019, Florian Weimer wrote:

> > This shouldn't just be about Reviewed-by.  If someone says a patch is OK 
> > with a specific change made to it (whether to the code or to the commit 
> > message), it should be enough to make that change and retest and push to 
> > master, without needing to go through extra administration in a review 
> > system just because of that change.
> 
> If you want to use Gerrit as some sort of audit trail (and we will
> eventually face attacks on the GNU toolchain sources; maybe it has
> already happened and we just haven't noticed yet), then of course it's
> necessary that any tiny change gets re-reviewed.

We say maintainers can commit changes in their areas without needing 
review, and that certain kinds of changes are considered obvious for 
anyone with commit access.  So I don't think "OK with change X" (without 
needing re-review) is fundamentally different from that.

git provides the audit trail of exactly what changes went into the 
repository.  (And the glibc-cvs list shows which user account did the 
push, which is key information if it turns out a malicious change was 
pushed.  If we enable pushing from gerrit (with some set of gerrit users 
who also have write access being able to cause gerrit to push a change), 
we should consider how to track which gerrit account it was that caused a 
change to be pushed, in a similarly distributed way.)

> If on the other hand it is just an optional tool to help a contributor
> to produce their commit in a collaborative fashion, then it's indeed
> silly to ask for a re-review once the contributor is satisfied with
> what they've got.

I'm thinking of it as an optional tool to help the community review 
changes and track the state of changes being proposed (by providing the 
database of those that have yet to be pushed to master or abandoned, and 
possibly in future by providing other features such as automatic CI to 
help reviewers).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]