[gmx-developers] Transition to Gitlab

Thu Aug 1 06:20:53 CEST 2019

Hi,

As far as I could tell, the last point - which I agree is nice - is available at least in gitlab too (not sure about github) by only accepting fast-forward merge requests, and then one can decide to squash them (but that might not have been available 5-7 years ago).

However, my take on it isn't based on not liking Gerrit, but finding a solution that is is stable, fast, and with as little administration as possible for the combination of

- code review
- hosting multiple branches 
- making it easy for users to maintain separate repos
- A CI where we specify jobs as docker images, and have the CI specs fully integrated in the source repo
- Enabling us to self-host CI jobs with a few fat redundant servers
- improving testing performance by enabling caching  per change
- Separating long compile from short testing runs so we can compile everywhere instead of waiting for a particular host
- not having to maintain multiple sites (eg. Gerrit+Jenkins+Redmine) and doing admin like removing spam users
- Having so clear documentation that everyone can fix things and extend/adjust jobs
- Zero cost

... And there i simply haven't found any good overall setup based on Gerrit.

Cheers,

Erik

--
Erik Lindahl <erik.lindahl at scilifelab.se>
Professor of Biophysics
Science for Life Laboratory
Stockholm University & KTH
Office (SciLifeLab): +46 8 524 81567
Cell (Sweden): +46 73 4618050
Cell (US): +1 (650) 924 7674 

> On 1 Aug 2019, at 00:20, Schulz, Roland <roland.schulz at intel.com> wrote:
> 
> Many discussions on the web:
> e.g. https://softwareengineering.stackexchange.com/questions/173262/gerrit-code-review-or-githubs-fork-and-pull-model
> or https://news.ycombinator.com/item?id=8605293
> 
> My take:
> 
> Github/gitlab pull-request pros:
> - Much more developers are familiar with it
> - Allows to review branches
> - Doesn't force the developer to rewrite history and break into individually small reviewable patches
> 
> Gerrit pros:
> - What we are used to. Either model needs a good workflow with agreed on best practices. We need to learn/document them anew if we switch.
> - Forces developers to rewrite history makes it sometimes easier for reviewers
> - You end up with a single commit after review which is guaranteed to compile and work by itself. With pull-request you have a branch with all the fixes based on the review. Either you squash it before you merge or you have all the fixits commit in the main git history. In the first case if the original code was multiple commits from a branch (and if not you lose the main advantage and still force people to create small commits) then that history is lost, because pull-request don't distinguish between commits from the initial history prior to review and the fixits based on the review/CI failures. In the latter case you'll end up with some commits which won't compile which is problem if you later need to e.g. bisect or revert. Or you need to use a mixture of commits and history rewrite but that isn't well supported.
> 
> Roland
> 
>> -----Original Message-----
>> From: gromacs.org_gmx-developers-bounces at maillist.sys.kth.se
>> [mailto:gromacs.org_gmx-developers-bounces at maillist.sys.kth.se] On
>> Behalf Of Berk Hess
>> Sent: Wednesday, July 31, 2019 2:30 PM
>> To: gmx-developers at gromacs.org
>> Subject: Re: [gmx-developers] Transition to Gitlab
>> 
>> That's important information.
>> 
>> Is there some place which discusses the pros and cons of both workflows?
>> 
>> Cheers,
>> 
>> Berk
>> 
>>> On 7/31/19 11:09 PM, Schulz, Roland wrote:
>>> How will the code review work in gitlab? We are planning to switch to the
>> pull-request workflow from the current gerrit workflow? They both have
>> pros and cons but they are very different. So I think that's an important
>> decision. And note that you really need to change to the different best
>> practices for a pull-request workflow. Github/gitlab don't work well if you
>> rebase changes which is required for gerrit.
>>> Note that http://www.gerritforge.com/pricing.html#platinum provides
>> free Gerrit hosting for OpenSource projects. So if we want to stick with the
>> gerrit forkflow we can do so while moving to a hosted solution. But
>> gerritforge only works with github and not gitlab. So it wouldn't make sense
>> to move the issues to gitlab if we wanted to use gerritforge.
>>> 
>>> Roland
>>> 
>>>> -----Original Message-----
>>>> From: gromacs.org_gmx-developers-bounces at maillist.sys.kth.se
>>>> [mailto:gromacs.org_gmx-developers-bounces at maillist.sys.kth.se] On
>>>> Behalf Of Paul bauer
>>>> Sent: Wednesday, July 31, 2019 8:45 AM
>>>> To: gromacs.org_gmx-developers at maillist.sys.kth.se
>>>> Subject: [gmx-developers] Transition to Gitlab
>>>> 
>>>> Hello @ all developers,
>>>> 
>>>> the core team is currently investigating a transition of our code
>>>> review, issue tracking and CI to Gitlab, to reduce the time
>>>> developers need to spend on maintaining our current, self-hosted
>> infrastructure.
>>>> As part of this we are planning to transfer the information in
>>>> Redmine to Gitlab issues and milestones.
>>>> 
>>>> We want to have issues and such still linked to the correct
>>>> users/developers, so we need the Gitlab user names of those of you
>>>> that are interested to continue development on Gitlab.
>>>> This is a requirement of the script that performs the transition :(
>>>> Those users should also link themselves to the GROMACS organisation
>>>> (https://gitlab.com/gromacs).
>>>> 
>>>> Please send the Gitlab user names as private e-Mail to either me or
>>>> another member of the core team.
>>>> 
>>>> Cheers
>>>> 
>>>> Paul
>>>> 
>>>> 
>>>> --
>>>> Paul Bauer, PhD
>>>> GROMACS Release Manager
>>>> KTH Stockholm, SciLifeLab
>>>> 0046737308594
>> 
>> --
>> Gromacs Developers mailing list
>> 
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> before posting!
>> 
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>> 
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
>> send a mail to gmx-developers-request at gromacs.org.
> -- 
> Gromacs Developers mailing list
> 
> * Please search the archive at http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before posting!
> 
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> 
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or send a mail to gmx-developers-request at gromacs.org.