Re: Proposal to deploy GitLab on


On Wed, May 17, 2017 at 12:27 AM, Carlos Soriano via
desktop-devel-list <desktop-devel-list gnome org> wrote:
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 :)

Good to read! This would also be a big problem for GIMP. We are trying
to keep up master commit log as linear as possible, without any merge
commits (it failed sometimes, errors were made!).

One of my other main issues with github/lab is the way it forces you
to fork a project on your personal account so that you can contribute.
Many of my contributions to various projects are one-liners or small
commits (as is the case for many developers). When I do this, I want
to just upload a git formatted patch file (which will also be easy for
the reviewer to test with a `git apply|am`).

Unfortunately gitlab does not allow simple .patch files.If I recall,
you can still upload one but there is no support of it. That's just
considered as a text file. So you don't get the UI for review, etc. It
is not handled the same as there "merge requests".
Well last time I tried. Correct me if I am wrong.

Github/gitlab wants to force you to fork the project into a public
repository on your private account so that you can make a pull
request. This is seriously stupid IMO and very poor workflow. That's
the reason why github/gitlab is absolutely littered with useless
repositories containing absolutely no difference with the upstream
repository (except they are outdated since the person didn't touch it
for months). I'm sure trash "fork" repositories are the majority of
github/gitlab contents.

Could GNOME's gitlab instance make sure that patch files are properly
handled so that contributors are still allowed to upload patches?
Will GNOME's gitlab instance have the same politics on "everything
should be forked one thousand times"?


P.S.: apart from this, I am happy that things go forward and I think
gitlab has some great tools for code reviewing, and simpler UI for bug
reporters. But there are some things which really make things
complicated each time I have to contribute to a github or gitlab
project (since gitlab is apparently trying to mimic github on many
core features). This made me not contribute sometimes on some projects
when I thought that the annoyance was worse than the usefulness of my
patch (whereas if I could have just git-formatted a patch, I would
have done it).

Best regards,
Carlos Soriano

-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on
Local Time: May 17, 2017 12:04 AM
UTC Time: May 16, 2017 10:04 PM
From: mattias jc bengtsson 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

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?

A very excited Mattias
desktop-devel-list mailing list
desktop-devel-list gnome org

desktop-devel-list mailing list
desktop-devel-list gnome org

ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]