-
Task
-
Resolution: Unresolved
-
Low
-
None
At the moment we use the tracker for code review, along with diff urls etc.
I have long thought this is suboptimal:
- It's noisy for non-developers
- It doesn't handle evolving patchsets well if looking back at the history (e.g. example cibot comments)
- Commenting on specific lines of code is akward - it would feel a lot more natural to comment on specific lines as you go along looking at the code.
- We reimplement a lot of 'integration checks' using the tracker when a code review tool has natural support for this stuff
That said, i've thought about alternatives in the past, but they've always had issues which are significant downsides. I am creating this issue to record them for future discussion.
With most of the existing tools, my thoughts has always been:
- That they take over the entire merging process - and its not clear how it would work with lib/db/upgrade.php or other constant conflicting files which we generally get conflicts most weeks.
- How we would fit into the existing tracker workflow. Making the tracker the primary source works well for us.
- Some of the tools require new tools to be learnt which is a barrier. (github is a counter example to that, where most people now expect github pull requests to work, so it would probably be better)
Anyway here is the issue for discussion as the landscape changes over the years.
An interesting bit of invetigation from wikimedia which we can draw on http://www.mediawiki.org/wiki/Git/Gerrit_evaluation#Where_we_stand
- has a non-specific relationship to
-
MDLSITE-3684 Dealing with open pull requests on github
-
- Open
-