OT Software Review Code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux