[LinuxBIOS] #31: Do proper checking for flash erase for SST FWH parts

Segher Boessenkool segher at kernel.crashing.org
Mon Nov 6 00:49:32 CET 2006

>> The Linux Kernel guys seem to think otherwise.
> 1. There are _lots_ of people hired full time to check no patches  
> get lost.

They're not lost, they are still in people's inboxes (unless
they deleted them) and in the ML archive.

There is only one guy working fulltime taking care of all
orphan Linux patches (well not fulltime really, even), FWIW.

> 2. Patches still get lost or stay ignored pretty often.

If the author still cares, he can ping the patches after
some certain period of time (don't be too impatient).

If really everyone is too busy or just no one cares, well,
tough luck, that has nothing to do with what tools they
use to run their business.

Of course it helps for a huge project like Linux that someone
like MM regularly sweeps up all (small) patches that look good
enough to him and/or whoever reviewed them on the list, to
have those patches simmer in his experimental tree for a while.

At the other side of the spectrum, there are projects like GCC,
where patches frequently are ignored or at least not reviewed
for a month or more.  Most such patches are huge invasive patches
requiring in-depth specialistic knowledge of what that patch is

Does that mean such patches should then just be "let in" without

Does it mean that we should keep a subset (namely, the new patch
contents) of our development mailing list in a separate database
(the tracker)?  Would that really be harder to ignore (for the
"bad guys") or easier to keep up with (for the "good guys")?


More information about the coreboot mailing list