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