Thoughts on using Gerrit?

EmilienM commented 2 years ago

We are looking for a potential new home for Gophercloud (see this thread). It might or it might not involve changes in our tools used to maintain Gophercloud.

I basically want to know if moving to Gerrit would be a problem for our community of contributors. Please give your concerns, feedback, etc, it's an open forum.

Just a note: if you have no idea what moving to Gerrit would mean, please have a look at this document.

I would like to know:

if you're attached to the Github review system
if setting up an account for Gerrit would be a barrier of entry (note: you don't have to setup anything if you're already an OpenStack contributor).
if that would prevent you or anyone to contribute

Thanks for your feedback and we hope to make the right decisions based on the inputs we'll get.

jtopjian commented 2 years ago

There are definitely benefits to this change.

To confirm: would this change be for only contributing code or for both contributions and bug reports / feature requests?

EmilienM commented 2 years ago

There are definitely benefits to this change.

To confirm: would this change be for only contributing code or for both contributions and bug reports / feature requests?

Good question. Moving to opendev would potentially imply using Storyboard for bug tracking. Although technically speaking I'm not sure what would prevent us to keep using Github issues...

jtopjian commented 2 years ago

I think whichever solution, the barrier to reporting bugs or feature requests should be low or it might feel like too much effort to do. There's that saying that for every 1 report of something there is more than 1 person affected, just not reporting it.

dtantsur commented 2 years ago

GitHub's integration with Gerrit is probably worse than with Storyboard, but we in the Ironic team has been using Storyboard for a few years, and we're not impressed with it.

EmilienM commented 2 years ago

@kayrus @shhgs @nikParasyr @schirevko @dustymabe @lingxiankong @kristian-lesko @MysteriousWolf @andrewbaxter @majewsky @TonyZhang1989 @nikParasyr @cardoe @reenjii @abnvanand @eltociear @zaneb @iurygregory @psvmcc @bfournie @yylt @objque @pierreprinetti @toliu

Hi everyone,

You have contributed to Gophercloud this year (thank you!). I wanted to make sure that you saw this open issue, and that you had a chance to share your feedback. Your feedback is really really important, we are going to make decisions, but only when we'll have inputs from our community. Please have a look at https://github.com/gophercloud/gophercloud/issues/2257#issue-1044264913 and give your feedback here or in private if you prefer (emilien at redhat com).

I think we can summarize the whole proposal to:

Keep the project as is, on Github and keep using Openlab for CI
Move the project under OpenStack (opendev), which involves switching to Gerrit, and their Zuul instance - connecting with other OpenStack projects and focus on integration, community growth
Keep the project on Github, but rethink our tooling (for CI, reviews, bots, etc) - github actions? etc

Thanks! And we look forward to seeing you contributing again.

iurygregory commented 2 years ago

I'm +1 to using gerrit (but my vote might be a bit biased since I've been contributing to opendev for a while :sweat_smile: ) I will be happy with whatever the decision is :smiley:

nikParasyr commented 2 years ago

Hello :). Thank you for reaching out. My thoughts/opinion:

if you're attached to the GitHub review system

Not really. Although i do find it a bit more user-friendly.

if setting up an account for Gerrit would be a barrier of entry.

I have already one for a couple of minor contributions i made.

if that would prevent you or anyone to contribute

Personally it wouldn't prevent me. I do think though that it adds a barrier to entry for new users that don't have prior experience with opendev/gerrit etc. This includes code contributions, when setting a gerrit acc and understanding the workflow there can be a bit too much for a newcomer, especially for minor patches/contributions. It also includes creating an issue, checking open issues and PRs to see the status of various bugs/fixes which is much easier and better in github than in storyboard.

Although i have some concerns I can also see a lot of benefits so I'm not against it. Personally my biggest pain with gophercloud has been the stability of ci. If we expect improvements there by moving to gerrit and integrating with the various projects, i'd be more than happy to move :)

majewsky commented 2 years ago

I have contributed to OpenStack via Gerrit once a few years back, and the experience was god awful back then compared to the ease of GItHub PRs. I don't remember many details, but I recall having to fiddle with Launchpad logins and having to set up the git-review stuff. Have things improved since then?

pierreprinetti commented 2 years ago

@EmilienM I appreciate that you approach past and present contributors for their advice. Some people in your list have spent hundreds of hours on this project and they deserve a vote, certainly more so than I do.

My 2¢: I'm wondering who Gophercloud's prospect contributors might be.

If new OpenStack development efforts moved towards Go, then opendev folks might be interested in Gophercloud and they would appreciate using gerrit for it. If instead they stick with Python, then probably Gophercloud wouldn't be gaining new contributors by moving there, and we'd have to consider how many people we'd gain/lose by moving to gerrit. By staying on Github, I guess we're attracting OpenStack users (rather than contributors). I would assume that the bulk of the OpenStack consumers reflect the overall statistic and thus would for the most part work in Github.

EmilienM commented 2 years ago

I have contributed to OpenStack via Gerrit once a few years back, and the experience was god awful back then compared to the ease of GItHub PRs. I don't remember many details, but I recall having to fiddle with Launchpad logins and having to set up the git-review stuff. Have things improved since then?

You still need to login via Launchpad (it's just an SSO here), and yes using Gerrit implies using git-review. I understand you didn't have a good experience with it, could you please elaborate on one or two examples, (with details), so I can see if this was improved or if it's in the roadmap to be improved.

Thanks!

EmilienM commented 2 years ago

@pierreprinetti :

I appreciate that you approach past and present contributors for their advice. Some people in your list have spent hundreds of hours on this project and they deserve a vote, certainly more so than I do.

Everyone deserves to give feedback and each comment will be taken in consideration. Like I said multiple times, our goal is to move forward, not backward. To scale the project, not to kill it; etc.

My 2¢: I'm wondering who Gophercloud's prospect contributors might be.

If new OpenStack development efforts moved towards Go, then opendev folks might be interested in Gophercloud and they would appreciate using gerrit for it.

This won't happen, OpenStack projects (Nova, Neutron, Oslo, etc) are and will stay in Python as far as I know.

If instead they stick with Python, then probably Gophercloud wouldn't be gaining new contributors by moving there, and we'd have to consider how many people we'd gain/lose by moving to gerrit. By staying on Github, I guess we're attracting OpenStack users (rather than contributors). I would assume that the bulk of the OpenStack consumers reflect the overall statistic and thus would for the most part work in Github.

Although Python is the major language in OpenStack, it is not the only one. I was project lead for a project in Ruby/Puppet OpenStack, to tell you language doesn't matter to enter in opendev. However you're right, the community has more skills in Python, but a lot of people also contribute to other projects (e.g. k8s), and therefore have other skill sets that our project could use. Actually, there are a bunch of folks now working on k8s who were working in OpenStack before (and some do both).

I personally think that Gophercloud is right now "isolated". Cost of maintenance is fairly high:

CI is not stable (working on it btw) and isolated (no integration is possible with other open-source projects, especially the ones we care: OpenStack APIs).
Low amount of reviewers - this is a current single point of failure where we don't have much reviewers. With more visibility we could get more reviews.
Lot of manual process (docs, release management, etc) which could be automated (e.g. opendev infra has it all automated, at very large scale)

If we stay on Github, we'll have to take that cost in consideration and have no choice to get more people helping on these topics mentioned before ^^^^. If people think it's better, then they'll need to sign up to help on these tasks.

majewsky commented 2 years ago

could you please elaborate on one or two examples, (with details), so I can see if this was improved or if it's in the roadmap to be improved.

It was five years ago for me, so no, I don't have any more details to elaborate. As for specific questions, I would be interested in knowing if there is any way at all to bypass the requirement for the git-review tooling. I remember it being a quite idiosyncratic workflow compared to pull requests which are way more commonly understood. I would rather like if I could just push a branch somewhere and open a PR or such in Gerrit like I do in GitHub.

With more visibility we could get more reviews.

How would moving to opendev get more visibility? Usually the common argument for GitHub is that everyone already has a GitHub account, so everyone can jump into discussions and submit PRs right away.

EmilienM commented 2 years ago

You have valid concerns, here is my take:

could you please elaborate on one or two examples, (with details), so I can see if this was improved or if it's in the roadmap to be improved.

It was five years ago for me, so no, I don't have any more details to elaborate. As for specific questions, I would be interested in knowing if there is any way at all to bypass the requirement for the git-review tooling. I remember it being a quite idiosyncratic workflow compared to pull requests which are way more commonly understood.

I don't want to start a long list of feature comparison between Github and Gerrit. I worked with both. They have benefits & drawbacks. Some people hate one of them, some people hate both, some people don't care, some people love them all.

My personal take: dev tools will never be able to satisfy everyone, but if we make all the necessary to maintain a low entry level, document the process etc, I think this is an acceptable move.

I would rather like if I could just push a branch somewhere and open a PR or such in Gerrit like I do in GitHub.

You could still do it, but once your branch would be ready, you would submit your patch with "git review" instead of "git push".

With more visibility we could get more reviews.

How would moving to opendev get more visibility? Usually the common argument for GitHub is that everyone already has a GitHub account, so everyone can jump into discussions and submit PRs right away.

Because there are people in the opendev community who don't necessarily know about Gophercloud, but have to maintain stable APIs. Some of them expressed high interest into adding CI jobs into their projects (e.g. Ironic), so we would get visibility from their team as well and potentially grow our community. Also, there is a group called "OpenStack SDK", which maintain the Python SDK. We could joint our efforts and work together; I think this could be beneficial and if not, wouldn't hurt, since we will maintain our current governance (ie we'll merge code as before).

zaneb commented 2 years ago

I personally prefer Gerrit to GitHub, but I don't think GitHub is so bad that it would be worth the confusion of moving the project. (Also Storyboard is... not great.)

I would concentrate on improving CI, which can be done without moving to Gerrit - Zuul integrates fine with GitHub (in fact, Gophercloud is already using it).

EmilienM commented 2 years ago

I personally prefer Gerrit to GitHub, but I don't think GitHub is so bad that it would be worth the confusion of moving the project. (Also Storyboard is... not great.)

I would concentrate on improving CI, which can be done without moving to Gerrit - Zuul integrates fine with GitHub (in fact, Gophercloud is already using it).

++ on concentrating CI, we already started BTW.

Yes Zuul is fine here but keep in mind that:

We currently rely on Openlab zuul, which has a fork of zuul jobs: https://github.com/theopenlab/openlab-zuul-jobs/ - which differ from opendev, (and therefor lack of features) - I don't want to re-invent the wheel and feed the gap. I would rather move and use for free the opendev zuul.
If we move to Opendev, we can't keep PRs, see this thread: http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025663.html

dustymabe commented 2 years ago

I've made a single contribution so my vote doesn't count at all, though I will offer some perspective. The contribution I made was a quintessential "drive-by" contribution. I was using the library, identified a missing feature that was easy to add, and implemented it myself locally in my code. At that point my itch was scratched because it already worked for me, but I wanted to push it into the library for others to use. Because of the network effect of GitHub I was empowered to make the contribution conveniently. Because Gerrit is unfamiliar to me and I don't have an account with the target system already I probably wouldn't have pushed it up.

I hate arguing for a proprietary platform, but there's a lot of gravity there (here).

EDIT: Just want to point out the above argument also applies to reporting issues.

EmilienM commented 2 years ago

I've made a single contribution so my vote doesn't count at all, though I will offer some perspective. The contribution I made was a quintessential "drive-by" contribution. I was using the library, identified a missing feature that was easy to add, and implemented it myself locally in my code. At that point my itch was scratched because it already worked for me, but I wanted to push it into the library for others to use. Because of the network effect of GitHub I was empowered to make the contribution conveniently. Because Gerrit is unfamiliar to me and I don't have an account with the target system already I probably wouldn't have pushed it up.

Thanks for your feedback; this is the kind of one that I actually fear the most, because we really don't want to loose these kind of contributions. Hopefully we'll find a solution that works for everyone and helps us to scale the project.

[...]

s3rj1k commented 2 years ago

In case of migration I would suggest keeping a RO Github mirror at least, and verify that go.mod plays well with repo changes (probably it would require to use new import paths, this is not ideal).

pierreprinetti commented 2 years ago

I propose to focus on contributor appeal & retention, and to forget about the quality of the platforms themselves for a moment.

In my understanding, I see two groups of current contributors when it comes to Gerrit:

those of us who wouldn't be comfortable migrating to Gerrit
those of us who like Gerrit more, but as a matter of fact are well-versed in Github anyway.

Logically, we can only expect to lose current contributors by moving the project.

Speaking of perspective contributors: I don't expect to find more of them on any Gerrit instance than on Github. Even though the Go project started on Gerrit, the core team progressively made it easier to contribute from Github.

Reasonably, I don't expect the project to be able to gain more new contributors on a Gerrit instance, than on Github.

Based on these considerations only, and unless I missed some big factors, I would certainly vote for staying on Github.

SuperSandro2000 commented 2 years ago

I have used GitHub, GitLab and Gitea and everytime I need to research some change on either Gerrit or Launchpad I get totally lost and can't find what I am searching for. Also fetching a patch file from gerrit is a nightmare and requires you to base64 decode a file fetched from some undocumented endpoint.

dtantsur commented 2 years ago

requires you to base64 decode a file fetched from some undocumented endpoint.

I understand that gerrit is not the easiest tool to use (which IMO is justified given how superior it is in terms of features), but this particular statement is not accurate. The base64 patch is available from the "Download patch" menu. Its URL seems to be quite straightforward: https://review.opendev.org/changes/<PROJECT>~<REVIEW NUMBER>/revisions/<REVISION>/patch?download.

I'd also not call using curl <..> | base64 -d | patch -p1 nightmare, although our experience may differ here.

SuperSandro2000 commented 2 years ago

is justified given how superior it is in terms of features

It also seems to be missing a lot. I just wanted to browse a PR and the first link I found for gitweb ended up being a 404 after I needed to login and the second is only gitiles which is just better than nothing. Also from gitiles there seems to be no way to find PRs for the project which makes it hard to find patches for bugs which might be already fixed.

Then for gitiles in particular issues are on GItHub but contributions are through gerrit but the canonical source is on an gitiles instance. Then the CI is on gerrit and gerrit-forge and I couldn't find the declaration file for it. Given that GitHub can do all of this in one place, gerrit just looks like a big confusing mess to me with very little cross links which are very helpful for new contributors.

I'd also not call using curl <..> | base64 -d | patch -p1 nightmare, although our experience may differ here.

If you have a package system like nixpkgs which does not have native support for downloading base64 encoded patches because most other platforms offer them in plain text, you need to custom cook something which is annoying. Also I don't understand why a software with supposedly superior features does not offer something so simple as downloading a patch in plain text but two more complicated methods over plain http.

dtantsur commented 2 years ago

It also seems to be missing a lot. I just wanted to browse a PR and the first link I found for gitweb ended up being a 404

It's a bug of the deployment, I've reported it to opendev folks.

Note that just below that are the files you can browse and review (how do I do that in github without opening the whole diff, which may refuse to open because of its size?).

Given that GitHub can do all of this in one place, gerrit just looks like a big confusing mess to me with very little cross links which are very helpful for new contributors.

I don't necessarily disagree with gerrit being a mess, but so is github.

Per file diffs? None, you only have "Jump to" and only after opening the whole diff (which may take many seconds or fail completely).
Difference between revisions? Only if the PR does not use push -f, and even then good luck finding it (speaking of confusing UX).
Line comments are only possible for changed lines and a few lines around them. This is a pure and very annoying bug, I don't know how github folks are okay with it.
No way to block a review from merging, only closing it or marking as draft.

What I'm trying to say, advanced features come at price. Minimalistic UI and straightforward UX don't play well with tailoring to advanced users. And to be clear, I probably hate the gerrit UI more than you, but I can use it for my daily reviews, while github mostly stays in the way.

If you have a package system like nixpkgs which does not have native support for downloading base64 encoded patches

I don't think we should judge gerrit by its usability on platforms that don't have coreutils. I guess DOS is not supported well either ;)

why a software with supposedly superior features does not offer something so simple as downloading a patch in plain text

FWIW I don't understand it either. I guess nobody was annoyed enough by it to implement?

majewsky commented 2 years ago

I don't necessarily disagree with gerrit being a mess, but so is github.

That's the core issue here. I won't have the energy to deal with yet another mess, and I think that's the gripe of many other people here as well.

If you guys end up going to Gerrit, our team (@sapcc) will very likely end up taking the decentralized nature of Git to heart and just push into our own fork. If you end up pulling from us or not will be on you to decide then.

SuperSandro2000 commented 2 years ago

Note that just below that are the files you can browse and review (how do I do that in github without opening the whole diff, which may refuse to open because of its size?).

I can click on greetings and end up on the branch of the PR.

which may take many seconds or fail completely

Yeah, that is a problem on very big PRs.

Difference between revisions?

You can click on the force pushed words and get the diff between the two commits. Only if you are force pushing changes and a big rebase this does not help.

Line comments are only possible for changed lines and a few lines around them.

That is on their roadmap to change https://github.com/github/roadmap/issues/347 . I don't think this is a bug, more a very strict safe guard which ended up being more annoying.

No way to block a review from merging, only closing it or marking as draft.

I think you can play around with approving policies. I don't know if there is a setting to block merging when a change is requested but I have seen CIs which block if a change is requested.

while github mostly stays in the way.

If you are not already using it I would suggest to try out Refined GitHub which makes many things much better https://github.com/refined-github/refined-github

pierreprinetti commented 2 years ago

I am going to close this issue, as in my understanding we converged to consensus on Github for the time being.

Anyone wanting to revert the decision should feel very free to open a new issue for discussion.

gophercloud / gophercloud

Thoughts on using Gerrit? #2257