[LinuxBIOS] commit rules
Segher Boessenkool
segher at kernel.crashing.org
Sat Oct 21 11:35:53 CEST 2006
> The goal of the process is to make changes trackable even after a
> longer
> period of time. Therefore there needs to be a connection between
> checkins and the discussion on the associated topics.
There's a mailing list archive, every patch gets sent to the
mailing list for review --> it's trackable (although a pain
to find the right threads sometimes, esp. if people break
the ML threads).
> As in: No code goes in
> that does not serve a (documented) purpose.
A good check in comment would state that purpose anyway.
> At some point when we are
> doing LinuxBIOS v4 or v5, we might even go as far as "no code goes in
> that has no automated test case that the code does what it is
> required to do"
Good :-)
> And no code should go in that has not been reviewed. We do need to
> find
> a solution on review timeouts (code has to be reviewed within ...
> hours/days or it can go in without,.. thats what Yinghai did with the
> AM2 code while we were at the symposium)
How about: only maintainers (of the code under discussion) can approve
a patch (and they can approve their own). Patches should _still_ be
sent to the mailing list of course (and in most cases it would be
prudent to not check in before it has been out for review for a few
days).
> Until the tracker side of things is up and running, we should send
> mails
> to the mailing list, as we've been doing recently, and have someone
> review it there. As we have been doing it already.
Please even with a tracker keep it on the mailing list as well. Mail
works offline, is distributed, has built-in redundancy -- all things
that a centralised web-based thing does not.
Let's keep the whole "process" thing as flexible and unobtrusive as
possible?
Segher
More information about the coreboot
mailing list