[LinuxBIOS] commit rules

[Segher Boessenkool]

> 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