<div dir="ltr">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).<div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 1, 2019 at 6:20 AM Erik Lindahl <<a href="mailto:erik.lindahl@gmail.com">erik.lindahl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
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).<br>
<br>
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<br>
<br>
- code review<br>
- hosting multiple branches <br>
- making it easy for users to maintain separate repos<br>
- A CI where we specify jobs as docker images, and have the CI specs fully integrated in the source repo<br>
- Enabling us to self-host CI jobs with a few fat redundant servers<br>
- improving testing performance by enabling caching per change<br>
- Separating long compile from short testing runs so we can compile everywhere instead of waiting for a particular host<br>
- not having to maintain multiple sites (eg. Gerrit+Jenkins+Redmine) and doing admin like removing spam users<br>
- Having so clear documentation that everyone can fix things and extend/adjust jobs<br>
- Zero cost<br>
<br>
<br>
... And there i simply haven't found any good overall setup based on Gerrit.<br>
<br>
Cheers,<br>
<br>
Erik<br>
<br>
--<br>
Erik Lindahl <<a href="mailto:erik.lindahl@scilifelab.se" target="_blank">erik.lindahl@scilifelab.se</a>><br>
Professor of Biophysics<br>
Science for Life Laboratory<br>
Stockholm University & KTH<br>
Office (SciLifeLab): +46 8 524 81567<br>
Cell (Sweden): +46 73 4618050<br>
Cell (US): +1 (650) 924 7674 <br>
<br>
<br>
<br>
> On 1 Aug 2019, at 00:20, Schulz, Roland <<a href="mailto:roland.schulz@intel.com" target="_blank">roland.schulz@intel.com</a>> wrote:<br>
> <br>
> Many discussions on the web:<br>
> e.g. <a href="https://softwareengineering.stackexchange.com/questions/173262/gerrit-code-review-or-githubs-fork-and-pull-model" rel="noreferrer" target="_blank">https://softwareengineering.stackexchange.com/questions/173262/gerrit-code-review-or-githubs-fork-and-pull-model</a><br>
> or <a href="https://news.ycombinator.com/item?id=8605293" rel="noreferrer" target="_blank">https://news.ycombinator.com/item?id=8605293</a><br>
> <br>
> My take:<br>
> <br>
> Github/gitlab pull-request pros:<br>
> - Much more developers are familiar with it<br>
> - Allows to review branches<br>
> - Doesn't force the developer to rewrite history and break into individually small reviewable patches<br>
> <br>
> Gerrit pros:<br>
> - 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.<br>
> - Forces developers to rewrite history makes it sometimes easier for reviewers<br>
> - 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.<br>
> <br>
> Roland<br>
> <br>
>> -----Original Message-----<br>
>> From: <a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a><br>
>> [mailto:<a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a>] On<br>
>> Behalf Of Berk Hess<br>
>> Sent: Wednesday, July 31, 2019 2:30 PM<br>
>> To: <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
>> Subject: Re: [gmx-developers] Transition to Gitlab<br>
>> <br>
>> That's important information.<br>
>> <br>
>> Is there some place which discusses the pros and cons of both workflows?<br>
>> <br>
>> Cheers,<br>
>> <br>
>> Berk<br>
>> <br>
>>> On 7/31/19 11:09 PM, Schulz, Roland wrote:<br>
>>> How will the code review work in gitlab? We are planning to switch to the<br>
>> pull-request workflow from the current gerrit workflow? They both have<br>
>> pros and cons but they are very different. So I think that's an important<br>
>> decision. And note that you really need to change to the different best<br>
>> practices for a pull-request workflow. Github/gitlab don't work well if you<br>
>> rebase changes which is required for gerrit.<br>
>>> Note that <a href="http://www.gerritforge.com/pricing.html#platinum" rel="noreferrer" target="_blank">http://www.gerritforge.com/pricing.html#platinum</a> provides<br>
>> free Gerrit hosting for OpenSource projects. So if we want to stick with the<br>
>> gerrit forkflow we can do so while moving to a hosted solution. But<br>
>> gerritforge only works with github and not gitlab. So it wouldn't make sense<br>
>> to move the issues to gitlab if we wanted to use gerritforge.<br>
>>> <br>
>>> Roland<br>
>>> <br>
>>>> -----Original Message-----<br>
>>>> From: <a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a><br>
>>>> [mailto:<a href="mailto:gromacs.org_gmx-developers-bounces@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers-bounces@maillist.sys.kth.se</a>] On<br>
>>>> Behalf Of Paul bauer<br>
>>>> Sent: Wednesday, July 31, 2019 8:45 AM<br>
>>>> To: <a href="mailto:gromacs.org_gmx-developers@maillist.sys.kth.se" target="_blank">gromacs.org_gmx-developers@maillist.sys.kth.se</a><br>
>>>> Subject: [gmx-developers] Transition to Gitlab<br>
>>>> <br>
>>>> Hello @ all developers,<br>
>>>> <br>
>>>> the core team is currently investigating a transition of our code<br>
>>>> review, issue tracking and CI to Gitlab, to reduce the time<br>
>>>> developers need to spend on maintaining our current, self-hosted<br>
>> infrastructure.<br>
>>>> As part of this we are planning to transfer the information in<br>
>>>> Redmine to Gitlab issues and milestones.<br>
>>>> <br>
>>>> We want to have issues and such still linked to the correct<br>
>>>> users/developers, so we need the Gitlab user names of those of you<br>
>>>> that are interested to continue development on Gitlab.<br>
>>>> This is a requirement of the script that performs the transition :(<br>
>>>> Those users should also link themselves to the GROMACS organisation<br>
>>>> (<a href="https://gitlab.com/gromacs" rel="noreferrer" target="_blank">https://gitlab.com/gromacs</a>).<br>
>>>> <br>
>>>> Please send the Gitlab user names as private e-Mail to either me or<br>
>>>> another member of the core team.<br>
>>>> <br>
>>>> Cheers<br>
>>>> <br>
>>>> Paul<br>
>>>> <br>
>>>> <br>
>>>> --<br>
>>>> Paul Bauer, PhD<br>
>>>> GROMACS Release Manager<br>
>>>> KTH Stockholm, SciLifeLab<br>
>>>> 0046737308594<br>
>> <br>
>> --<br>
>> Gromacs Developers mailing list<br>
>> <br>
>> * Please search the archive at<br>
>> <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a><br>
>> before posting!<br>
>> <br>
>> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
>> <br>
>> * For (un)subscribe requests visit<br>
>> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or<br>
>> send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
> -- <br>
> Gromacs Developers mailing list<br>
> <br>
> * Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
> <br>
> * Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
> <br>
> * For (un)subscribe requests visit<br>
> <a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div></div></div></div></div></div></div></div></div>