[gmx-developers] Transition to Gitlab

Thu Aug 1 16:55:14 CEST 2019

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).

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.

Cheers,

Erik

On Thu, Aug 1, 2019 at 6:20 AM Erik Lindahl <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>
> 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.
>

-- 
Erik Lindahl <erik.lindahl at dbb.su.se>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20190801/b55d2867/attachment-0001.html>