<div dir="ltr"><div>Hi,</div><div><br></div><div><br></div><div>Firstly, thanks for git-review, it's such a useful tool, and I use it all the time working with Gerrit, from working on some openstack projects (including the odd patch to git-review), various projects in work and the very rare patch to Gerrit or it's plugins itself.<br></div><div><br></div><div>Based on the comments at <a href="https://git.openstack.org/cgit/openstack-infra/git-review/tree/CONTRIBUTING.rst#n5">https://git.openstack.org/cgit/openstack-infra/git-review/tree/CONTRIBUTING.rst#n5</a>, git-review is considered feature complete, and as a consequence it seems that reviewers have mostly moved onto other projects so it can take quite some time to get reviews. Perfectly understandable, everyone can only do so much and needs to pick something(s) to prioritise. However this is such a useful tool for working with Gerrit from the command line it seems to be the defacto git subcommand for interfacing with Gerrit that it seems a shame to limit it.<br></div><div><br></div><div>While I think there are a number of current reviews that would be beneficial to git-review, as well as some pieces that don't appear to be there currently, I'm reluctant to invest much time as it seems unlikely enhancements would be accepted due to the current state of feature complete. Instead of putting together various changes to see if they might be reviewed and accepted, hoping a chat about what paths might be available could save a bit of time.<br></div><div><br></div><div>There are a couple of things that I would like to work towards:</div><div>* Change the tests to use a single gerrit with separate projects instead of separate instances (faster testing)</div><div>* Allow the tests to run against multiple versions of Gerrit (ensure compatibility)</div><div>* Fix and land many of the changes making it easier to download changes, list changes ordered with their dependencies, stashing when downloading, etc</div><div>* Have git-review auto configure refs/notes/review (assuming it's available) for fetching on setup (I find it very handy and I'm always forgetting to do this)<br></div><div><br></div><div>And potentially controversially; support other workflows and options outside of the OpenStack workflow. Although maybe not directly, and still keeping the OpenStack one as the default.<br></div><div><br></div><div>I think there are a couple of ways that could be achieved, but I can't see any of them working well without a decent amount of refactoring.</div><div><br></div><div>* Have git-review provide the APIs so that someone may define a git-review-<name> that can add their workflow</div><div>* Add support for additional behaviour to be defined with refs/meta/config of projects</div><div>* Allow extensions to be installed that allow additional options to be added to the git-review CLI and config file</div><div><br></div><div>That last one might require being able to specify the additional required plugins to be listed in .gitreview, and providing the documentation might be trickier?<br></div><div><br></div><div>Basically make it easier to add custom behaviour without it being builtin to git-review, and without needing to reimplement a whole load of functionality elsewhere. But I'm pretty sure that all requires a substantial rewrite.<br></div><div><br></div><div><br></div><div></div><div>Thoughts? Is it worth putting a plan together around some of the initial changes? And then revisiting what would be needed to allow extensions around other workflows?</div><div><br></div><div><br>-- <br><div class="gmail_signature">Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool"</div>
</div></div>