On Fri, 19 Jul 2013 16:35:14 -0700 David Hendricks dhendrix@google.com wrote:
On Fri, Jul 19, 2013 at 4:31 AM, Stefan Tauner < stefan.tauner@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). 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 :)
And, even if we would switch to gerrit and git, I don't see how that would influence the guidelines I proposed very much. 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.
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 :)
(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@student.tuwien.ac.at wrote:
On Fri, 19 Jul 2013 16:35:14 -0700 David Hendricks dhendrix@google.com wrote:
On Fri, Jul 19, 2013 at 4:31 AM, Stefan Tauner < stefan.tauner@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.
-
David Hendricks -
Stefan Tauner