Hello Russ,
Thanks for being upfront about this change. I expected to lose the
ability to click "submit" sooner than later due to the submit queue bot,
though I admit I didn't expect a wider change like this one.
Before I get to my concerns, I have some questions about GerritAccess:
> Every CL requires both a code review (Code-Review+2) from an approver and
> the involvement of two Google employees, either as code uploader or as a
> reviewer voting at least Code-Review+1. Requiring multiple people ensures
> that code cannot be submitted unilaterally from a single compromised
> account.
If you want to protect the project against a single approver account
being compromised, it seems to me like the existing system with two
Trust votes already accomplishes that. I assume this wording would need
to be adjusted, as it describes the current system.
Second, I would like to understand what it is about Google that prevents
two of their approver employees from being compromised at once.
There's clearly something that external approvers are missing, as
otherwise this wouldn't be a factor in the equation at all.
For example, I would be completely open to Go approvers being required
to have strong multi-factor authentication, even for each Gerrit session
where they approve or submit changes. This kind of security enhancement
hasn't been touched upon before, as far as I can tell.
Onto the concerns: your prediction is right that I am disappointed.
I'll try to explain why in three main points below:
First, it feels like the set of Go approvers loses much of its meaning.
Google company-wide security policies aside, it's as if the project no
longer trusted external contributors to perform their duties.
If they can't be trusted to keep their accounts reasonably secure,
should they be trusted to maintain parts of the Go project?
The above also goes the other way: as an external contributor and
maintainer, should I really invest that much time and energy in the
project if the project doesn't reciprocate with trust?
I understand that the "Googlers only" rule is probably not your choice,
but its effect on the project and community is the same regardless.
Second, this change will make timezone differences more painful.
Practically all Go team members at Google are in US timezones,
meaning that people like me have little overlap in working hours.
Our work is generally asynchronous and that is fine, but being able to
submit a CL without waiting hours or days is still valuable.
For example, if a "long" builder in
build.golang.org unexpectedly breaks
due to a CL of mine, I can notice that and attempt to fix it if I'm
around, but not if the CL gets merged six hours later when I'm AFK.
I expect this will be the reality, because the new Gerrit dashboard
won't be manned anywhere close to 24/7.
Third, no matter how well engineered the Gerrit dashboard is,
it will still ultimately lead to more work for the Go team at Google,
which is worrying given the project is already lagging behind in reviews.
I'm too far removed to know who is responsible for the supply chain
security measures, but I would assume they can realise that they are not
viable unless the Go team magically doubles in headcount.
In summary, Go needs more maintainers and reviewers, and doing that work
outside of Google has always been a delicate balance. There are calls
and emails that I'll never be included in due to not being at Google,
and I've come to accept that. However, I do fear that this change will
make it even less likely to actively participate in Go from the outside.