* ron minnich rminnich@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