También estoy decepcionado con PeerCodeReview. Ata comentarios a una revisión específica, y cuando "reenvía" una revisión más reciente para su revisión, está cerrando la revisión anterior y abriendo una nueva, ¡pero todos los comentarios se quedan en la revisión anterior solamente! Por lo tanto, no hay una manera fácil de ver un comentario junto con la fuente más reciente que lo aborda. Junto con la falta total de soporte para revisar commits/diffs, esto hace que PeerCodeReview no sea adecuado para mí.
El plugin de CodeReview parece agradable (en realidad no lo intenté), pero todavía echo de menos la posibilidad de comentar líneas específicas.
No debería ser que mi caso de uso no fuera una "revisión de código" clásica, sino que revisara un único documento LaTeX. Esto tiene diferentes requisitos:
No es necesario revisar antes de una confirmación; por el contrario, un flujo de trabajo "pipeline" es crítico: los comentarios de revisión se crean cuando el revisor tiene tiempo libre, y se dirigen cuando el escritor los recibe, con frecuencia en confirmaciones posteriores.
Sería bueno hacer un seguimiento de qué partes del texto se han revisado en qué revisiones.
Esto no es crítico, ya que la revisión generalmente se realiza una sección a la vez y es fácil suficiente para rastrear manualmente.
Hay muchos pequeños comentarios independientes. Cada comentario debe rastrearse de forma independiente, una única resolución de "aprobación/rechazo" para una confirmación.
La mayoría de los comentarios son bien localizadas en el archivo, por lo que quieren un flujo que permite unir a lugares específicos en el archivo, y ellos deben tener su lugar cuando el archivo es editado.
El derecho flujo para esto sería abrir una entrada para cada comentario, cerrándolos con cometer ganchos cuando se le habla. El único problema es que no hay una manera fácil de vincular un ticket a líneas específicas en el archivo, lo que lo hace bastante engorroso. Estoy tentado de escribir un complemento minimalista que vincule los tickets a las líneas fuente/diff. ¿Alguien más le gustaría tal bestia?
Lo que probablemente haré en la práctica es poner los comentarios de TODO dentro de la propia fuente y no utilizar la interfaz de Trac de lujo en absoluto para esto. El control de versiones se asegurará de que los comentarios permanezcan donde pertenecen entre ediciones.
[específicamente para el látex, probablemente usará los todonotes y/o fixme paquetes para mostrar los comentarios muy bien, y tal vez latexdiff para ficheros diff visuales.] Voy a editar esta tarde para informar de cómo ha ido ...
Por cierto, este enfoque no se limita a los documentos: he trabajado con un equipo que lo usó mucho para la revisión de código durante el desarrollo ágil intensivo y funcionó bastante bien.Tenían un deseo similar de "canalizar" el proceso de revisión: el desarrollo debe continuar, pero todos los cambios deben revisarse antes de hacer una publicación. La parte más difícil fue rastrear lo que se revisó o no, lo que se hizo marcando revisiones "limpias" y diferenciándolas; en retrospectiva, tener una rama "revisada" y "cherry-picking" en ella funcionaría mejor. (Por supuesto, las preguntas arquitectónicas no localizadas entrarían en las entradas de Trac, o comenzarían como comentarios de HACER y se migrarían a las entradas si resultaran no triviales)
También hay GvnTrac: http: //projects.matt-good.net/trac/gvntrac, estas aplicaciones en trac-hacks: http://trac-hacks.org/tags/%27codereview%27, y es posible que también quiera echarle un vistazo a esta entrada : http://trac.edgewall.org/ticket/2035. – RjOllos
Vea también: https://github.com/Automattic/trac-code-comments-plugin que parece actual e interesante –