Open Stack

Hi,


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.

Based on the comments at
https://git.openstack.org/cgit/openstack-infra/git-review/tree/CONTRIBUTING.rst#n5,
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.

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.

There are a couple of things that I would like to work towards:
* Change the tests to use a single gerrit with separate projects instead of
separate instances (faster testing)
* Allow the tests to run against multiple versions of Gerrit (ensure
compatibility)
* Fix and land many of the changes making it easier to download changes,
list changes ordered with their dependencies, stashing when downloading, etc
* 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)

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.

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.

* Have git-review provide the APIs so that someone may define a
git-review-<name> that can add their workflow
* Add support for additional behaviour to be defined with refs/meta/config
of projects
* Allow extensions to be installed that allow additional options to be
added to the git-review CLI and config file

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?

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.


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?


-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20180704/9c4f1e40/attachment-0001.html>