Re: Proposal to deploy GitLab on


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

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.



ZeMarmot open animation film

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