Re: Why are some organizations moving away from Gerrit?

591 views
Skip to first unread message

Kenny Ho

unread,
Jan 11, 2021, 1:43:14 PM1/11/21
to Repo and Gerrit Discussion
Hi sorry to chime in so late with my two cents.  I just caught up with the virtual summit topics over the holiday.

As a user and ex-admin of Gerrit, I think Gerrit is great and the workflow is first class.  Unfortunately, a professional and efficient workflow for experienced developers is a second step of a developer journey.  What Gerrit misses is the on-ramp to this second step and I think this is what is hurting adoption.

While we might not want to compete with GitHub by emulating and following their feature set, we are competing in the sense of developer mindshare, workflow and git hosting best practices.  GitHub, GitLabs and others have a lot of features so perhaps listing them out can help us articulate how we may be able to compete (i.e. what to keep, what to add, what to change, and perhaps what to remove.)

## Workflow
This is the best part of Gerrit so obviously it is a keeper.  What's missing here, I think, is documentation and developer advocacy/marketing.  We have a lot of documentation but we are missing something concise that matches the current state of the ecosystem (since a lot of the documentations are iterative improvement from the days before GitHub became popular.)

I propose we have something called "GerritFlow" to encapsulate the values of our workflow (every commit must stand on its own, leverage git protocol to the fullest extent, ability to amend patch series while keeping a live history and so on.)  The exact name can be something else (since I am not a native English speaker and not great at naming things, GerritFlow is just something I borrowed from GitFlow,) but the key point here is to have a term that everyone can referr to easily so that it can become as popularly known as GitFlow.  Having this concisely described will go a long way in answering a lot of the why (like why is there a Change-ID or why refs/for.)

By formalizing a "GerritFlow", we can also add some formal names to various pieces of our workflow.  For example, when we push to refs/for/<branch>, what are we creating?  I have heard of Change or ChangeList, or Patchset but I am not sure if that is official (and perhaps Change is too generic and ChangeList is too Perforce-like.)  Also, what is the name of the act of pushing to refs/for and what is the name of the destination.  I want to be able to explain to new users consciously with something like: 'when you push to refs/for, you are creating a Pull Request(?) by pushing to the Staging Area(?) of the server.'

This doesn't have to be technically precise but it should help create a conceptual image in users' mind.  A term/noun is needed so that we can relate this step to something the user may already know (GitHub's Pull Request.)

To further clarify our workflow and leverage GitHub's popularity and knowledge, perhaps we can have multiple side-by-side sequence diagrams comparing GerritFlow with Pull Request added to the walkthrough.  The current GitHub walk through has a lot of 'what' but doesn't have a big picture to explain the 'why'.  Perhaps we can even frame this as graduation from GitHub to more advanced git usage with Gerrit.


## Wiki/CI/Bug Tracker/Analytics
Other products/projects have these features but with consideration to resource limits and project focus, I think it's reasonable for these to be out of scope.  From competition perspective, the answer (as others have mentioned) should be the Gerrit plugin ecosystem and having OpenAPI/Swagger type mechanism to Gerrit API to make integration with Gerrit easier.  Make things easier for folks like Zuul.


## Repository home page, browsing and Code search
Some may argue that code search and repository browsing like Gitiles should be out of scope but I disagree.  A repository view is the missing on-ramp that I was referring to earlier.  It is the key missing piece for an open source project to simply use Gerrit for its git hosting.  The repository view/home page is the 'storefront' for the project and where the project gets search engine hit and exposure.  Each repository already has some kind of home page in Gerrit (like this https://gerrit-review.googlesource.com/admin/repos/Core-Plugins) but it's not first class the way GitHub treats a project/repository.  If done right, the repository view can be a good place for customization and integration as well.  Instead of having some fixed widgets like contributor stats, releases, language stats the way GitHub has it, external systems like CI or bug tracker can have widgets with live status there (like those CI/code scan badges maintainers place in the README but more advanced and elaborate.)  Even if we don't have the resource to invest in code search, I think having a first class repository home page is still a good idea.

Another possibly missing 'home page' is the concept of a collection of repositories (the way GitHub treats organization.)  Perhaps git submodule can have some special UI treatment but I haven't quite thought this one through yet.

## Final thoughts
Looking at the notes, Ben R asked, "Gerrit is a specialized tool. If we are all product managers, where do we want to go?"  Git started with the ideal of being distributed, but looking at the current trend in git hosting, natural forces (like toolings, admin overhead, resource constraints, ease of use, etc.) seem to be pushing things back to a more centralized model.  Perhaps a good mission for Gerrit to have is to help keep git distributed by building tools on top of git.  (NodeDB being one of the prime examples.)

Anyway, these are my two cents.  What do you think?

Luca Milanesio

unread,
Jan 11, 2021, 2:04:13 PM1/11/21
to Kenny Ho, Luca Milanesio, Repo and Gerrit Discussion

On 11 Jan 2021, at 18:43, Kenny Ho <y2k...@gmail.com> wrote:

Hi sorry to chime in so late with my two cents.  I just caught up with the virtual summit topics over the holiday.

As a user and ex-admin of Gerrit, I think Gerrit is great and the workflow is first class.  Unfortunately, a professional and efficient workflow for experienced developers is a second step of a developer journey.  What Gerrit misses is the on-ramp to this second step and I think this is what is hurting adoption.

Hi Kenny,
Thanks for sharing this.

In your own experience, what was the most important of the three factors below that drove you (or your company) to move away from Gerrit Code Review?
What was the system that was adopted as a replacement of Gerrit Code Review?

See below my feedback on your points.


While we might not want to compete with GitHub by emulating and following their feature set, we are competing in the sense of developer mindshare, workflow and git hosting best practices.  GitHub, GitLabs and others have a lot of features so perhaps listing them out can help us articulate how we may be able to compete (i.e. what to keep, what to add, what to change, and perhaps what to remove.)

## Workflow
This is the best part of Gerrit so obviously it is a keeper.  What's missing here, I think, is documentation and developer advocacy/marketing.  We have a lot of documentation but we are missing something concise that matches the current state of the ecosystem (since a lot of the documentations are iterative improvement from the days before GitHub became popular.)

I propose we have something called "GerritFlow" to encapsulate the values of our workflow (every commit must stand on its own, leverage git protocol to the fullest extent, ability to amend patch series while keeping a live history and so on.)  The exact name can be something else (since I am not a native English speaker and not great at naming things, GerritFlow is just something I borrowed from GitFlow,) but the key point here is to have a term that everyone can referr to easily so that it can become as popularly known as GitFlow.  Having this concisely described will go a long way in answering a lot of the why (like why is there a Change-ID or why refs/for.)

By formalizing a "GerritFlow", we can also add some formal names to various pieces of our workflow.  For example, when we push to refs/for/<branch>, what are we creating?  I have heard of Change or ChangeList, or Patchset but I am not sure if that is official (and perhaps Change is too generic and ChangeList is too Perforce-like.)  Also, what is the name of the act of pushing to refs/for and what is the name of the destination.  I want to be able to explain to new users consciously with something like: 'when you push to refs/for, you are creating a Pull Request(?) by pushing to the Staging Area(?) of the server.'

This doesn't have to be technically precise but it should help create a conceptual image in users' mind.  A term/noun is needed so that we can relate this step to something the user may already know (GitHub's Pull Request.)

To further clarify our workflow and leverage GitHub's popularity and knowledge, perhaps we can have multiple side-by-side sequence diagrams comparing GerritFlow with Pull Request added to the walkthrough.  The current GitHub walk through has a lot of 'what' but doesn't have a big picture to explain the 'why'.  Perhaps we can even frame this as graduation from GitHub to more advanced git usage with Gerrit.

I believe there are already tools for automating the Gerrit workflow, like ‘git-review’ [1].
I do agree that we do not officially “advertise” it on the Gerrit Code Review homepage though, even if we mentioned it here and there: possibly we should in the future.

There is a second argument that Gerrit workflow requires *advanced* git knowledge: the ‘git-review’ is quite handy because avoids you being exposed to that complexity.



## Wiki/CI/Bug Tracker/Analytics
Other products/projects have these features but with consideration to resource limits and project focus, I think it's reasonable for these to be out of scope.  From competition perspective, the answer (as others have mentioned) should be the Gerrit plugin ecosystem and having OpenAPI/Swagger type mechanism to Gerrit API to make integration with Gerrit easier.  Make things easier for folks like Zuul.

Gerrit has an advanced analytics tool, a lot more functional and sophisticated than GitHub or GitLab [2].
With regards to BugTracker or CI, those are points that we decided NOT to address inside Gerrit but rather integrate with existing tools. Of course, tools like GitLab and GitHub, took another approach and proposed themselves as *uber-tool* for the whole CI/CD lifecycle.

Last but not least, the OpenAPI / Swagger interface has been proposed [3], but we decided to move to Protos instead.
From Protos you will still be able to generate client stubs for many popular languages and will be able to use a protobuf-binary protocol for API calls.



## Repository home page, browsing and Code search
Some may argue that code search and repository browsing like Gitiles should be out of scope but I disagree.  A repository view is the missing on-ramp that I was referring to earlier.  It is the key missing piece for an open source project to simply use Gerrit for its git hosting.  The repository view/home page is the 'storefront' for the project and where the project gets search engine hit and exposure.  Each repository already has some kind of home page in Gerrit (like this https://gerrit-review.googlesource.com/admin/repos/Core-Plugins) but it's not first class the way GitHub treats a project/repository.  If done right, the repository view can be a good place for customization and integration as well.  Instead of having some fixed widgets like contributor stats, releases, language stats the way GitHub has it, external systems like CI or bug tracker can have widgets with live status there (like those CI/code scan badges maintainers place in the README but more advanced and elaborate.)  Even if we don't have the resource to invest in code search, I think having a first class repository home page is still a good idea.

Another possibly missing 'home page' is the concept of a collection of repositories (the way GitHub treats organization.)  Perhaps git submodule can have some special UI treatment but I haven't quite thought this one through yet.

Oh yes, I 100% agree with you: we are definitely missing it.
For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.


## Final thoughts
Looking at the notes, Ben R asked, "Gerrit is a specialized tool. If we are all product managers, where do we want to go?"  Git started with the ideal of being distributed, but looking at the current trend in git hosting, natural forces (like toolings, admin overhead, resource constraints, ease of use, etc.) seem to be pushing things back to a more centralized model.  Perhaps a good mission for Gerrit to have is to help keep git distributed by building tools on top of git.  (NodeDB being one of the prime examples.)

Anyway, these are my two cents.  What do you think?

My personal view is that Gerrit needs to be more *seamlessly* integrated with all the other tools that currently exist in the cloud.
I have defined our goal at GerritForge (one of the main supporters of Gerrit Code Review) as making Gerrit more cloud-native in 2021 [5].

The cloud has *lots* of existing plug&play resources for doing CI/CD: forcing Gerrit to cover the whole DevOps lifecycle won’t be neither fair nor desirable.
*Plugging* Gerrit into an existing set of tools on the cloud, *IS* the way to go, rather than replacing everything else.

I agree 100% with you that we do need to “focussed tutorials” on how to use Gerrit with other tools, simply and for new-starters of the Gerrit workflow.

Thanks again for sharing your view.
Luca.


References:




--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/3c89a5d9-3c37-423e-8ec0-59b7c52bca7bn%40googlegroups.com.

Han-Wen Nienhuys

unread,
Jan 11, 2021, 2:12:02 PM1/11/21
to Luca Milanesio, Kenny Ho, Repo and Gerrit Discussion
On Mon, Jan 11, 2021 at 8:04 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
> For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.

I never got round to implementing Gerrit ACLs, so zoekt "integrated
with Gerrit security" isn't true. :-(

--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Luca Milanesio

unread,
Jan 11, 2021, 3:50:11 PM1/11/21
to Han-Wen Nienhuys, Luca Milanesio, Kenny Ho, Repo and Gerrit Discussion

On 11 Jan 2021, at 19:11, Han-Wen Nienhuys <han...@google.com> wrote:

On Mon, Jan 11, 2021 at 8:04 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.

I never got round to implementing Gerrit ACLs, so zoekt "integrated
with Gerrit security" isn't true. :-(

Didn’t you demo the feature 3 years ago [1] at the Gerrit User Summit in London?

Kenny Ho

unread,
Jan 11, 2021, 4:08:01 PM1/11/21
to Repo and Gerrit Discussion


On Monday, January 11, 2021 at 2:04:13 PM UTC-5 lucamilanesio wrote:
On 11 Jan 2021, at 18:43, Kenny Ho wrote:

In your own experience, what was the most important of the three factors below that drove you (or your company) to move away from Gerrit Code Review?
What was the system that was adopted as a replacement of Gerrit Code Review?

The top one is not having to maintain multiple git host.  We have Gerrit first but now folks are bringing in GitHub by user request.  We are running both currently but it's not hard to see that management will eventually pressure folks to streamline the services.  GitHub will likely win due to perceived reliability of their 'enterprise' support.
 

## Workflow

I believe there are already tools for automating the Gerrit workflow, like ‘git-review’ [1].
I do agree that we do not officially “advertise” it on the Gerrit Code Review homepage though, even if we mentioned it here and there: possibly we should in the future.

There is a second argument that Gerrit workflow requires *advanced* git knowledge: the ‘git-review’ is quite handy because avoids you being exposed to that complexity.


Yes I am aware of git-review, but my point is actually not so much about the nominal / mechanical complexity.  I actually don't use git-review since I find using ctrl-r in bash history sufficiently simple.  In addition, some may actually use git-review to argue against Gerrit because they will claim that you don't need add-on to interact with GitHub (even though that argument is kind of comparing apples and oranges.)

Git-review may reduce the number of key stroke one need to type, but I think people still want to have some conceptual understanding of what they are doing.  For example,  with GitHub, it has the concept of forking repo and then have commits pull from one repo to another.  These are tangible concepts that user understand even though it may not be technically what happens in the background (as far as I can tell, the forked repo behave almost like a branch.)

GitHub's fork-pull-request has complexity.  What I was trying to say is that their success is not so much hiding the complexity but giving names to it so that it can be taught and communicated.
 
## Repository home page, browsing and Code search
Oh yes, I 100% agree with you: we are definitely missing it.
For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.

Yes, I am aware of Zoekt.  I was very excited to see it when I was in London.  Last I chat with Han-Wen I think it is what Sourcegraph is based on?  The repository/project home page is really a big deal though if people want to use Gerrit as a one stop shop for project hosting (even if things like wiki, bug tracker, code search, CI is not integrated out of the box.)  In many ways, I am actually happy to not have CI and bug tracker integrated as long as plugging other projects to Gerrit is sufficiently easy.

## Final thoughts
My personal view is that Gerrit needs to be more *seamlessly* integrated with all the other tools that currently exist in the cloud.
I have defined our goal at GerritForge (one of the main supporters of Gerrit Code Review) as making Gerrit more cloud-native in 2021 [5].

The cloud has *lots* of existing plug&play resources for doing CI/CD: forcing Gerrit to cover the whole DevOps lifecycle won’t be neither fair nor desirable.
*Plugging* Gerrit into an existing set of tools on the cloud, *IS* the way to go, rather than replacing everything else.

Yup, I agree with this, although I am less cloud-oriented since a lot of my work have to be done in baremetal/ in private network.  I am loving Zuul so far so there's no need for Gerrit to have build in CI.

Regards,
Kenny

Luca Milanesio

unread,
Jan 11, 2021, 4:14:12 PM1/11/21
to Kenny Ho, Luca Milanesio, Repo and Gerrit Discussion

On 11 Jan 2021, at 21:08, Kenny Ho <y2k...@gmail.com> wrote:



On Monday, January 11, 2021 at 2:04:13 PM UTC-5 lucamilanesio wrote:
On 11 Jan 2021, at 18:43, Kenny Ho wrote:

In your own experience, what was the most important of the three factors below that drove you (or your company) to move away from Gerrit Code Review?
What was the system that was adopted as a replacement of Gerrit Code Review?

The top one is not having to maintain multiple git host.  We have Gerrit first but now folks are bringing in GitHub by user request.  We are running both currently but it's not hard to see that management will eventually pressure folks to streamline the services.  GitHub will likely win due to perceived reliability of their 'enterprise' support.

The offering of Gerrit Enterprise Support has been in place for years, but not very well known in the community.

I’ve just merged a couple of days ago a change on the Gerrit Code Review Support page to mention that possibility:

HTH

Luca.

 

## Workflow

I believe there are already tools for automating the Gerrit workflow, like ‘git-review’ [1].
I do agree that we do not officially “advertise” it on the Gerrit Code Review homepage though, even if we mentioned it here and there: possibly we should in the future.

There is a second argument that Gerrit workflow requires *advanced* git knowledge: the ‘git-review’ is quite handy because avoids you being exposed to that complexity.


Yes I am aware of git-review, but my point is actually not so much about the nominal / mechanical complexity.  I actually don't use git-review since I find using ctrl-r in bash history sufficiently simple.  In addition, some may actually use git-review to argue against Gerrit because they will claim that you don't need add-on to interact with GitHub (even though that argument is kind of comparing apples and oranges.)

Git-review may reduce the number of key stroke one need to type, but I think people still want to have some conceptual understanding of what they are doing.  For example,  with GitHub, it has the concept of forking repo and then have commits pull from one repo to another.  These are tangible concepts that user understand even though it may not be technically what happens in the background (as far as I can tell, the forked repo behave almost like a branch.)

GitHub's fork-pull-request has complexity.  What I was trying to say is that their success is not so much hiding the complexity but giving names to it so that it can be taught and communicated.
 
## Repository home page, browsing and Code search
Oh yes, I 100% agree with you: we are definitely missing it.
For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.

Yes, I am aware of Zoekt.  I was very excited to see it when I was in London.  Last I chat with Han-Wen I think it is what Sourcegraph is based on?  The repository/project home page is really a big deal though if people want to use Gerrit as a one stop shop for project hosting (even if things like wiki, bug tracker, code search, CI is not integrated out of the box.)  In many ways, I am actually happy to not have CI and bug tracker integrated as long as plugging other projects to Gerrit is sufficiently easy.

## Final thoughts
My personal view is that Gerrit needs to be more *seamlessly* integrated with all the other tools that currently exist in the cloud.
I have defined our goal at GerritForge (one of the main supporters of Gerrit Code Review) as making Gerrit more cloud-native in 2021 [5].

The cloud has *lots* of existing plug&play resources for doing CI/CD: forcing Gerrit to cover the whole DevOps lifecycle won’t be neither fair nor desirable.
*Plugging* Gerrit into an existing set of tools on the cloud, *IS* the way to go, rather than replacing everything else.

Yup, I agree with this, although I am less cloud-oriented since a lot of my work have to be done in baremetal/ in private network.  I am loving Zuul so far so there's no need for Gerrit to have build in CI.

Regards,
Kenny



Thanks again for sharing your view.
Luca.


--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Karl

unread,
Jan 12, 2021, 12:16:39 AM1/12/21
to Repo and Gerrit Discussion
I agree with Kenny's opinion but I would like to share some comments by my admin/user experience. 

So far we are running Gerrit, GitLab and the others in our company. 

# Required knowledge for admins and operators
Gerrit requires advanced knowledge of git in many scenes. Creating repos, configuring privileges and adding members...
It is my headache, because typical admin/operator role persons don't have enough knowledge of git and the learning curve for that is high. And also, skilled persons need high salary :-P
With GitHub Enterprise and GitLab Enterprise and BitBucket, most operations will be done in a web browser. The learning curve for them is much lower than Gerrit. 

# Workflow, repo browsing and code search
In our case, some users choose Gerrit because of its brilliant review/workflow system especially in projects for high regulated industry. However, they complain the functionalities for repo browsing and code search so we have to set-up FishEye or similar tools for Gerrit projects.
In these days, GHE and GLE have review/approval systems that satisfies most (not regulated) project needs. And also, they have repo browsing and code search in one place. 

2021年1月12日火曜日 3:43:14 UTC+9 y2k...@gmail.com:

Kenny Ho

unread,
Jan 12, 2021, 12:40:59 AM1/12/21
to Karl, Repo and Gerrit Discussion
Thanks for adding your experience Karl.  If you don't mind letting us know, which version of Gerrit are you using?  In my experience, I mostly use the web browser to configure the repository access control permissions and I usually delegate the responsibility to the relevant team leads.  We also use AD/LDAP distribution list to automate some of the settings.  Were you referring to the gerrit.config when you mentioned the learning curve?

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to a topic in the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/repo-discuss/Zugbe7bmEpU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/c23c6d5b-e5ed-4f9f-bdbb-3a963623a252n%40googlegroups.com.

Karl

unread,
Jan 12, 2021, 2:12:56 AM1/12/21
to Repo and Gerrit Discussion
Currently we are using Gerrit ver.3.2.5.1 with Atlassian Crowd as an OpenID auth provider. 

> Were you referring to the gerrit.config when you mentioned the learning curve?
No, I mean the leaning curve for:
- Gerrit has "inherits" feature in privileges. However, it's very difficult to understand exact privileges in a complex instance with Gerrit UI. 
- Gerrit stores some sort of configuration data in All-Users.git (user related) and All-Projects.git (project related). 

Because of this, a bit deep git knowledge will be needed. 
e.g.) To edit user information on behalf of target user(s).
e.g.) To troubleshoot and fix "external ID already in use" issue. 

2021年1月12日火曜日 14:40:59 UTC+9 y2k...@gmail.com:

Luca Milanesio

unread,
Jan 12, 2021, 2:53:26 AM1/12/21
to Karl, Luca Milanesio, Repo and Gerrit Discussion

On 12 Jan 2021, at 07:12, Karl <karukomi...@jp.panasonic.com> wrote:

Currently we are using Gerrit ver.3.2.5.1 with Atlassian Crowd as an OpenID auth provider. 

> Were you referring to the gerrit.config when you mentioned the learning curve?
No, I mean the leaning curve for:
- Gerrit has "inherits" feature in privileges. However, it's very difficult to understand exact privileges in a complex instance with Gerrit UI. 
- Gerrit stores some sort of configuration data in All-Users.git (user related) and All-Projects.git (project related). 

Because of this, a bit deep git knowledge will be needed. 
e.g.) To edit user information on behalf of target user(s).
e.g.) To troubleshoot and fix "external ID already in use" issue. 

Hi Karl,
Thanks for sharing your experience.

As you are managing both Gerrit and GitLab, how do you manage the project permission inheritance in GitLab from the Web browser?
Is there also an easy way to edit the user information and preferences by the administrator on behalf of the users?

It would be very useful to have your experience as a Gerrit admin to understand how to smooth the rough edges.

Thanks in advance for your feedback.
Luca.

You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/06867a0e-64a2-4ec1-a6a0-245015dec1a5n%40googlegroups.com.

Karukomi Kensuke (軽込 健介)

unread,
Jan 12, 2021, 5:50:23 AM1/12/21
to Luca Milanesio, Repo and Gerrit Discussion

> As you are managing both Gerrit and GitLab, how do you manage the project permission inheritance in GitLab from the Web browser?

 

 

> Is there also an easy way to edit the user information and preferences by the administrator on behalf of the users?

 

GitLab has user maintenance page in the web UI, so it's obviously easier than Gerrit.

Please see also the attached files.

 

Please note that GitLab supported features may vary depending on the edition.

There are 4 editions including OSS (Core).

https://about.gitlab.com/pricing/self-managed/feature-comparison/

gitlab-core_admin-user-list.png
gitlab-core_admin-user-detail.png
gitlab-core_admin-nested-group.png

Han-Wen Nienhuys

unread,
Jan 12, 2021, 5:53:35 AM1/12/21
to Luca Milanesio, Kenny Ho, Repo and Gerrit Discussion
On Mon, Jan 11, 2021 at 9:50 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
>
>
>
> On 11 Jan 2021, at 19:11, Han-Wen Nienhuys <han...@google.com> wrote:
>
> On Mon, Jan 11, 2021 at 8:04 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
>
> For code-search, have you looked at Zoekt? [4] It is super-powerful and integrated with Gerrit security.
>
>
> I never got round to implementing Gerrit ACLs, so zoekt "integrated
> with Gerrit security" isn't true. :-(
>
>
> Didn’t you demo the feature 3 years ago [1] at the Gerrit User Summit in London?

It was a prototype, and I never productionized it. I have some
alternate ideas on how to implement it better, but sadly lack the time
to look into them.

Kenny Ho

unread,
Jan 12, 2021, 12:26:09 PM1/12/21
to Karukomi Kensuke (軽込 健介), Luca Milanesio, Repo and Gerrit Discussion
Ah ok.  Thanks for highlighting this.  I have gotten so used to the Gerrit's access control that I have forgotten how complicated it is.  This is definitely one of those advanced area that can take some UX improvement and marketing promotion since it is one of Gerrit's power (but seldom talked about since it's not very user facing.)

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/OSAPR01MB397066FF064DBA11017FFD07ACAA0%40OSAPR01MB3970.jpnprd01.prod.outlook.com.

Saša Živkov

unread,
Jan 14, 2021, 8:25:46 AM1/14/21
to Kenny Ho, Repo and Gerrit Discussion

Hi Kenny


On Mon, Jan 11, 2021 at 7:43 PM Kenny Ho <y2k...@gmail.com> wrote:
Hi sorry to chime in so late with my two cents.  I just caught up with the virtual summit topics over the holiday.

As a user and ex-admin of Gerrit, I think Gerrit is great and the workflow is first class.  Unfortunately, a professional and efficient workflow for experienced developers is a second step of a developer journey.  What Gerrit misses is the on-ramp to this second step and I think this is what is hurting adoption.

Very well summarized, I agree on this fully. Very well summarized! I also in general agree with most of what you wrote below.

However, I believe that you are talking about a slightly different topic here: "the adoption of Gerrit by the first-time users".
The main topic here is why long-term Gerrit users are moving away from Gerrit. Most of them are already aware of all of the advantages of the "GerritFlow".
Trying to relate what you wrote here to the topic of long-term Gerrit users moving away, I believe that your point is that (continued) Gerrit adoption
also depends on constantly getting new Gerrit users within the organizations where Gerrit is already established.
 

While we might not want to compete with GitHub by emulating and following their feature set, we are competing in the sense of developer mindshare, workflow and git hosting best practices.  GitHub, GitLabs and others have a lot of features so perhaps listing them out can help us articulate how we may be able to compete (i.e. what to keep, what to add, what to change, and perhaps what to remove.)

## Workflow
This is the best part of Gerrit so obviously it is a keeper.  What's missing here, I think, is documentation and developer advocacy/marketing.  We have a lot of documentation but we are missing something concise that matches the current state of the ecosystem (since a lot of the documentations are iterative improvement from the days before GitHub became popular.)

I propose we have something called "GerritFlow" to encapsulate the values of our workflow (every commit must stand on its own, leverage git protocol to the fullest extent, ability to amend patch series while keeping a live history and so on.)  The exact name can be something else (since I am not a native English speaker and not great at naming things, GerritFlow is just something I borrowed from GitFlow,) but the key point here is to have a term that everyone can referr to easily so that it can become as popularly known as GitFlow.  Having this concisely described will go a long way in answering a lot of the why (like why is there a Change-ID or why refs/for.)

By formalizing a "GerritFlow", we can also add some formal names to various pieces of our workflow.  For example, when we push to refs/for/<branch>, what are we creating?  I have heard of Change or ChangeList, or Patchset but I am not sure if that is official (and perhaps Change is too generic and ChangeList is too Perforce-like.)  Also, what is the name of the act of pushing to refs/for and what is the name of the destination.  I want to be able to explain to new users consciously with something like: 'when you push to refs/for, you are creating a Pull Request(?) by pushing to the Staging Area(?) of the server.'

+1 for a well named formalized "GerritFlow".
 
This doesn't have to be technically precise but it should help create a conceptual image in users' mind.  A term/noun is needed so that we can relate this step to something the user may already know (GitHub's Pull Request.)

To further clarify our workflow and leverage GitHub's popularity and knowledge, perhaps we can have multiple side-by-side sequence diagrams comparing GerritFlow with Pull Request added to the walkthrough.  The current GitHub walk through has a lot of 'what' but doesn't have a big picture to explain the 'why'.  Perhaps we can even frame this as graduation from GitHub to more advanced git usage with Gerrit.


## Wiki/CI/Bug Tracker/Analytics
Other products/projects have these features but with consideration to resource limits and project focus, I think it's reasonable for these to be out of scope.  From competition perspective, the answer (as others have mentioned) should be the Gerrit plugin ecosystem and having OpenAPI/Swagger type mechanism to Gerrit API to make integration with Gerrit easier.  Make things easier for folks like Zuul.


## Repository home page, browsing and Code search
Some may argue that code search and repository browsing like Gitiles should be out of scope but I disagree.  A repository view is the missing on-ramp that I was referring to earlier.  It is the key missing piece for an open source project to simply use Gerrit for its git hosting.  The repository view/home page is the 'storefront' for the project and where the project gets search engine hit and exposure.  Each repository already has some kind of home page in Gerrit (like this https://gerrit-review.googlesource.com/admin/repos/Core-Plugins) but it's not first class the way GitHub treats a project/repository.  If done right, the repository view can be a good place for customization and integration as well.  Instead of having some fixed widgets like contributor stats, releases, language stats the way GitHub has it, external systems like CI or bug tracker
can have widgets with live status there (like those CI/code scan badges maintainers place in the README but more advanced and elaborate.)  Even if we don't have the resource to invest in code search, I think having a first class repository home page is still a good idea.

This fits in the idea you mentioned in the beginning: to onboard the new users even if Gerrit as a highly specialized
code-review tool doesn't want/need to be a repository browser. 


Another possibly missing 'home page' is the concept of a collection of repositories (the way GitHub treats organization.)  Perhaps git submodule can have some special UI treatment but I haven't quite thought this one through yet.

## Final thoughts
Looking at the notes, Ben R asked, "Gerrit is a specialized tool. If we are all product managers, where do we want to go?"  Git started with the ideal of being distributed, but looking at the current trend in git hosting, natural forces (like toolings, admin overhead, resource constraints, ease of use, etc.) seem to be pushing things back to a more centralized model.  Perhaps a good mission for Gerrit to have is to help keep git distributed by building tools on top of git.  (NodeDB being one of the prime examples.)

Anyway, these are my two cents.  What do you think?

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Kenny Ho

unread,
Jan 14, 2021, 10:25:51 PM1/14/21
to Saša Živkov, Repo and Gerrit Discussion
Hi Saša,

On Thu, Jan 14, 2021 at 8:25 AM Saša Živkov <ziv...@gmail.com> wrote:

However, I believe that you are talking about a slightly different topic here: "the adoption of Gerrit by the first-time users".
The main topic here is why long-term Gerrit users are moving away from Gerrit. Most of them are already aware of all of the advantages of the "GerritFlow".
Trying to relate what you wrote here to the topic of long-term Gerrit users moving away, I believe that your point is that (continued) Gerrit adoption
also depends on constantly getting new Gerrit users within the organizations where Gerrit is already established.
 
This is correct, but I think there is something even more subtle.  The developers might be aware of the advantages of GerritFlow, but because of the lack of vocabulary, the awareness could simply be in the subconscious.  So when new users join, the senior devs lack the language to teach, and when new users ask for a simpler workflow, the senior devs won't be able to defend the status quo.  Some developers might also take what Gerrit has for granted, assuming the power of Gerrit (like the workflow and access control) is available everywhere.
Reply all
Reply to author
Forward
0 new messages