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.
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. > On 4 Jul 2018, at 22:32, Darragh Bailey <[email protected]> wrote: > > 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 > > <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" > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
