On 1/22/20 10:01 AM, Yedidyah Bar David wrote: > 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? > The current requirement is for a pull request based workflow, which users of pagure, gitlab and github are already used to. Gitlab, github, and pagure cover a broad assortment of our current developer base, as well as many of the upstreams we interact with. Gerrit, as you mention below doesn't use this method. That's basically the reason we didn't list 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 >> > > -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77