Changes between Version 53 and Version 54 of PeerReviewPlugin


Ignore:
Timestamp:
Apr 3, 2008 11:07:15 PM (6 years ago)
Author:
proofek
Comment:

Moved user comments to a separate ticket

Legend:

Unmodified
Added
Removed
Modified
  • PeerReviewPlugin

    v53 v54  
    5252 
    5353== User Comments == 
    54 Got some comments about our plugin?  Leave them right here. 
    5554 
    56 ==== Comment by anonymous on Sun 23 Apr 2006 08:36:39 EST ==== 
    57 Can you put a screenshot? Thanks! 
     55If you have any comments about the plugin or/and you would like to join the discussion please see [http://trac-hacks.org/ticket/2850 this ticket]. 
    5856 
    59 ==== Comment by Team5 on Wed 26 Apr 2006 06:21:52 EST ==== 
    60 We sure can - see below.  Thanks for the suggestion. 
    61  
    62 ==== Comment by Tim on Mi 10 mai 2006 21:22:15 EST ==== 
    63 We use Trac and Subversion, but when we do a code review, the author of the code changes sends the source files he changed to other engineers via email, and they place these files into their working directory, and use subversion diff to compare the working directory with the latest source in repository. All of the changes made by the author are then very clear, and comments can be sent back to the author via email, incorporated/discussed, and then new code changes sent out for review. Obviously, this approach works, but would be much better if it was integrated into Trac. Anyway, I have looked at your documentation, and unless I am mistaken you require the code changes to be committed into repository first, then your code is used to mark each line that was changed, and needs to be reviewed. Is this correct ? If so, do you have any plans to store the code changes into a temporary location, and use subvresion diff to compare with the HEAD revision in the repository, so that the changes are very clear to the person reviewing the code ? 
    64  
    65 ==== Comment by szm on Ma 30 mai 2006 04:31:24 EST ==== 
    66 This plugin would be much more interesting if it could compare svn diffs rather than having the user mark the changes manually, which is error prone, and difficult to compare against the previous version. 
    67  
    68 ==== Comment by anonymous on Vi 02 iun 2006 18:13:27 EST ==== 
    69 It seems that the plugin interferes with the "source:" form of wiki links. These links do only return a div element, like it may be suitable for ajax requests. Is there a workaround? 
    70  
    71 ==== Comment by anonymous on Vi 02 iun 2006 18:17:26 EST ==== 
    72 hm. and "Add comment" implemented as GET request will lead to the above for people like me, who hit reload every once in a while. 
    73  
    74 ==== Comment by moisei _ at _ gmail.com on Du 02 iul 2006 07:50:19 EST ==== 
    75 [http://codestriker.sourceforge.net Codestriker] has really good concept on 
    76 the code-review process. They use a "source code diff" as the item of review rather than "part of code" as it is done in this plugin. 
    77 Do you have any plans to move in this direction? I wish to have our code review 
    78 integrated with trac and I even raised some [http://lists.edgewall.com/archive/trac/2005-September/004772.html discussion] on this topic. 
    79  
    80 ==== Comment by anonymous on Tue Oct 17 00:52:10 2006 ==== 
    81 So is this plugin going to be updated to v0.10 and beyond? 
    82 And will it be updated to work with changesets as opposed or in addition to revisions? 
    83  
    84 For peer reviews to be most successful, the actual changes to the files should be highlighted automatically by the revision control system (which the changeset view already does), and allow annotations on the entire file. 
    85  
    86 ==== Comment by anonymous on Tue Oct 17 22:59:39 2006 ==== 
    87 So is this plugin going to be updated to v0.10 and beyond? 
    88 And will it be updated to work with changesets as opposed or in addition to revisions? 
    89  
    90 For peer reviews to be most successful, the actual changes to the files should be highlighted automatically by the revision control system (which the changeset view already does), and allow annotations on the entire file. 
    91  
    92 ==== Comment by anonymous on Thu Dec  7 02:22:25 2006 ==== 
    93 The plugin would be usable for me if: 
    94  * I could use diffs of arbitrary revisions and/or paths in the repository (tags, trunk, branches etc.) 
    95  * I could also use plain source at specific revision at the same time (like for initial review of old code) 
    96  * The commenting process is more like http://gplv3.fsf.org/comments/gplv3-draft-2.html where its indicated which are is a "hot" area and much discuessed. Maybe also with an additional option to have colors not for heat but for age of the latest comment(s) 
    97  
    98 ==== Comment by tag@cpan.org on Thu Dec  7 05:30:33 2006 ==== 
    99 I'm working on driving a project to replace this.  It will have a better functional design, and be more useful to organizations that actually need to implement a real code review process.  The goal is to build something we (the folks involved) can all use at our respective organizations of employment. 
    100  
    101 The project is only in the deciding what needs to be done phase (discussions and requirement gathering began 2006/12/04). 
    102  
    103 It lives here: http://www.blisted.org/wiki/projects/JianCha 
    104  
    105 ==== Comment by Anonymous on Sat Feb 16 10:10:33 2008 ==== 
    106 Just for a reference project -- you might take a look at "Review Board" (http://code.google.com/p/reviewboard/).  It looks like an excellent open source, python-based code-review project, which allows integration with Subversion, Mercurial, and several other revision-control systems.  Perhaps it wouldn't be difficult to re-use some of the code from review board in this plugin. 
    107  
    108 ==== Comment by Maik on March 10 10:12:33 2008 ==== 
    109  
    110 What is teh current status of this project? Is it still being developed? I think it's a great start, and = in principle - exactly what I am looking for (which is a TRAC based code review system). Unfortunately, as many people stated before me, there are still many features and functionality missing to make it "production ready". 
    111 Do you need help or manpower to develop this any further or is ths project sort of "closed"?  
    112  
    113 ==== Comment by Geib on April 3 13:54:22 2008 ==== 
    114  
    115 We use Trac alot and this tool has been something we have looked for a number of time. We have even used CodeStiker a bit. We would like the integration with Trac and also offer any help.  
     57I have moved every comments from here to that ticket to make the main wiki page more visible and pure informative.