[gmx-developers] Transition to Gitlab

Benson Muite benson_muite at emailplus.org
Fri Aug 2 12:27:25 CEST 2019


It has been nice to learn about Gerrit, most of the other projects I 
have encountered have just used Github or Gitlab issues. I do not know 
if the Gerrit community has similar problems in having to run several 
services.  Volvo seems to be a user of Gerrit as it is hosting a 
workshop on Gerrit in late August, http://www.gerritforge.com/events.html

Tensorflow seems to have a community supported build testing process:

https://github.com/tensorflow/tensorflow

Vendor supported builds include Intel, Redhat and IBM.

NAMD seems to also use Gerrit for code review, but does not seem to do 
continuous integration - at least openly. NWCHEM seems to use Travis CI 
(https://travis-ci.org/nwchemgit/nwchem/builds). Most other open source 
scientific software projects have neither code review nor continuous 
integration testing.

On 8/1/19 8:08 PM, Erik Lindahl wrote:
> Hi,
>
> Oh, do get me right - I too am still open in the discussion, I just need to stress that not changing anything isn't an option :-)
>
> Gerritforge might be a great solution to avoid self-hosting Gerrit, but that's a relatively minor item - I think the big challenge is to find a combined setup that works reasonably well for all the ~10 challenges I listed rather than optimizing for one at a time.
>
> My hunch is that Jenkins in the biggest problem (in particular setting up/maintaining build slaves, as well as some instabilities), followed by the complexity that comes from using many different services and having to document everything ourselves.
>
> 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 18:48, Schulz, Roland <roland.schulz at intel.com> wrote:
>>
>>
>>
>>> -----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 9:35 AM
>>> To: gmx-developers at gromacs.org
>>> Subject: Re: [gmx-developers] Transition to Gitlab
>>>
>>> Hi,
>>>
>>> On Thu, Aug 1, 2019 at 5:19 PM Schulz, Roland <roland.schulz at intel.com
>>> <mailto:roland.schulz at intel.com> > wrote:
>>>
>>>
>>>
>>>     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.
>>>
>>>
>>>
>>> Yes, I recognize that nomenclature, so that's probably it. On the other hand,
>>> since it's a choice per-change we can always choose to merge somethings as
>>> patch chains instead. Some things will likely hurt a bit, and this might very
>>> well be one of them.
>>>
>>> However: Unless we have a volunteer stepping forward and offering to first
>>> fix all the outstanding issues we have with Gerrit+Jenkins+Redmine, improve
>>> performance and then keep supporting it for everyone else, sticking to our
>>> current setup is not an alternative.  We need something drastically simpler to
>>> maintain.
>> I just wanted to provide info based on having used both in production and not having seen any discussion on the impact on code-review and workflow.
>> As I mentioned previously, if people want to stick with Gerrit, Gerritforge seems the best available hosted option. But I don't have experience with it.
>> But I have nothing against gitlab.
>>
>> Roland
>> -- 
>> 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.


More information about the gromacs.org_gmx-developers mailing list