[LinuxBIOS] commit rules

[Stefan Reinauer]

* ron minnich <rminnich at gmail.com> [061021 00:41]:
> I don't understand the process.
 
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.

This is going to happen via the tracker eventually, as soon as all
infrastructure is in place. 

So each patch should "belong to" either a feature enhancement or a bug fix
(whereas "cleanup" would count as the later). As in: No code goes in
that does not serve a (documented) purpose. 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"

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)

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.

Note: This is not about restricting people to do their check ins.
It is still possible to sign off your own patches and get them committed
this way. But this should not be used to render the whole review and 
documentation tracability process useless. 

If you add a new board and dont change any other code, nobody will care 
if you sign it off yourself, because without the hardware nobody will be
able to give anything but well-intentioned hints.

> How does it work? Do I do svn commit, and someone else signs it off?

For now:

- send a patch to the mailing list and/or ask someone to review it.
- If you get the review within some amount of time, go ahead and check
  it in with the "foreign" signed-off-by
- If you dont get the review, send another mail explaining why you 
  check the code in anyways (ie. This is 3 lines of code adding a new
  flash chip to "flashrom", no review required)
  and commit the patch signed off by yourself.

For trivial stuff waiting for a review might not make sense or be
necessary. For infrastructure changes and cross-board features however,
we should take the time to do reviews.

Stefan

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/