[flashrom] New development guidelines after 0.9.7
dhendrix at google.com
Sat Jul 20 04:36:53 CEST 2013
(don't mean to get too off-topic into a discussion of tools, but it
seems that ship has already sailed...)
On Fri, Jul 19, 2013 at 5:11 PM, Stefan Tauner
<stefan.tauner at student.tuwien.ac.at> wrote:
> On Fri, 19 Jul 2013 16:35:14 -0700
> David Hendricks <dhendrix at google.com> wrote:
> > On Fri, Jul 19, 2013 at 4:31 AM, Stefan Tauner <
> > stefan.tauner at student.tuwien.ac.at> wrote:
> > > I think it is a bit sad that almost all discussion in this thread is
> > > focused on the VCS to use and not about the guidelines. Apparently
> > > emotions regarding the tools are much more intense than about the
> > > created work.
> > >
> > Maybe it's a sign?
> > (Hint: re-read *all* the stuff you wrote, and then reconsider what Marc
> > said about automation)
> It certainly is a sign of frustration, but if I look at coreboot
> reviews I would even feel vindicated that the tools are not so
> important and one needs to set some rules, because frankly speaking...
> the coreboot review process has become pretty crappy lately AFAICS (but
> I am not that involved, maybe it was always like that).
Interesting. IMO the development and review process for flashrom seems
incredibly manual and tedious by comparison.
But you and Carl-Daniel do a most core flashrom work, so this is
largely about finding something you guys can agree on that will also
make patch submission less painful for others.
> Things like
> Peter's patch that got merged although he did not want that and that he
> reverted afterwards etc. are a clear sign that there are some missing
> rules IMHO :)
I think the tools which exist for coreboot could have preventing that
from happening without a bunch of arbitrary rules. Don't want a patch
submitted? Mark it as -2 until it's ready. Need to insert a patch into
a series? Upload your branch with it, gerrit will list it explicitly
and jenkins will rebuild with it to verify it doesn't break other
patches in the series.
> And, even if we would switch to gerrit and git,
Feel free to substitute git/gerrit/jenkins with tools of your
choosing. Anything to automate enforcement of guidelines and provide
quick feedback for patch submissions will be a step in the right
> I don't see how that
> would influence the guidelines I proposed very much.
The guidelines are fine. It's the implementation that's troublesome.
Git hooks (server and client-side) could help to enforce a few of your
guidelines automatically. Anything to provide quick feedback to
developers and reduce overall turnaround time is a step in the right
> Yes, maybe there
> would be more reviewing and that would ease the problem of endless
> patch queues, but that would just be the same uncontrolled process -
> just faster.
Obligatory Simpsons reference: There's the right way, the wrong way,
and the Max Power way!
The simple fact is that coreboot developers have an easy-to-use and
integrated solution for tracking outstanding patches, checking review
status, ensuring patches build, and merging them. For most situations
a reviewer doesn't even need to download and apply the patch(set),
though the option is there if desired.
(I also like gerrit's UI for doing code reviews, commenting, and
reviewing a patch's history. But that's just a matter of taste.)
> So while I recognize the wish for changing tools, the pain would not go
> away just by switching them and we should discuss the process
> nevertheless :)
True, the pain will not all go away. But at least it would not be
death from 1,000 papercuts like flashrom is today.
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
More information about the flashrom