GNOME.org
 

Re: Proposal to deploy GitLab on gnome.org

Hi,

On Wed, May 17, 2017 at 3:55 PM, Bastien Nocera <hadess hadess net> wrote:

On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano wrote:

-------- Original Message --------
Subject: Re: Proposal to deploy GitLab on gnome.org
Local Time: May 17, 2017 2:10 PM
UTC Time: May 17, 2017 12:10 PM
From: hadess hadess net
To: Carlos Soriano <csoriano protonmail com>
desktop-devel-list gnome org <desktop-devel-list gnome org>

On Wed, 2017-05-17 at 06:36 -0400, Carlos Soriano via desktop-
devel-
list wrote:

Hey Bastien,

Not sure if you read the wiki and the workflow we outlined in

there,

since we mention how this works. You will realize that's not
necessary for you, neither a git-bz alternative since you will

use

just git:
- git-bz apply equals to git checkout remoteBranch


No, it doesn't. git-bz apply on a master or version branch will
allow
me to amend commits. It does everything but push. The above doesn't
allow me to apply the same set of patches to a development and a
stable
branch for example.


Doesn't git rebase do precisely this?


I don't quite understand the workflow for users to create merge
requests with patches added, compared to my experiences with GitHub for
example, so bear with me.

If I'm a registered developer for the GNOME org, or that particular
module, I'd create my merge requests as wip branches in the main
repo?Or as branches in a separate repo that I have the control of?

What about developers that don't have GNOME commit access? Do they
fork, play in their corners and then create a merge request?


The typical workflow as advised by github (and therefore I believe
that's similar in gitlab), if not mistaken, is:

1/ clone the repo you want to fix into a new public remote by clicking
a "fork" button in the web GUI.
  So for instance if your nickname is 'bastien' in git.gnome.org,
let's assume that 'gnome-shell' repo is under
git.gnome.org/git/gnome/gnome-shell, then clicking the button will
create a new remote git.gnome.org/git/bastien/gnome-shell.
  Notice that the origin URL is slightly different from current
(adding gnome/), that's because github/gitlab need are all prefixed
with some kind of project or user namespace (so I guess git.gnome.org
will have to update project URLs with this concept, no?).

2/ Clone your personal repo into a working branch on your computer.

3/ Make your commits and push.

4/ Go back to the web GUI and click the merge request button.

Personally I don't think I ever did this, because I want to checkout a
code before even being sure I would do a patch. Creating a public repo
just to read code is dumb. So I just clone the upstream, and only if I
end up doing a patch, I would only then "fork" on github, then update
my local repository to point to my "fork", so that I can push then
click the "pull request" button. That's still very cumbersome.

IMO this is a completely broken and over-complicated workflow. For
long term contributors, having their own remote can be understandable.
But for one-time contribs?


Does that
merge request automatically create a branch in the upstream repo? How
do we stop merge request spam, or the unbounded growth of the repo with
all the wip branches, if that's the case?


No. AFAIK, merge requests don't create an upstream branch. Fortunately
this would be a very bad security issue!

Jehan


- git-bz attach equals to git push origin HEAD:fix2340issue, then
click create merge request.


Does this rewrite the commit message to include the PR or bug
number?


No, as written in the wiki you write "Closes: $number" and it will
handle things automatically.
Of course some addition could be done to do the rewrite.


Right, so that's not automated, and you can't know what to put in the
commit messages until you've create the merge request. Kind of a
chicken and egg problem.


Do we end up with separate merge requests and bug numbers,
segregating
users and developers? And yes, clicking a button is a problem when


Yes. They are different concepts in this tool, which I though it was
an improvement. The bug is more about the discussion of what is
wanted/motivation/reasoning/design/etc., the merge request is about
pure code.
Not sure I would frame it as segregating users and developers though.


As Jehan mentions, it is. Users filing bugs look at open issues, most
of the time, but don't look at merge requests at all.


"git-bz file" took care of all the clicky stuff on the command-
line.


Right, that can be improved.


And since you will have access to all projects...not need for

your

own repo.

Do you mean you don't like the extra step that is clicking once

per

issue the "create merge request" button?


I don't like the fact that the bug report and the merge request are
separate.


If that's the case, why is the command line tool we mention in

the

wiki not good for you? (you will need some alias for adapting it

to

your needs, or maybe we can modify to make the "create merge

request"

more comprehensible?)


The only mention of a command-line tool says:
"There is a CLI tool which allows a wide range of actions to be
done
from the command line, although it isn't particularly user
friendly."
which is a bit low on details to allow me to comment on it.


It's rather vague, I agree. But you can explore it yourself, the
readme of the project is quite explanation. But I'm afraid is not up
to the expectations you have as it is right now. Would be good to
improve this of course.


Do you have a link to the tool and its documentation? There's nothing
in the Wiki linking to it, it just says "a tool exists".
_______________________________________________
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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]