<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Indeed, git-review is one of the tools I use the most and it is sad it didn't get more attention lately.... Clearly a project like this should not have open CRsr that are more than two years old that didn't get any feedback on them --- it sends a clear (bad) message to other potential contributors.<div class=""><br class=""></div><div class="">I am willing to spend a little bit of my time doing reviving work on the project, like we did with python-jenkins and jjb.</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 4 Jul 2018, at 22:32, Darragh Bailey <<a href="mailto:daragh.bailey@gmail.com" class="">daragh.bailey@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">Based on the comments at <a href="https://git.openstack.org/cgit/openstack-infra/git-review/tree/CONTRIBUTING.rst#n5" class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">There are a couple of things that I would like to work towards:</div><div class="">* Change the tests to use a single gerrit with separate projects instead of separate instances (faster testing)</div><div class="">* Allow the tests to run against multiple versions of Gerrit (ensure compatibility)</div><div class="">* 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 class="">* 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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">* Have git-review provide the APIs so that someone may define a git-review-<name> that can add their workflow</div><div class="">* Add support for additional behaviour to be defined with refs/meta/config of projects</div><div class="">* Allow extensions to be installed that allow additional options to be added to the git-review CLI and config file</div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class="">-- <br class=""><div class="gmail_signature">Darragh Bailey<br class="">"Nothing is foolproof to a sufficiently talented fool"</div>
</div></div>
_______________________________________________<br class="">OpenStack-Infra mailing list<br class=""><a href="mailto:OpenStack-Infra@lists.openstack.org" class="">OpenStack-Infra@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra</div></blockquote></div><br class=""></div></body></html>