I would not say "stability/quality"
has improved (depending on what that means), but it is clear that it avoids
"breaking HEAD" of the 'simrel.build' repository. And that is
It is already 'required' that contributors
"go though Gerrit" ... but it is allowed that the 'review/validation'
can be skipped, if "refs/heads/master" used instead of "refs/for/master".
But I myself would not like to see it
*required* to go through "refs/for/master". I think most
already do go through "refs/for/master" and the few times they
do not, I would assume they have a good reason for it.
Can you point out (or monitor for) cases
where people go directly to "refs/heads/master" and it causes
Mickael Istria <mistria@xxxxxxxxxx> To:
Cross project issues
01/07/2016 07:06 AM Subject:
Enforce Gerrit for Simrel? Sent by:
Gerrit for SimRel has been widely used by many projects and the validation
checks that come with Simrel have successfully caught a bunch of issues
before the had the opportunity to break the Simultaneous Release. Gerrit
and Code-Review can have an incredible effect on software quality, many
projects and teams enforce it with success. I don't have metrics, but maybe
David can say whether he felt a noticeable improvement in stability/quality
since the inception of Gerrit a few months ago?
I believe it's the right time to start considering enforcing Gerrit usage
for SimRel: a first implementation would be to have committers push to
refs/for/master instead of master, and would either be reviewed by someone
else, or review themselves their contribution. The Hudson validation job
triggers automatically on any contribution and gives a vote if the contribution
is breaking the build.