<div class="gmail_quote">On Sun, May 31, 2009 at 10:56 AM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com">rminnich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Sat, May 30, 2009 at 9:01 PM, Peter Stuge <<a href="mailto:peter@stuge.se">peter@stuge.se</a>> wrote:<br>
<br>
> I would like to request a better patch management system than this<br>
> mailing list. The fact the above "ping" is now a part of our<br>
> development process is a very strong indication that things are not<br>
> functioning very well.<br>
<br>
</div>it's a hard problem. I'm on several projects. They are all non-ideal<br>
in some way. Linux sucks in patches at the rate of 30,000 a year or<br>
so; that's fine performance but some feel (me included) that the<br>
kernel is "de-cohering": it no longer has the small tight feel and<br>
coherence of vision that it might have once had. Plan 9 still has the<br>
same tight feel and coherence but at a cost: important patches seem to<br>
linger on the vine for (i am not kidding here) years .<br>
<br>
Coreboot is trickier than a kernel, as trivial errors can lead to<br>
systems that can not be recovered. I especially avoid acking flashrom<br>
patches because I can't test most of them. Others I know don't like to<br>
NAK, but they're not comfortable with an ACK either; they don't like<br>
the code but they don't want to hold up progress.<br>
<br>
All in all, I think the process works. Yes, it is not ideal.  Yes, it<br>
could be better, but so could everything.<br>
<font color="#888888"><br>
ron<br>
</font><div><div></div><div class="h5"><br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br>Indeed, changing the whole process might not be worth the effort considering the trade-offs. There are some tools that can make the current process a lot less painful, however, specifically <a href="http://ostatic.com/blog/open-source-code-review-tools">web-based code review dashboards</a>. <a href="http://www.review-board.org/">Review Board</a> from the folks at VMWare looks really good, and <a href="http://code.google.com/p/rietveld/">Rietveld</a>, which is a relatively new open-source fork of Google's <a href="http://www.youtube.com/watch?v=sMql3Di4Kgc#t=25m20s">Mondrian</a> code review tool, is quite helpful as well though it seems behind RB at the moment.<br clear="all">

<br>-- <br>David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.<br>