> 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 -- linuxbios mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
