[gmx-developers] Transition to Gitlab

[Erik Lindahl]

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.