[gmx-developers] Transition to Gitlab

Schulz, Roland roland.schulz at intel.com
Thu Aug 1 17:19:14 CEST 2019 



> -----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 Erik Lindahl
> Sent: Thursday, August 1, 2019 7:55 AM
> To: gmx-developers at gromacs.org
> Subject: Re: [gmx-developers] Transition to Gitlab
> 
> PS: Just wanted to let everyone know that I tested the "squash merges"
> setup, which works great (including a possibility to edit the commit message),
> and it checks that the branch is in a state that allows fast-forward merging
> (and does not allow any other type of merges if we say so).
But this requires that the branch can be fast-forwarded and not just that it's conflict free (like our current setup) right? This is equivalent 
This means that we will require much more manual rebasing in the future prior to merging because it is required even if there is no merge conflict.

The fast-forward setting in gitlab is equivalent to the "Fast Forward Only" submit strategy in gerrit (https://gerrit-review.googlesource.com/Documentation/concept-changes.html#submit-strategies) . But we decided that one is too inconvenient and went with the "Rebase if Necessary" strategy. I don' think gitlab has an equivalent.
 
> Now, what I haven't yet tested is how to properly rebase an entire branch
> locally when that isn't the case - although I'm sure that's just a question of
> knowing the right kind of git magic.
Gitlab does support rebasing locally and force pushing the updated branch under review. No special magic required.

Roland

> 
> Cheers,
> 
> Erik
> 
> 
> 
> 
> On Thu, Aug 1, 2019 at 6:20 AM Erik Lindahl <erik.lindahl at gmail.com
> <mailto:erik.lindahl at gmail.com> > wrote:
> 
> 
> 	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
> <mailto: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
> <mailto: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>
> 	>> [mailto: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 <mailto: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>
> 	>>>> [mailto: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
> <mailto: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
> <mailto: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
> <mailto:gmx-developers-request at gromacs.org> .
> 
> 
> 
> 
> --
> 
> Erik Lindahl <erik.lindahl at dbb.su.se <mailto:erik.lindahl at dbb.su.se> >
> Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
> University Science for Life Laboratory, Box 1031, 17121 Solna, Sweden

More information about the gromacs.org_gmx-developers mailing list