-
Notifications
You must be signed in to change notification settings - Fork 0
Infrastructure_Projects
Note: This is ported without modification from the old wiki. It may not be completely current.
There is some preference within the group for sending patches to the mailing list, as well as performing reviews there. However, this method has proven difficult to keep track of, with the result being dropped/stale patches as well as a general lack of ability to quickly get an overview of where we stand wrt ‘patches on the list’ and what tickets/issues those patches relate to. Existing Code Review Management Systems:
- Patchwork
- Gerrit
Requirements for our needs (may or may not be met by above) - AKA ‘The Dream’:
-
A system that enables easier tracking of where patches are in the review process, as well as facilitating the review process itself, without getting in the way of those who prefer to work strictly on the list, and providing the same digital trail of the review for those unable or unwilling to use the tools. In other words, it should wrap around/enhance our current process so people who do not like the current process can ‘opt in’ without imposing any undue burden on those who are happy with things as they currently are.
-
Web (or other) view of patches for the project. This should include a status showing whether patch is under review, pushed, etc, and who the reviewer is
-
Ability to flag a patch (important, critical, etc), perhaps with some requested ‘review-by’ date.
-
Ability to request that a specific person (or someone from a list of people) review your patch.
-
Ability to connect a patch (set) to a ticket in redmine and bugzilla (wherever it actually lives)
-
Commenting/review system that allows you to make general comments, or attach a comment directly to a line/section of code.
-
Pull/push review updates to list, couple scenarios:
- If a patch is sent to list, the system should pick that up and pull it in so anyone looking at the list through the system will see this patch (maybe this is even the primary way to pull a patch in).
- If a review is sent to the list, this review should be imported to the system for viewing. Ideally this will be the same view as if the review were actually done in the system (attach comment to correct line number of patch), but if that is too complex or error prone, may require a simpler fall-back
- If a review is performed in the system, that review should be output in email format and sent to the list, so it looks similar to if the review went straight to the list.
-
Hooks into git, so if a patch is pushed, the entry in the system is updated and an email is sent to the list (threaded to the patch) saying this.