Trac: Code-Rezension-Plugin

Ich bin auf der Suche nach einem code-review-plugin für unsere trac installation.

Fand ich diese beiden als top-Ergebnis für " trac code-review " - Abfrage auf google

Ich bin Neigung in Richtung PeerCodeReview plugin.

Erbitten, die, SO Gemeinschaft für die Eingänge zu diesen plugins, um mir zu helfen wählen Sie für unsere trac-installation.

Wenn Sie wissen, über alle anderen plugins bitte lassen Sie mich wissen, über diese als gut. 🙂

Das, was ich Suche in der plugin -

  • Eine Möglichkeit zum kommentieren von code mit Kommentare.
  • Genehmigen/Dis-genehmigen ; wie eine Art von Schaltfläche zu informieren, dass code geändert werden muss. vielleicht ein bug ist erstellt.
  • Einen Weg zu weisen code-review "Aufgabe" einer person(s).

Die erste Funktion ist erforderlich (ich denke, das ist der springende Punkt); andere sind optional. Ich kann hack-trac zu bekommen, etwas ähnliches einzubauen, dass workflow. Hoffentlich! 😉

InformationsquelleAutor der Frage xk0der | 2009-06-04

  1. 6

    Waren wir in der gleichen situation. Am Ende entschieden wir uns für die Installation Review Board parallel zum Trac. Es ist zwar kein Trac-plugin, es ist ein hervorragendes Werkzeug, und so weit wir sind sehr zufrieden mit ihm.

    Es hat auch basic-Trac-Unterstützung, so dass, beispielsweise bei der überprüfung von bug fixes, erhalten Sie automatisch die links zu den Trac-ticket.

    InformationsquelleAutor der Antwort Gilad Naor

  2. 9

    In meiner Firma, wir schauten kurz im "peerreview" - plugin auf TracHacks, und waren sehr enttäuscht mit ihm.

    Scheint es uns klar, dass ein code-review-plugin würde natürlich standardmäßig auf der Annahme, dass eine gesamte Subversion-commit-code-überprüft werden. Leider, die peerreview-plugin zwingt Sie zu manuell zu identifizieren, die code-Zeilen, die Sie überprüfen möchten. Es schadet auch nicht, Sie geben Hinweise, in welche Zeilen geändert haben, die mit einer bestimmten verpflichten, was bedeutet, dass, wenn Sie nicht geben Sie die Zeile, die geändert sorgfältig, Sie könnte Ende-up re-überprüfung der gleichen code-Zeilen über und über.

    Haben wir nicht hatte eine chance zu überprüfen, die anderen plugin (CodeReviewPlugin) in jedem detail.

    InformationsquelleAutor der Antwort Eric Johnson

  3. 4

    Ich denke, die PeerCodeReview ist besser, für das, was Sie wollen.

    Der vorherigen poster ist richtig, aber-müssen Sie das Quell-repository und wählen Sie den code, den Sie möchten, überprüft und mit Anmerkungen versehen. Es weiß nichts über die änderungen.

    Dies ist in Ordnung, wenn Sie jemanden haben, der (wie der Architekt oder der Führung) , ist proaktiv mit Blick auf den code und identifiing Dinge, die möglicherweise problematisch sein.

    Funktioniert es nicht so gut, wenn Sie überprüfen möchten, jedes Stück code, wie es bezieht sich auf eine änderung.

    Wenn du nach etwas suchst, der Mitarbeiter verpflichtet sich und übernimmt die diffs, dann schauen Sie auf ReviewBoard (eine DJango-app):

    InformationsquelleAutor der Antwort Dutch Masters

  4. 3

    Ich bin auch enttäuscht, mit PeerCodeReview. Es knüpft Bemerkungen an eine bestimmte revision, und wenn Sie "Erneut" eine neuere revision zur überprüfung schließen Sie die alte abgeben und eine neue zu öffnen - aber alle Kommentare bleiben auf dem alten review nur! Es gibt also keine einfache Möglichkeit zu sehen, einen Kommentar zusammen mit der neueren Quelle, die Adressen. Zusammen mit dem völligen Mangel an Unterstützung für die überprüfung von commits/diffs, das macht PeerCodeReview ungeeignet für mich.

    Den CodeReview plugin scheint nett (wollte eigentlich nicht versuchen Sie es), aber ich vermisse immer noch die Möglichkeit zu kommentieren auf bestimmten Linien.

    Sollte ich nicht, dass meine Verwendung nicht dem klassischen "code-review", aber für ein einzelnes LaTeX-Dokument. Dies hat verschiedene Anforderungen:

    • Überprüfen, bevor ein commit ist nicht erforderlich; im Gegenteil, eine "Pipeline" workflow
      entscheidend ist: der review-Kommentare werden erstellt, wenn der Rezensent hat Freizeit
      und behandelt, wenn der Schriftsteller bekommt Sie, Häufig viel später verpflichtet.

    • Wäre es schön, zu verfolgen, welche Teile des Textes wurden überprüft, was Revisionen.

      Dies ist nicht kritisch, da die überprüfung erfolgt in der Regel ein Abschnitt in einer Zeit, und es ist leicht
      genug, um die Spur manuell.

    • Gibt es viele kleine, unabhängige Kommentare. Jeder Kommentar sollte verfolgt werden
      unabhängig ist, wird eine "genehmigen/ablehnen" die Auflösung für eine übertragung.

    • Meisten Kommentare sind gut lokalisiert in der Datei, also möchte ich eine flow, ermöglicht die Befestigung
      Sie auf bestimmte stellen in der Datei, und Sie sollten halten Sie Ihren Platz, wenn die Datei
      bearbeitet.

    Den Recht fließen, denn dies wäre ein ticket zu eröffnen, für jeden Kommentar, schließen Sie mit commit-hooks, wenn angesprochen. Das problem ist nur, dass es keine einfache Möglichkeit, binden Sie ein ticket, um bestimmte Zeilen in der Datei, so dass es ziemlich umständlich. Ich bin versucht zu schreiben, ein minimalistisches plugin, mit Krawatten tickets Quelle/diff-Zeilen. Würde jemand anderes, wie ein solches Tier?

    Was werde ich wohl tun, in der Praxis ist setzen TODO-Kommentare im Quellcode selbst und nicht Lust auf Trac-Oberfläche an. Version control stellen Sie sicher, dass die Kommentare bleiben, wo Sie hingehören, zwischen bearbeitet.

    [Für LaTeX-spezifisch, ich werde wahrscheinlich mit dem todonotes und/oder fixme Pakete zum anzeigen der Kommentare nett, und vielleicht latexdiff für visual diffs.] Ich werde Bearbeiten Sie diese später zu berichten, wie es gelaufen ist...

    BTW, dieser Ansatz ist nicht beschränkt auf Dokumente, ich habe mit einem team, dass es eine Menge für die code-überprüfung während der intensiven agile Entwicklung und es funktionierte gut genug. Sie hatte einen ähnlichen Wunsch, "pipeline" der review-Prozess - Entwicklung muss weitergehen, aber alle änderungen müssen überprüft werden, bevor man eine Freigabe. Der schwierigste Teil war-tracking-was hat sich oder wurde noch nicht überprüft, was getan wurde, durch tagging "sauber" Revisionen und diff; im Nachhinein, dass ein "geprüft" - Zweig und cherry-picking in es würde besser funktionieren. (Natürlich, nicht-lokalisierten, architektonische Fragen gehen würde in Trac-tickets statt, oder würde beginnen als TODO-Kommentare und wäre gewandert in tickets, wenn Sie den Beweis nicht-trivial-Adresse.)

    InformationsquelleAutor der Antwort Beni Cherniavsky-Paskin

Schreibe einen Kommentar