Hello Mattias,
Thanks for sharing your thoughs!
Your concern is about using fast forward merge. Yes, we raised this concern as
the top most important for us, and as we mention in the wiki we have good news,
GitLab team is willing to strongly consider making fast forward merge to CE if
GNOME decides to switch to GitLab.
Don't worry much about this one :)
Best regards,
Carlos Soriano
-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 12:04 AM
UTC Time: May 16, 2017 10:04 PM
From: mattias.jc.bengts...@gmail.com
To: desktop-devel-list@gnome.org
Hi all!
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> The outcome of this evaluation process is that we are recommending
> that GNOME sets up its own GitLab instance, as a replacement for
> Bugzilla and cgit.
This is very exciting! I've been following the plans on the wiki and
the discussions in #sysadmin and have been waiting impatiently for you
to reveal the plans to the public.
As part of my responsibilities at my current work I help maintaining
our internal GitLab CE instance and from my limited experience,
updating and maintaining it has been rather easy.
One exciting thing about GitLab is its fast pace of development. New
releases with new features are coming often.
One question though regarding the GitLab CE merge button:
The merge button in GitLab CE produces (non-ff) merge-commits
which might be undesirable (the history gets really hard to read
IMHO). GitLab EE allows you to rebase and/or perform --ff merges
instead.
At my work we keep a semi-linear git history:
- we only allow merges based on the tip of master
- we always merge with --no-ff (which is what GitLab's merge
button does)
This gives us grouping of commits into features, while still
making sure our history is reasonably easy to follow.
To enforce this with GitLab CE we use a pre-merge CI test that
tries to perform a fast forward merge, and fails if it can't. We
then set the merge setting for the repo in question to not allow
merging MR's with failing CI pipelines.
In GNOME, the most common workflow has been to use a straight
history without merge-commits + release-branches. This implies making
a fast-forward merge or a rebase, which means that the above mentioned
trick won't work with our model.
From my understanding (after reading the workflow description),
the plan is to just not use the merge-button if you want to keep
the current merging model.
This is /definitely/ fine by me, the net gain from moving to
GitLab is still *huge*. But I'm wondering, has there been any
further discussion around this? Has anyone reached out to GitLab
asking if this feature could be moved to CE for us?
Regards,
A very excited Mattias
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list