Ok. Thank you! I will try PeerReviewPlugin then. As for workflows. I believe that we cannot use it for our purposes. The matter is that we do not require all code to be reviewed (since we don't have Code Review now and if we begin to make a full reviewing it may cause bad reaction from our developers :)). Our idea is: review can be done by anyone who has access to the trac but nobody should register tickets to be reviwed (sure one ace but not ought to) since it requires additional actions from a developer ;). Later we might change our policy to have a workflow...
On Jan 31, 3:03 am, Stodge <[email protected]> wrote: > The peerreviewplugin is ok, except it has one major flaw that makes > it unusable - (from memory!) you have to manually enter the lines > numbers of thecodeyou want toreview. This is impractical for large > reviews. > > On Jan 30, 2:22 pm, [email protected] wrote: > > > > > On Jan 30, 3:43 am, Sergey Marchenko <[email protected]> wrote: > > > > Hi There, > > > > I am very new Trac user and my question might be not in correct place, > > > sorry. > > > > We would like to organize ourCodeReviewprocessthat can be tracked > > > by Trac. You have done almost all things we need: you have timeline > > > and change set details page. The only thing we need is to addCode > > >reviewicon near each change set record (just reviewed or not) and > > > support for comments, possibility ofcodereviewconfirmation or > > > rejection (with notification) on Change set details page. > > > > So my questions are: > > > 1. Do you have such functionality (plugin, etc) in current version of > > > Trac? If yes could you please point me to right direction (I have seen > > > the Plugin list but failed to find anything that we can use for > > > reviewing purposes). > > > 2. If you don’t have this functionality than can it be implemented as > > > a plugin or changes in Trac are necessary? > > > > Thx. > > > I think you'd need to make/use a plugin. There is acodereview > > plugin: PeerReviewPlugin that might be part of the solution you are > > after. > > You would also likely want to customize a workflow for this. We did > > this. We use a trunk/feature branch strategy, and a custom workflow > > for a "feature branch" ticket type (a master ticket for the feature) > > using the TypedTicketWorkflow. a feature ticket can't be merged back > > to trunk untilcodereviews have been completed on all work in the > > feature. Then the feature branch must be integration tested ,finally > > if all that passes, it can be closed as merged with a merge operation > > via a subversion post commit hook. Not exactly what you are asking > > for... > > > Another option could be to have every new ticket be a master ticket, > > and create a blocking "codereview" ticket that prevents it from being > > closed until thecodereviewhas been completed. I have been > > contemplating a way to use subversion properties + a plugin to > > automate this. Maybe with verison of the Agilo fork of trac which > > allows creating and display of "linked" tickets. > > > Some thoughts anyway.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
