Re: Proposal to deploy GitLab on gnome.org

[Jehan Pagès <jehan marmottard gmail com>]

Hi!

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"?

Jehan

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 gnome.org
> 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
> 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



-- 
ZeMarmot open animation film
http://film.zemarmot.net
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot