[CentOS-devel] Git Forge Requirements: Please see the CentOS blog - https://blog.centos.org/2020/01/git-forge-requirements-odf/

On Wed, Jan 22, 2020 at 12:04 AM Jim Perrin <jperrin at centos.org> wrote:
>
> Hi Everyone,
>
> This email has me wearing multiple hats, both as a member of the CentOS
> Project, and as a manager within RH's Community Platform Engineering
> team. For those of you who may not be know, CPE is the team inside RH
> responsible for CentOS and Fedora infra and engineering and is home to
> many of the Project folks you may be used to working with such as
> Fabian, Johnny, and Brian.
>
> On behalf of the CPE team I want to draw the communities attention to a
> recent blog post[1] which may impact you.
>
> The TL;DR is we're attempting to determine if our needs are best served
> by one of 3 solutions (in no particular order):
>
> * Pagure
> * Gitlab
> * Github

Any particular reason for not including gerrit?

>
>
> We will be seeking input and requirements in an open and transparent
> manner on the future of a git forge solution which will be run by the
> CPE team on behalf of the CentOS community.
>
> A similar message was sent to Fedora's devel list[2] as both projects
> use Pagure so this message may be duplicated if you participate in both
> communities.
>
> If you have specific features, use cases or workflows you'd like us to
> consider, please call them out to make sure they're heard. Rich Bowen
> and I will be gathering these to bring to the CentOS Board as a
> stakeholder as described in the blog post.

I'd like to highlight one important difference, IMO, between gitlab/github
and gerrit. Didn't try much pagure, but I think it's similar to the
formers. Please consider that I mostly use gerrit (in oVirt) and have much
less experience with the others.

gitlab/github encourage, AFAIU, "traditional" (patches sent to, and reviewed
on, mailing lists) behavior, with the only difference being a richer GUI
(compared to most mailing list archive web frontends). You start by branching
somewhere, push some patches, then ask for reviews, and as a result of the
review, push more patches to your branch, eventually leading to a merge. This
remains visible in the git log after the merge, and everyone can later on see
the changes done during the review process, but not the actual review comments,
unless checking the web UI.

gerrit, OTOH, works differently. Usually, the object you work on is a single
patch, not a full branch. You push such a patch to gerrit, and include in its
footer a special 'Change-Id:' tag, which lets gerrit identify it, and ask for
reviews. Then, as a result, you normally change stuff, commit them
with '--amend',
and push to the same Change (with same Change-Id). People that check
your change's
web page, can see both versions, comments for each, add comments, etc. Once
the change is ready to be merged, you (or a maintainer, or gerrit itself, it has
several options) rebase, then commit a single patch to the branch. No merge
commits in the log, no differences between the various versions prior to merge,
only a single git patch. Log is very clean, easy to read and understand, but
misses all the work done prior to merging - no intermediate versions,
no comments,
etc. All of these can only be found in the web ui. If you do need them, though,
and don't mind using the web UI, everything is there, and is much more
comfortable
to see/find, at least compared to trying to follow a similar flow with
github/gitlab.

I didn't try searching much, but I think that gitlab/github/pagure do not offer
a similar experience. If I try to push a new version ('--amend',
'--force'), it's
at least not easy to see the previous version on the web ui, nor find
the comments
written for it, or at least see what version they were written for.
With gerrit, in
several cases, finding previous versions of eventually-merged patches,
and the review
comments written for them, was invaluable for me.

I admit that downloading/mirroring gerrit's DB locally is a feature I
do miss, but
given only these options, I'd pick gerrit. There is also a separate
project called
gertty, a text-based interface to gerrit which allows offline work,
but I never had
a reason strong enough to use it, as I almost always do have an
Internet connection
when I work. I still might, eventually...

I am not representing the oVirt project. I do know that there are other opinions
here, and our CI system, while being quite tied to gerrit, also supports github,
and several sub-projects do use that, I think quite happily.

Hope this helps, best regards,

>
>
>
> 1. https://blog.centos.org/2020/01/git-forge-requirements-odf/
>
> 2.
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YKA74LI7RU4PEQF3BOEL35MTVIRVHYUM/
>
>
> Thanks!
>
>
> --
> Jim Perrin
> The CentOS Project | http://www.centos.org
> twitter: @BitIntegrity | GPG Key: FA09AD77
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>


-- 
Didi