[coreboot] [RFC]Using gerrit for patch management (and jenkins for QA)

[Patrick Georgi]

Am 01.06.2011 05:02, schrieb Peter Stuge:
> Patrick Georgi wrote:
>> I'm officially sick and tired of patchwork. Or from losing patches
>> to the mailing list.
> Hear hear!
Mail is for spam-delivery, an ancient tool from a distant past ;-)

No, seriously - we have 100+ unhandled patches on patchwork, many of
them iterations on a single topic that must be cleaned up manually
(because the scripts can't).

If patches bitrot in gerrit, at least they're already build tested, and
iterations are grouped together automatically.
Which means less work for the poor soul trying to clean up.

>> Enter gerrit: A web tool to push git commits to, have them reviewed,
>> with proper handling of updated patches. Automatic support for
>> dependencies between commits (by default it assumes that ancestry means
>> dependency). An automated gatekeeper to the repository.
> Sounds even better! Does updated patches mean rebase?
rebase, modifications, ... essentially, it's possible to track a single
issue and its patches at a single location.

> So far there has been no way at all to push git commits to the main
> repo and I really like the look of this setup so if we want to start
> getting commits also via git then I think it makes perfect sense.
It's a special workflow, but for git there doesn't seem to be a default
workflow anyway. Specifically, there's no way to push to master
directly. Instead:
- commits are pushed to gerrit (by normal "git push" and a
commit-message hook that adds a Change-Id entry)
- commits are build tested by jenkins automatically, which registers its
vote with gerrit
- commits are reviewed by other developers
- sufficient positive review count -> commits are pushed to mainline by
gerrit

> Maybe the svn repo can (and should) stay primary repo a while longer
> still, but that would require a magic post-receive git hook to
> transplant received commits into the svn repo, which comes with lots
> of fun potential synchronization issues.
We'd need bidirectional bridging that doesn't always break...

> It may also be just as well to simply rip off the svn bandaid once
> and for all.
... so I'd prefer that.

> Some contributors may experience issues with firewalls when switching
> from svn to ssh, but meanwhile it would always be possible to send
> patches generated by git via email. (There is even a git send-email
> command that automates the process.)
People generally had a problem with accessing svn:// URLs already, so we
provided a http[s] read-only copy of the repo.
I guess we can do similar with a read-only git repo.


Patrick