Hi,
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
Given how the git read-only mirror gains popularity, maybe we should use that to our advantage and upgrade other parts of our tool set, too.
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.
It's built by Google and they use it for Android (https://review.source.android.com/) and Chromium (http://gerrit.chromium.org/). Thankfully, it's open source.
Should we use it, I'd also add Jenkins (http://www.jenkins-ci.org) to the mix. Jenkins is a fork of Hudson, both are Continuous Integration tools. Kinda like our current build bot at qa.coreboot.org, just with some more maintenance behind it, and a couple of neat features:
"The mix" would be inclue jenkins test-building all proposed patches on gerrit, vetoing those that fail in gerrit. Nice for commits where the dev forgot to add a file to the repo, or which were only partially tested.
Anyway, this would be a rather large change in the development workflow, so unlike other changes to our infrastructure this is nothing I can "just do".
Opinions?
Patrick
Den 31-05-2011 20:55, Patrick Georgi skrev:
"The mix" would be inclue jenkins test-building all proposed patches on gerrit, vetoing those that fail in gerrit. Nice for commits where the dev forgot to add a file to the repo, or which were only partially tested.
Anyway, this would be a rather large change in the development workflow, so unlike other chang
I favor this change
În Mie, Iunie 1, 2011 5:32, Anders Jenbo a scris:
Den 31-05-2011 20:55, Patrick Georgi skrev:
"The mix" would be inclue jenkins test-building all proposed patches on gerrit, vetoing those that fail in gerrit. Nice for commits where the dev forgot to add a file to the repo, or which were only partially tested.
Anyway, this would be a rather large change in the development workflow, so unlike other chang
I favor this change
+1 from me too
Patrick Georgi wrote:
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
Hear hear!
Given how the git read-only mirror gains popularity, maybe we should use that to our advantage and upgrade other parts of our tool set, too.
Sounds good.
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?
Should we use it, I'd also add Jenkins (http://www.jenkins-ci.org) to the mix.
Put into oven at 220 C and bake for 20 minutes. Yum, chocolate cake!
Anyway, this would be a rather large change in the development workflow, so unlike other changes to our infrastructure this is nothing I can "just do".
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.
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.
It may also be just as well to simply rip off the svn bandaid once and for all.
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.)
//Peter
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
Dear Patrick,
Am Dienstag, den 31.05.2011, 20:55 +0200 schrieb Patrick Georgi:
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
does that happen so often?
Given how the git read-only mirror gains popularity, maybe we should use that to our advantage and upgrade other parts of our tool set, too.
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.
Since you write Web tool, I am wondering if it is still possible to review patches on the list and to manipulate it using email or the command line.
[…]
Thanks,
Paul
Am 01.06.2011 09:31, schrieb Paul Menzel:
Am Dienstag, den 31.05.2011, 20:55 +0200 schrieb Patrick Georgi:
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
does that happen so often?
http://patchwork.coreboot.org/project/coreboot/list/ More than 100 patches unhandled, with some of them duplicates/iterations that must be tracked down manually.
Since you write Web tool, I am wondering if it is still possible to review patches on the list and to manipulate it using email or the command line.
No bridge to mail exists at this time. I think it would also be hard to map properly. But feel free to try.
Patrick
Am Mittwoch, den 01.06.2011, 10:44 +0200 schrieb Patrick Georgi:
Am 01.06.2011 09:31, schrieb Paul Menzel:
Am Dienstag, den 31.05.2011, 20:55 +0200 schrieb Patrick Georgi:
I'm officially sick and tired of patchwork. Or from losing patches to the mailing list.
does that happen so often?
http://patchwork.coreboot.org/project/coreboot/list/ More than 100 patches unhandled, with some of them duplicates/iterations that must be tracked down manually.
Well if people would mark there iterations [PATCH v2] or send them as a reply, I guess it would be scriptable. But you would have to teach/educate the developers.
Since you write Web tool, I am wondering if it is still possible to review patches on the list and to manipulate it using email or the command line.
No bridge to mail exists at this time. I think it would also be hard to map properly.
So the question is, if the developers would adapt to this new work flow using a Web interface. Most free software developers are used to email as far as I know.
They would probably need to create an account, log in every time and do some clicks before they can review something. The main developers need to commit to and embrace that new work flow.
I am doing no coreboot development and therefore do not care much. But the main developers (maybe also AMD) should be asked directly.
But feel free to try.
No time and no intentions to do so.
It might be also a good idea to ask that question on the flashrom list, since they also use the infrastructure(?) and there are some Google folks who maybe have experience with at least Gerrit.
Thanks,
Paul
Am 01.06.2011 11:01, schrieb Paul Menzel:
Well if people would mark there iterations [PATCH v2] or send them as a reply, I guess it would be scriptable. But you would have to teach/educate the developers.
Only if the tool is able to deduct which patch it is version 2 of. Once it can do that, we wouldn't need that mark.
So the question is, if the developers would adapt to this new work flow using a Web interface. Most free software developers are used to email as far as I know.
There used to be a time where no SCMs (distributed or not) were used. Traditions are nice and all - until they get in the way.
The main developers need to commit to and embrace that new work flow.
That's why I ask.
It might be also a good idea to ask that question on the flashrom list, since they also use the infrastructure(?) and there are some Google folks who maybe have experience with at least Gerrit.
I've been approached by flashrom developers already. There's no issue with keeping patchwork alive for them (and the mailing lists will continue to exist anyway).
It's just that for coreboot, the infrastructure doesn't work all that well - probably because compared to flashrom it's a less integrated package.
Patrick
On Wed, Jun 1, 2011 at 2:01 AM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:
It might be also a good idea to ask that question on the flashrom list, since they also use the infrastructure(?) and there are some Google folks who maybe have experience with at least Gerrit.
I can't say that I am an advanced user, however for simple usage cases I find Gerrit to be excellent.
A few things I like about Gerrit:
- Very good web-based side-by-side context diffs (with syntax highlighting and other nice features of native apps like gdiff, kompare, etc). One can still download a patch and apply, but I think the web-based diff saves the reviewer *a lot* of time overall since changes don't need to be downloaded and applied (sometimes with conflict resolution involved). *Saving the reviewers' time is critical.* - Better patch management. You can review side-by-side diffs of any patch revision. This is essential for reducing the burden of reviewing and to prevent patches from bit rotting IMHO. Especially true when the patch revision is >3. - Comments *do* show up in e-mail. I think there is a way to reply to comments in e-mail as well, but I always just use the web interface. - A plethora of log-in methods can be used. For chromium.org one can sign in using Open ID, a Google account, or a Yahoo account. - One-click commits are handy since you don't need to worry about sync'ing your tree
There is a learning curve with git, but I think a concise wiki entry demonstrating some a simple workflow will help people get their toes wet quickly. It's clear that many contributors on this list are already familiar (and indeed eager) to use git.
Overall, I believe e-mail is fine up to a certain point, but Coreboot and Flashrom both have enough developers contributing that it's worth moving to a more advanced SCM. Especially since a lot of changes can linger for days or weeks since hardware scarcity can often limit the ability of reviewers and testers.
-
Anders Jenbo -
Cristi Magherusan -
David Hendricks -
Patrick Georgi -
Paul Menzel -
Peter Stuge