[flashrom] New development guidelines after 0.9.7

[David Hendricks]

(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
direction.

> 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
direction.

> 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.