On Tue, Aug 11, 2015 at 2:25 AM, Patrick Georgi <[email protected]> wrote:
> 2015-08-11 2:28 GMT+02:00 Carl-Daniel Hailfinger < > [email protected]>: >> >> @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 > [email protected] > http://www.flashrom.org/mailman/listinfo/flashrom > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
_______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
