plugins - plantillas - Trac: complemento de revisión de código

install doku wiki (4)

Creo que PeerCodeReview es mejor para lo que quieres.

Sin embargo, el póster anterior es correcto: debe buscar en el repositorio de origen y seleccionar el código que desea revisar y anotar. No sabe nada sobre los conjuntos de cambios.

Esto está bien si tienes a alguien (como un arquitecto o líder) que está mirando proactivamente el código e identificando cosas que pueden ser problemáticas.

No funciona tan bien si desea revisar cada fragmento de código en lo que se refiere a un cambio.

Si está buscando algo que se asocia con commits, y maneja diffs, mire en ReviewBoard (una aplicación de DJango):

Estoy buscando un complemento de revisión de código para nuestra instalación de trac .

Encontré estos dos como el resultado principal para la consulta de " revisión del código de trac " en google

Me estoy inclinando hacia el plugin PeerCodeReview.

Solicitar a la comunidad de SO información sobre estos complementos para que me ayude a seleccionar uno para nuestra instalación de trac.

Si conoce otros plugins, hágamelo saber también. :)

Lo que estoy buscando en el complemento

Una forma de anotar el código con comentarios.
Aprobar / desaprobar; como un botón para informar que el código debe cambiar. tal vez se crea un error.
Una forma de asignar la revisión de código "Tarea" a una persona (s).

La primera característica es obligatoria (supongo que ese es el punto); otros son opcionales Puedo hackear Trac para obtener algo similar que se ajuste a ese flujo de trabajo. ¡Ojalá! ;)

En mi compañía, miramos brevemente el plugin "peerreview" en TracHacks, y estábamos muy decepcionados con él.

Parece obvio para nosotros que un complemento de revisión de código sería predeterminado de forma natural al asumir que toda la confirmación de Subversion debería ser revisada por el código. Desafortunadamente, el plugin peerreview te obliga a identificar manualmente las líneas de código que deseas revisar. Ni siquiera te da pistas sobre qué líneas podrían haber cambiado con una confirmación en particular, lo que significa que si no ingresas la línea que cambió cuidadosamente, podrías terminar re-revisando las mismas líneas de código una y otra vez.

No hemos tenido la oportunidad de revisar el otro complemento (CodeReviewPlugin) en detalle.

Estábamos en la misma situación. Al final optamos por instalar Review Board en paralelo a Trac. Si bien no es un complemento de Trac, es una herramienta excelente, y hasta ahora estamos muy contentos con él.

También tiene soporte básico de Trac, por lo que, por ejemplo, cuando revisas las correcciones de errores, obtienes enlaces automáticos al ticket de Trac.

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 CodeReview parece agradable (en realidad no lo intenté), pero sigo echando 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 " canalizado " es crítico: los comentarios de revisión se crean cuando el revisor tiene tiempo libre, y se abordan cuando el escritor llega a ellos, con frecuencia en confirmaciones mucho más tarde.
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 de una sección a la vez y es fácil seguirla 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 están bien localizados en el archivo, por lo que quiero un flujo que permita unirlos a lugares específicos del archivo, y ellos deben mantener su lugar cuando se edite el archivo.

El flujo correcto para esto sería abrir un ticket para cada comentario, cerrándolos con commit hooks cuando se dirijan. 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 fuente misma y no utilizar la interfaz de Trac para nada. El control de versiones se asegurará de que los comentarios permanezcan donde pertenecen entre ediciones.

[Específicamente para LaTeX, probablemente fixme paquetes todonotes y / o fixme para mostrar los comentarios muy bien, y tal vez latexdiff para los diffs visuales.] latexdiff esto más adelante para informar cómo fue ...

Por cierto, este enfoque no se limita a los documentos: he trabajado con un equipo que lo usó mucho para revisar el código durante un 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 sucursal "revisada" y seleccionarla de manera selectiva funcionaría mejor. (Por supuesto, las preguntas arquitectónicas no localizadas entrarían en las entradas de Trac, o comenzarían como HECHO de comentarios y se migrarían a las entradas si resultaban no triviales).