So now that we have several new committers on Allura, I think its time to talk about how we want to handle reviewing & merging code into Allura. I'll give an overview of how we at SourceForge have been doing it so far, but I think it will need some modifications.
1. create a ticket for the issue 2. assign the ticket to yourself 3. create a branch (we name them with our initials and ticket number, like db/1234) 4. commit & revise as much as needed on that branch, until ready 5. change the ticket status to "code-review" and put enter another developer into the QA field 6. the "QA" developer reviews the changes in the branch, to make sure the code is good, functionality is correct, no performance or security concerns, tests are present, etc 7. the reviewing developer merges the branch to master and closes the ticket This works well for us, so personally I'd be interested in continuing a process similar to this. However, I think #5 at least needs more thought. Since SourceForge has several full-time developers working on Allura (and other internal things too), we work on a lot of tickets, and regularly check our QA queue to review each others' tickets. How do we get the rest of the Allura committers involved? Assigning tickets to people puts a responsibility on them to do that review, which isn't appropriate at Apache. Maybe we could just change tickets to "code-review" status and not assign a reviewer. Then there would be a pool of tickets and anyone can take any ticket from that pool to review it. SF employees would probably take a lot of them, but that's ok, at least it wouldn't be exclusive to us then. What do others think about this process? Changes to it? Something completely different? I think it'd be good to get a broad perspective here, opinions from SourceForge devs, our newer committers, mentors, and anyone else is encouraged -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
