Git Forge Requirements: Please see the CentOS blog - https://blog.centos.org/2020/01/git-forge-requirements-odf/
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
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.
1. https://blog.centos.org/2020/01/git-forge-requirements-odf/
2. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Thanks!
On Wed, Jan 22, 2020 at 12:04 AM Jim Perrin jperrin@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,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Thanks!
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 1/22/20 10:01 AM, Yedidyah Bar David wrote:
On Wed, Jan 22, 2020 at 12:04 AM Jim Perrin jperrin@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,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
Thanks!
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-
Jim Perrin -
Yedidyah Bar David