Re: Proposal to deploy GitLab on gnome.org

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

Hi,

On Wed, May 17, 2017 at 11:33 AM, Sébastien Wilmet <swilmet gnome org> wrote:
> On Wed, May 17, 2017 at 01:42:15AM +0200, Jehan Pagès wrote:
> > 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.
>
> Once your commit is merged upstream, you can delete your fork repo (but
> yes, maybe the majority of people don't do it).

And I perfectly understand why they don't. They think that maybe they
will finish their patch some day and be able to make a pull request
(since they would usually fork first before actually make their first
commit). They think that they may do another patch some day; so when
this day come, why bother forking again? I would do the same. After
all, it's not my own disk space!

Well if GNOME is fine with hosting thousands of clones of all their
repositories for every one-time committer which comes, I guess it's
ok.

> On GitHub at least it's easy to see if a repo is a fork, with a link to
> the upstream repo.
>
> Most developers are more familiar with the GitHub workflow, I think it's

Most developers who are on github because they discovered public
project contribution there, maybe. So they got used to the only thing
they know. I am absolutely not sure that they are actually more than
all the developers who used saner workflows for years! But I don't
have statistics, so who knows! I may be wrong. ;-)

Now don't take me wrong. I am not fully against the migration. I think
a lot of things would be nice on gitlab. But the workflow part is
horrible IMO. This whole public forking business. I am not asking for
the gitlab dev to change it (or for GNOME to patch gitlab) as a
default. I know that won't happen. I am only asking if we can have
"alternative" support for patches so that the ones who don't want to
fork can go the alternative route. Basically a bug report with a patch
should be considered same as a "merge request".

Also obviously having a git-bz equivalent, as others pointed, would be
very nice.

> an easier workflow than attaching a patch to a bugtracker ticket. Once
> the contributor has pushed a branch on the fork repo, all the rest can
> be done from the web interface by clicking on some buttons.

Assuming you consider than pushing on buttons on a web GUI is "easier"
workflow, you may be right.
As a developer, I spent most of my time in my terminal. The less I get
out of the terminal, the better I feel. I don't want some actions
which didn't need web browser interaction to suddenly need it.

Jehan

> --
> Sébastien



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