Sorry for the off-topic post. I'm looking for the following in an open source project... Imagine using bugzilla hooks, or hooks in Trac, or a new piece of "software review code" I'll call SRC, to implement the following... When a code change is proposed, make a new entry in SRC. Describe the change, add a commit message for the change, and add a patch that implements the change. Next SRC enters the "patch review state". In this state, SRC runs the patch through an automatic patch evaluation process that has hooks to check the style, build, and run tests. If the patch fails this test, the patch submitter is asked to resubmit the patch by SRC via email. If the patch passes the automatic patch submission test, it goes to the "code review state". For this state, the SRC program reviews all directories and source modules modified by the patch and determines a point value based on a point value assigned to the directories and files in the code base. The point values are used to determine the level of review required before a commit to the version code repository is allowed. Usually, commit privileges are based on a simple binary decision based on the code that is being changed and the changes account name. Here's an example of the proposed system. Someone commits a patch that touches the following directories with the following point values: Application/src 1 Lib/Math 6 Lib/GUI 5 SRC would look at this data and use the worst case required point total. In this case it would be 6 for the change made to the Lib/Math directory. Now imagine anyone registered in the SRC database could review the patch, but patch reviewers were assigned a "code reviewer quality". Account Name | Code Reviewer Quality -------------------------------------- cppexpert | 5 upandcomer | 3 newbie1 | 1 newbie2 | 1 newbie3 | 1 newbie4 | 1 newbie5 | 1 unqualified | 0 -------------------------------------- Also imagine SRC has a check box that reviewers can check to give their review approval to a patch. If they don't give their approval, the submitter must negotiate with the reviewer and possibly resubmit the patch. If this occurs the patch must pass the "automatic patch review" again and review continues. Once the sum of Code Reviewer Quality points for reviewers that have approved the patch is greater than or equal to 6, the patch is tested one more time to see if updates are needed, and if it passes this final test, the code is committed using the account of the original patch submitter and the commit message they entered in an earlier phase of the process. In this case if the "cppexpert" and anyone other than "unqualified" reviewed an approved the patch, it would be approved and committed by SRC. Reviews and approvals by the "upandcomer" account plus three additional "newbie*" reviews would also commit the patch. There could also be an optional "software design/architecture review state" added up front that disallows the submission of a patch until the proposed changes have passed a similar point based review. A person in the SRC system may be assigned different Quality values for different tasks. For instance the "cppexpert" might have a 5 rating for "Code Reviewer Quality", but a 2 rating for "Design Reviewer Quality". For "designexpert" it might be the opposite. Does anyone know of such a beast that is available as open source? Where should I post such a question? Pete PS I currently implement this by restricting commit privilege to critical directories to myself to force peer code review. Unfortunately, this means I'm the only member of the team that can commit in these directories. So there is currently a binary system that says "only I can commit here" which means "I want the code committed to this directory to be thoroughly reviewed". The only way I could guarantee thorough code review was to lock everyone else out and review everything myself. I want a system that will change this. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
