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