Re: [discuss] So what does Gerrit actually get us, anyway?

Randy Bias
 

From my perspective, Gerrit is not really a very friendly tool.  I think it’s important to closely consider the points of Will below.

 

However, that being said, I think the current priority needs to be on migrating completely from Juniper and I’m a little resistant to making this kind of change until that is done, although I could be persuaded if it continues to take a long time to complete the migration.

 

 

 

Best,

 

 

--Randy 

 

Vice President, Technology - OSS

Juniper Networks

+1 (415) 939-8507

TWITTER: @randybias

LINKEDIN: linkedin.com/in/randybias

ADMIN: jeanettet@...

 

From: <dev@...> on behalf of Will Stevens <wstevens@...>
Reply-To: "dev@..." <dev@...>
Date: Tuesday, June 11, 2019 at 6:06 AM
To: TF Dev <dev@...>
Cc: "discuss@..." <discuss@...>
Subject: Re: [TF Dev] [discuss] So what does Gerrit actually get us, anyway?

 

Valentine, I think your comments are quite accurate.

 

I know the CLA process has been a major blocker for contribution, and that is not a Gerrit thing per-say, but more of a process issue.  I think Vicky and I finally got the CCLA that CloudOps signed a YEAR ago working its way through the system.  So, I would agree that this is not a knock against Gerrit.

 

That said, I think your comment that "In a nutshell, Gerrit is (a bit clunky) code review tool which also does 

code hosting, Github is code hosting tool which also does review." is very accurate.  The one thing that Gerrit does do very well is gating commits into the main line code.  The rules that can be defined around review and validation of PRs is absolutely an area were Gerrit offers a good deal of flexibility.  So in Gerrit the reviews and PRs are the first class objects, while in Github, the code is the first class object.

 

So I guess the question comes back to, is the +2 feature that Gerrit offers a critical feature?  Are the strengths of Gerrit really what the community needs?  

 

One of the reasons that the grand majority of open source projects run on Github is because it is easy.  It is easy for users to learn the code.  It is easy for users to fix documentation issues.  It is easy for users to get familiar with the code to then consider becoming an actual code contributor.  

 

If I am a user of TF and I want to dig into some code, I have to do the following:

- Find review.opencontrail.org (through some documentation probably, searching in google wont find it).

- There is no mention of repositories there, you have to figure out that the code is under "Projects".

- But clicking Projects doesn't do anything, oh wait, it made a "List" menu option appear.

- Click the "List" menu option.

- Click on one of the repos.  Ok, I can clone it, but where is the code?  Where is a README to give me context of what I am looking at.

- Ok, there is no way to get to the code from this screen, lets start over and see if I can find the code.

- Click, click, click, ... oh, what is the 'gitweb' thing on the right, click.

- Ok, great now I see some stuff relevant to this project, but where is the code?

- After much trial and error they are likely to FINALLY find the 'tree' link which actually points them to the code.

- Ok, lets read the README file to make sure I am in the right place.  Oh wait, there is not MD renderer, so I have to know how to read Markdown.

- Ok, lets check the code.  OMG, my eyes, there isn't even syntax highlighting.  Who can read this?

- Why am I here again?  Maybe I will just tell my boss that I looked at TF and its not right for us.

 

VS on Github:

- Google for a project.  Oh look, the code.

- A README introduces me to the project, this looks right.

- Now I can browse the code and figure out what is going on.

- Let me link the line of code that is the problem to my coworker so they can have a look.

- etc...

 

What is important for the users and the community?  I think the visibility and usability of the tooling we are expecting our users and contributors to use is extremely important.

 

Have you ever seen a Gerrit repo show up in a google search?  Nope, because even google gave up looking for the code in that mess...

 

My two cents as an open source contributor of many projects...

 

Cheers,

 

Will Stevens

Chief Technology Officer

c 514.826.0190

 

 

 

On Tue, Jun 11, 2019 at 3:08 AM Valentine Sinitsyn <valentine.sinitsyn@...> wrote:

Hi all,

That's not how it should be obviously. However your story suggests that
the real blocker was CCLA (and I know where you come from), not Gerrit.
Are there any indications that ICLA/CCLA process on Github would be more
straightforward? Is it related to some bug or obscurity within Gerrit
itself, not our processes (which we are trying to fix now)?

I'm not a big fan of Gerrit personally, but it does have some nice
features such as +2 reviewers which are not readily available in Github.
In a nutshell, Gerrit is (a bit clunky) code review tool which also does
code hosting, Github is code hosting tool which also does review.

Valentin

On 11.06.2019 4:53, Davis, Matthew wrote:
> Hi all,
>
> For those who didn’t see my previous emails, I’d like to tell my story.
> (I think it’s part of the motivation for Vicky’s question.)
>
> I have about 16 patches I have been trying to submit since February.
>
> I have already submitted some patches to the docs on GitHub, and they
> have already been merged.
>
> That was simple and straightforward, like it /should/ be.
>
> That was just like submitting to any other non-LF project.
>
> But the rest of the code is on Gerrit, which is not straightforward.
>
> Trying to understand Gerrit is time consuming, because it’s a steep
> learning curve.
>
> That can be ok if there are useful features of Gerrit which outweigh
> that high barrier to entry.
>
> So, what are those advantages?
>
> Worst of all is the CCA issue, which is tied into Gerrit. After 4 months
> of trying, I still haven’t been approved in the system.
>
> The old approval system is not working any more. The new gerrit doesn’t
> yet have any code. Everyone talks about how things are about to change,
> but it’s been like this for at least 4 months.
>
> So I am unable to submit patches or raise issue tickets for the main
> body of code.
>
> I am about to move on from my current role to a new one, and my team at
> work is being disbanded.
>
> So after 4 months of trying to get patches submitted, I will have to
> abandon my patches.
>
> Over the last 4 months I’ve had to deploy Tungsten using a custom
> Ansible playbook which applies custom patches that I cannot contribute
> upstream.
>
> If Tungsten was on Github, those patches would have been submitted and
> merged months ago.
>
> But because the code is on Gerrit, (and because of the overbearing CCA
> process) the community will not get those patches, ever.
>
>
> That is the impact of using Gerrit.
>
> In a prior discussion someone mentioned self-hosting as a benefit of Gerrit.
>
> GitHub and GitLab both have self-hosted options if that is a concern.
>
> Other project such as Ansible (on GitHub) have an automatic CCA. (“By
> submitting this PR you agree to … “) So the project still gets the same
> legal protections, but without the bureaucratic hurdles.
>
> I think that is the motivation for the question.
>
> Regards,
>
> Matt
>
> *From:*dev@... [mailto:dev@...] *On Behalf
> Of *Sukhdev Kapur via Lists.Tungsten.Io
> *Sent:* Tuesday, 11 June 2019 9:34 AM
> *To:* dev@...; discuss@...;
> dev@...
> *Subject:* Re: [TF Dev] [discuss] So what does Gerrit actually get us,
> anyway?
>
> This is a very open ended question. What is the motivation of asking
> this question?
>
> Sukhdev
>
> Get Outlook for iOS <https://aka.ms/o0ukef>
>
> ------------------------------------------------------------------------
>
> *From:*dev@... <mailto:dev@...> on behalf of
> VM (Vicky) Brasseur via Lists.Tungsten.Io
> <vmb=juniper.net@...
> <mailto:vmb=juniper.net@...>>
> *Sent:* Monday, June 10, 2019 9:37 AM
> *To:* discuss@... <mailto:discuss@...>;
> dev@... <mailto:dev@...>
> *Subject:* Re: [TF Dev] [discuss] So what does Gerrit actually get us,
> anyway?
>
> Adding dev@, since the devs have skin in this game.
>
> *From: *<discuss@... <mailto:discuss@...>>
> on behalf of "VM (Vicky) Brasseur via Lists.Tungsten.Io"
> <vmb=juniper.net@...
> <mailto:vmb=juniper.net@...>>
> *Reply-To: *"discuss@...
> <mailto:discuss@...>" <discuss@...
> <mailto:discuss@...>>
> *Date: *Monday, June 10, 2019 at 12:32 PM
> *To: *"discuss@... <mailto:discuss@...>"
> <discuss@... <mailto:discuss@...>>
> *Subject: *[discuss] So what does Gerrit actually get us, anyway?
>
> Will and I are sitting here in the lovely CloudOps offices in beautiful
> Montreal, having a little 2-person TF hackathon, and we got to talking…
>
> Real Soon Now™,  we'll be moving the repos from Juniper to Gerrit and
> then mirroring them from Gerrit to GitHub.
>
> But what exactly does Gerrit do for us, anyway?
>
> Wouldn't just going directly from Juniper to GitHub and not do Gerrit at
> all entice more people to contribute and dramatically improve the
> contributor experience?
>
> Neither of us have yet seen an explanation for why Gerrit **needs** to
> be involved at all.
>
> Could someone please explain why it's needed and, if it turns out it's
> not really needed, could we please just not subject our community to the
> misery of having to use Gerrit?
>
> --V
>
>

--
С уважением,
Синицын Валентин


Join dev@lists.tungsten.io to automatically receive all group messages.