Hello,
I'm looking at creating a bundle that can be used to provide peer code reviews making use of TextMate for the majority if not all of the process. I'm looking for high level input/suggestions. Does anyone else think this would be helpful to them? Anyone else want to work on this with me?
The high level process of this goes like this: ( A database is used to store a code file for review and all comments submitted against that file. This allows metrics to be reported on as well as allowing any number of people to review the same code at the same time from many different locations. This also allows the status of comments to be tracked and changed and what not. I think I can push and pull data from a database pretty easily from TM. I'm looking at targeting PostgreSQL.)
0. Code creator submits a file to be reviewed via TM.(Submitting actually inserts the code into the database) 1. Reviewer/s retrieves the stored file from the database and the file contents are displayed in TM(This is all done via TM). 2. Reviewer/s comments on a line by line basis or select multiple lines and comment via TM. Each comment should have a status such as BUG, STANDARDS BROKEN, GENERAL, etc. I'm thinking of using GUI integration to allow data input. 3. Code creator can comment on the comments left by a reviewer/s via TM. Example "I did this because of XYZ". 4. Code creator makes fixes in their code via TM based on reviewer/s comments. 5. Code creator submits changed code. 6. Reviewer/s can then flag a comment as FIXED, COMPLETED, CLOSED etc. These would be user configurable values I'm just showing these ones as an example. 7. Repeat 0 to 6 until all comments are in a FIXED/COMPELTE/CLOSED state. 8. Mark review in the database as completed. This will keep anyone from adding new comments. But the process above will all be in the database for future reporting and what not if it's needed.
Things I wish I could do, but not sure that I can: 0. I can't mark a line in TextMate with a little graphic in the left gutter to indicate that line has a comment on it. I do see maybe using the HTML viewer like the TODO bundle does as an alternative. Is it possible to highlight a line with a specific color on the fly? Say mark a line with a BUG comment and the line will turn red and lines with comments marked as GENERAL are yellow etc etc?
Thanks in advance for any input Bob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
this is an interesting suggestion. Have you considered to use subversions (or some other version system) annotation feature instead of a dedicated database? This would integrate the code reviews with the versioning process which sounds like a nice idea. It would even give you a nice interface to determining conflicts in the review process, which could be reviewed... ;)
Greetings Florian
Bob Henkel wrote:
Hello, I'm looking at creating a bundle that can be used to provide peer code reviews making use of TextMate for the majority if not all of the process. I'm looking for high level input/suggestions. Does anyone else think this would be helpful to them? Anyone else want to work on this with me? The high level process of this goes like this: ( A database is used to store a code file for review and all comments submitted against that file. This allows metrics to be reported on as well as allowing any number of people to review the same code at the same time from many different locations. This also allows the status of comments to be tracked and changed and what not. I think I can push and pull data from a database pretty easily from TM. I'm looking at targeting PostgreSQL.) 0. Code creator submits a file to be reviewed via TM.(Submitting actually inserts the code into the database)
- Reviewer/s retrieves the stored file from the database and the file
contents are displayed in TM(This is all done via TM). 2. Reviewer/s comments on a line by line basis or select multiple lines and comment via TM. Each comment should have a status such as BUG, STANDARDS BROKEN, GENERAL, etc. I'm thinking of using GUI integration to allow data input. 3. Code creator can comment on the comments left by a reviewer/s via TM. Example "I did this because of XYZ". 4. Code creator makes fixes in their code via TM based on reviewer/s comments. 5. Code creator submits changed code. 6. Reviewer/s can then flag a comment as FIXED, COMPLETED, CLOSED etc. These would be user configurable values I'm just showing these ones as an example. 7. Repeat 0 to 6 until all comments are in a FIXED/COMPELTE/CLOSED state. 8. Mark review in the database as completed. This will keep anyone from adding new comments. But the process above will all be in the database for future reporting and what not if it's needed. Things I wish I could do, but not sure that I can: 0. I can't mark a line in TextMate with a little graphic in the left gutter to indicate that line has a comment on it. I do see maybe using the HTML viewer like the TODO bundle does as an alternative. Is it possible to highlight a line with a specific color on the fly? Say mark a line with a BUG comment and the line will turn red and lines with comments marked as GENERAL are yellow etc etc? Thanks in advance for any input Bob
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
I have thought about this and was thinking of using the TODO bundle to help out with this. I think avoiding the database approach would simplify things. It might not be as industrial strength, but is a much simpler implementation.
The usage would go something like this: A person enters TODO tags within the code such as --BUG OPEN BLH This code is junk fix it please! The The format could be something like --<TYPE> <STATE> <INITIALS> <COMMENT>
After someone reviews a file they submit it to source control with their review comments included in the source. The only problem I see is if two separate reviewers comment on the same line when it comes time to submit to source control who's comment wins? This is what leans me back to a database implementation. My assumption is that there may be 4 or more reviewers reviewing the same code at any given time.
Thanks Bob
On 4/16/07, Florian Gilcher flo@andersground.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
this is an interesting suggestion. Have you considered to use subversions (or some other version system) annotation feature instead of a dedicated database? This would integrate the code reviews with the versioning process which sounds like a nice idea. It would even give you a nice interface to determining conflicts in the review process, which could be reviewed... ;)
Greetings Florian
Bob Henkel wrote:
Hello,
I'm looking at creating a bundle that can be used to provide peer code reviews making use of TextMate for the majority if not all of the process. I'm looking for high level input/suggestions. Does anyone else think this would be helpful to them? Anyone else want to work on this with me?
The high level process of this goes like this: ( A database is used to store a code file for review and all comments submitted against that file. This allows metrics to be reported on as well as allowing any number of people to review the same code at the same time from many different locations. This also allows the status of comments to be tracked and changed and what not. I think I can push and pull data from a database pretty easily from TM. I'm looking at targeting PostgreSQL.)
- Code creator submits a file to be reviewed via TM.(Submitting
actually inserts the code into the database)
- Reviewer/s retrieves the stored file from the database and the file
contents are displayed in TM(This is all done via TM). 2. Reviewer/s comments on a line by line basis or select multiple lines and comment via TM. Each comment should have a status such as BUG, STANDARDS BROKEN, GENERAL, etc. I'm thinking of using GUI integration to allow data input. 3. Code creator can comment on the comments left by a reviewer/s via TM. Example "I did this because of XYZ". 4. Code creator makes fixes in their code via TM based on reviewer/s comments. 5. Code creator submits changed code. 6. Reviewer/s can then flag a comment as FIXED, COMPLETED, CLOSED etc. These would be user configurable values I'm just showing these ones as an example. 7. Repeat 0 to 6 until all comments are in a FIXED/COMPELTE/CLOSED
state.
- Mark review in the database as completed. This will keep anyone from
adding new comments. But the process above will all be in the database for future reporting and what not if it's needed.
Things I wish I could do, but not sure that I can: 0. I can't mark a line in TextMate with a little graphic in the left gutter to indicate that line has a comment on it. I do see maybe using the HTML viewer like the TODO bundle does as an alternative. Is it possible to highlight a line with a specific color on the fly? Say mark a line with a BUG comment and the line will turn red and lines with comments marked as GENERAL are yellow etc etc?
Thanks in advance for any input Bob
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGI8Ln8RlGMqQ8m7oRAgurAJ9Hk1rpiEhltXiy4zxsTiXJt4gdJACfVO5h No/QWzieDiFRy4+rbbcafjo= =hSys -----END PGP SIGNATURE-----
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think you misunderstood my intention. With svn propset, you can set arbitrary properties for a single file/directory. That gives you the possibility to use a set of file properties to keep track. In combination with a hook script, you could mark every changed line as 'unreviewed' on commit, while your bundle manages the task of changing the property back to 'reviewed' and listing the properties. (simple scenario...)
A hook script on the server side has the advantage that no client has to support you system or even know about it unless he wants to review code.
Greetings Skade
Bob Henkel wrote:
I have thought about this and was thinking of using the TODO bundle to help out with this. I think avoiding the database approach would simplify things. It might not be as industrial strength, but is a much simpler implementation. The usage would go something like this: A person enters TODO tags within the code such as --BUG OPEN BLH This code is junk fix it please! The The format could be something like --<TYPE> <STATE> <INITIALS> <COMMENT> After someone reviews a file they submit it to source control with their review comments included in the source. The only problem I see is if two separate reviewers comment on the same line when it comes time to submit to source control who's comment wins? This is what leans me back to a database implementation. My assumption is that there may be 4 or more reviewers reviewing the same code at any given time. Thanks Bob
I think you are correct. I come from a perforce environment and the ability to do what you described was somewhat alien to me. I'll have to look at the subversion way of doing things. Thanks for the information. Bob
On 4/17/07, Florian Gilcher flo@andersground.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think you misunderstood my intention. With svn propset, you can set arbitrary properties for a single file/directory. That gives you the possibility to use a set of file properties to keep track. In combination with a hook script, you could mark every changed line as 'unreviewed' on commit, while your bundle manages the task of changing the property back to 'reviewed' and listing the properties. (simple scenario...)
A hook script on the server side has the advantage that no client has to support you system or even know about it unless he wants to review code.
Greetings Skade
Bob Henkel wrote:
I have thought about this and was thinking of using the TODO bundle to help out with this. I think avoiding the database approach would simplify things. It might not be as industrial strength, but is a much simpler implementation.
The usage would go something like this: A person enters TODO tags within the code such as --BUG OPEN BLH This code is junk fix it please! The The format could be something like --<TYPE> <STATE> <INITIALS> <COMMENT>
After someone reviews a file they submit it to source control with their review comments included in the source. The only problem I see is if two separate reviewers comment on the same line when it comes time to submit to source control who's comment wins? This is what leans me back to a database implementation. My assumption is that there may be 4 or more reviewers reviewing the same code at any given time.
Thanks Bob
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGJNk58RlGMqQ8m7oRAuOqAJ9JzIpxbmTCQqS7gkDA2u9BHdTnsQCfeaI9 xcFzGHkAOzt3rAQKwyzpO2Q= =jo5L -----END PGP SIGNATURE-----
For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate
-
Bob Henkel -
Florian Gilcher