[flashrom] Proposed changes to flashrom hosting and workflow

David Hendricks dhendrix at google.com
Tue Aug 11 22:57:37 CEST 2015


On Tue, Aug 11, 2015 at 2:25 AM, Patrick Georgi <pgeorgi at google.com> wrote:

> 2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at 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 at flashrom.org
> http://www.flashrom.org/mailman/listinfo/flashrom
>



-- 
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20150811/9665020c/attachment.html>


More information about the flashrom mailing list