On Mon, 2024-02-26 at 15:52 +0000, Jeremy Stanley wrote:
On 2024-02-26 15:12:39 -0000 (-0000), thywyn@hotmail.com wrote: [...]
And since it was brought up... I am also a newb with commiting to opensource and the whole opendev/gerrit thing is certainly mouch more daunting compared to contributing to projects on Github as an example.
As one of the maintainers of our code review and hosting systems, I'm always interested in feedback like this, since we strive to make it as efficient and useful as possible to our projects. A little context around this would certainly help though.
When you say you are "a newb with commiting to opensource," do you mean you've also got zero experience with GitHub and are learning both at roughly the same time? Or is your observation that a platform you've not used yet is daunting compared to one you've already learned to use? Have you also used GitLab, Bitbucket, Pagure, Perforce, or any other non-GitHub code review workflows, and if so how many? What aspects, specifically, are daunting with respect to Gerrit? When there are things we can improve in that regard, we do try to contribute upstream to the Gerrit project in order to elevate the experience for our users.
We expect that learning to use new tools can seem daunting, and want to make that experience as smooth as possible, but everyone has to start somewhere and without learning new things there is little opportunity for growth. We generally prefer to choose the best possible tools for the task at hand, rather than choosing an inferior tool simply so that users won't be burdened with the need to learn. Far too often we get feedback along the lines of "Gerrit is inconvenient" when what the person really means is "learning to use something new is inconvenient," and that's not terribly helpful.
as an experienced person contibuting via github, gitlab and gerrit (i have also used perforce and svn but with no code review) i have mixed feeling about this topic. if you don't know how to use git at all then github can hide some fo that behind a ui (web or ide) or behind its CLI "gh" meaning you never really need to learn how git works beyond the superficial level. from my recent observations of non developers interfacing with gitlab and github for the frist time this tend ot newer user making 10s of broken commits. in the github pr flow this kind of becomes the maintainer problem to resolve either by editing the PR branch directly or couching the new user to fix the issues and then squash merging... squash merging losses all the context and defers leaning how to create up a series of changes into meaningful single commits. so as a new user to a version control system i personally think leaning the Github flow is actully harmful to your personal growth as a software engineer but if all you want to so is fix a typo in a doc, and never plan to do it again it makes it simple to do one off changes. as someone who has recently been forced to use github pull request for a different project i honestly could not see us using that for our daily development. the code review expericne as a maintainer and as a contributor while simpliced in some respect is more complex in other. its much harder for two people to work on a feature at the same time and its harder to review one commit/patch at a time. one question i woudl ask new users of git is do they mainly interact with code review systems to submit reviews via the cli, ide or ui? if they are used to a ui drivven approch have they look that the gerrit vs.code pugin? i dont use it much but i have used it ocationally. my experince with using github prs lately is unless is a single relivitly simple commit you need to either pull down the pr locally or use a vs.code exteion or similar to proeprly review a pr. if they are trying to use the cli are they aware of git-review? when i first started workign with gerrit and openstack i was not using git reveiw for about 2 years. once i learned i exited it made working with gerrit much simpler then doing "git push gerrit HEAD:ref/for/chagne/<number>" i am not sure it ^ is right but its something like that. "git review" is a lot simpler and closer to "gh pr create" i will say getting a gerrit acocunt and setting up ssh in our gerrit because of the launchpad/openid pre step was somewhat hader then signing up for a github account on day one. when we had new peopel join my team in the past getting gerrit setup to login, upload ssh keys and assert you have read and agree to the icla were always stumbling blocks for all involved. That was mainly because you have to to create a ubuntu.one/lauchpad account which is not obvious and which results in more clinking the creating a gmail or github account. i think supporting github or google account login would help new commers get up to speed with gerrit https://github.com/davido/gerrit-oauth-provider can enable that but we do not use that plugin in our instance. the documentaiton for creating a new account is also not very obvious when you first go to gerrit you need to know that it exists and google for it instead of having a simple register button beside the login button or a banner when your not logged in saying to create a new accoutn read this -> https://docs.openstack.org/contributors/en_GB/common/setup-gerrit.html the little bug icon we have in our gerrit beside signin directs you to https://docs.opendev.org/opendev/system-config/latest/project.html#contribut... which does not actully metion https://docs.openstack.org/contributors/en_GB/common/setup-gerrit.html so if your google foo fials you or soemone those not tell you ^ exists is not a good on boarding experince. im not sure if that is helpful but i can see why they would think its daunting compared to https://github.com/signup