On Tue, Aug 11, 2015 at 2:25 AM, Patrick Georgi <pgeorgi@google.com> wrote:
2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
@Stepan:
It would be good to know which of patchwork or svn (or both) cause extra
maintenance burden. 
AFAICS at least svn seems to be automatically getting security updates
on ra (coreboot server).
We run apache (with mod_dav_svn) just for svn. It's automatically updated alright, but it still increases the system's surface.
 
If we migrate off patchwork, is there a way to keep/import the old data
into some other tool?
Since it's unstructured data that will be hard to automate.
 
Hm. In the end, we have to decide whether the tree will be managed
directly by humans or indirectly via Gerrit. I doubt we can have both at
the same time without pretty explosions.
Even with gerrit, it's always managed by humans. Gerrit never presses the 'submit' button by itself.

And if a patch doesn't apply cleanly to the current top of tree gerrit won't be able to commit it.

I'd argue that there's less of a risk of "pretty explosions" with Gerrit, since developers will be less likely to push with additional local changes accidentally applied.

Though I know stefanct often makes small corrections/modifications to patches before submitting them (because our code review process makes even small amounts of back-and-forth comments so cumbersome). At least this way such changes can be tracked trivially on-line by diffing the N and N-1 patch revisions in gerrit.
 
I assume the switch was done to get some gerrit features (jenkins integration) not present in patchwork.
The switch was done because patchwork became a dumping ground for non-actionable diffs.

The main advantages of gerrit over patchwork (IMHO) are:
1. you can directly work from the list of open commits (in patch work you can only reply by hunting down the thread that it archived in your local mail client. if you weren't subscribed back then, you're out of luck)
2. through the git push model of contributing you're guaranteed to have context for the commit. compare "all history that leads to this commit" to the diffs in patchwork: uh, that might be based on r5200 or maybe r1500 or is it even manually edited and doesn't apply cleanly to anything?

#2 will also help us deal with the reality of lack of developer time and bit rotting patches. Gerrit makes rebasing stale patchsets reasonably straight-forward and simple. As Patrick says, the current state of many patches on patchwork is non-actionable - Tracking down whatever revision they apply to and dependencies for a patchset makes it very time-consuming and error-prone.

To make matters worse, once a developer has applied patches and gotten things in a working state again, properly applying individual fixes to >1 patch in a series is excruciating. That's why we have developers pointing at external git servers with patchsets applied rather than uploading rebased patches to the mailing list.
 

That we automatically test-build the commits and thus have some basic sanity checks is a very useful bonus. But at least for me that wasn't the reason for switching tools.


Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

_______________________________________________
flashrom mailing list
flashrom@flashrom.org
http://www.flashrom.org/mailman/listinfo/flashrom



--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.