Re: [RFE] Migration to gitlab

[Toon Claes]

Sorry it took me so long to reply, but we've had some family issues.

Eli Zaretskii <address@hidden> writes:

> I didn't "didn't approve" "even the minimal steps", that's a gross
> misunderstanding of what I wrote.

I know, and I also didn't want to make it sound like that.

> It is a bit hard to summarize all I said in a few sentences, but if I
> have to, it's that I don't yet see a clear overall picture of the
> workflow (or workflows, if there will be a few) enough to make up my
> mind about the proposed changes.

That's a good point. Some people here already know how the workflow on
GitHub happens, but I understand not everyone is familiar with it.

Let try to explain the contribution process on
GitHub/GitLab/BitBucket/etc. briefly.

A contributor wants submit a change. They generally don't have access to
push changes to the canonical git repo, so on the git hosting provider
they create a "fork", which is basically a ~git clone~ on the remote
server, but _their_ fork, so they can push code to it.

A feature branch is created for the change, and commits are pushed
there. Then a Pull Request or Merge Request to the canonical repo is
created, from their feature branch to e.g. master on emacs. This
Pull/Merge Request generates a page (dynamically) with the diff between
the two branches, similar to the patch they would normally send by
email.

The maintainers of the canonical repo can then, using the web UI,
comment on lines of code, and will ask the contributor to address those
comments. The contributor only has to push the changes to the feature
branch, and the PR/MR page updates the diff automatically. The
maintainers can review again and this can repeat as often as
needed. When the maintainers approve, they click a button, and the
changes get applied to the target branch, e.g. master.

On the PR/MR page you generally also have other information. The author
should fill in a description, explaining the changes. And based on the
settings, a template of checkboxes (in markdown, but similar to org-mode
checkboxes) will be inserted. The maintainers expect from the
contributor to have done the task and check the box if they did.

Also shows the PR/MR page the CI status. So you can directly see if the
automated test suite passed with the changes applied.

> I don't even understand what concrete changes are being proposed.
> Beyond my relative lack of familiarity with Gitlab, it provides a
> large number of features, and it is not yet clear to me which ones are
> included in the proposal.  It might make sense to produce a list of
> typical tasks and their proposed alternatives using Gitlab.

In short:

- forking repos so contributors can push code
- creating Pull/Merge Requests
- inline code review
- automated test results

> In the referenced discussion, I tried (and I guess failed, given the
> above "summary") to word my messages not as rejection, but as a
> critical assessment of the issues raised by others

That's also how I saw it. By introducing a GH/GL/BB/etc workflow we want
to make the process less painful of irregular contributors, but of
course the maintainers should not suffer from this. So my goal here is
also to be constructive and see whether we can mix that in. 

> because IMO many of the issues were described in exaggerated form

Exaggerated in which sense? I know it's trivial to you to send replies
and patches to debbugs, but to people used to the workflow described
above, it's not.

> and the proposed solutions were described in an optimistic, even
> simplistic, way that disregarded important factors and issues in Emacs
> development and maintenance that I and others have to deal with every
> day.  IOW, my intent was to try to balance the picture, not to reject
> the proposals.

I think we're on the same page here.

>> https://gitlab.com/gitlab-org/gitlab-ce/issues/60684
>
> Thanks.  I think it's a good idea to maintain a list of issues that we
> need to address, and this is a good start.
>
> (A naïve question: there's no "emacs" in the URL, so how does this
> issue relate to the project?  And what do "org" and "ce" signify in
> this context?)

I've created this issue on the project site where GitLab-CE is
maintained. So the goal is to make changes (if needed) to GitLab, to
make it possible to use GitLab for emacs development, if we ever manage
to succeed in that. 'gitlab-org' is the group, all software projects
made by the GitLab company are in that group. 'gitlab-ce' is the name of
the project. The CE stands for Community Edition, basically it's the
Free (as is Freedom) edition of GitLab. It does not contain any
proprietary code and is fully licensed under the MIT/Expat license.

> Allow me now to provide some comments on this.  They are my personal
> views at this point, not the project's position.  (They might become
> the project position if enough active developers agree with what I
> say.)  And please forgive any inaccurate/naïve/silly things I write
> due to lack of familiarity with Gitlab.
>
> I intentionally limit myself to only the few major issues, for now; I
> think the details should be addressed only after the main issues are
> resolved and/or decided.
>
> My main problem with Gitlab is that AFAIU it requires to do most of
> the work from a Web browser outside Emacs (I believe EWW is not up to
> this job, right?).

GitLab relies on javascript a lot, and EWW doesn't really cope well with
that.

> I don't like that, mainly because text editing facilities of a browser
> are vastly inferior to what I'm used to expect from Emacs.

I understand. That's why I want to figure out whether we can add changes
to GitLab, so (almost) everything also can be done outside the
webbrowser, and from emacs. Or maybe build something like the debbugs
package for emacs.

Side note: I sometimes enjoy using the browser plugin
https://github.com/GhostText/GhostText to edit textboxes, in Emacs. But
requires whiching between browser and Emacs, which isn't ideal.

> Discussing a bug report or a patch in a browser is thus inefficient
> and quite frustrating, especially when advanced text editing and
> processing is needed.  A browser also takes me a step further from the
> source code (you don't suggest that I use File->Open of the browser to
> browse the code, right?).

Well, mention you mention a commit hash in your comments, the hash
becomes clickable, taking you directly to the change. You can also use
hyperlinks to pieces of code, etc. I know it's weird to do that in the
browser, but many people grown accustomed to that. But not everyone will
like that.

> So I think having efficient integration with Emacs is very important
> for making the migration attractive, at least to me.

Many people will agree, I think.

> The second major issue is with bug reports.  This is mentioned towards
> the end of the issue, but it is IME much more important than merge
> requests, because currently most of the traffic on the bug tracker is
> bug reports, not patches.  Efficient handling of the reported issues
> is therefore much more important for me than handling of patches, and
> I didn't get the impression there's a lot Gitlab can offer in that
> direction.  I'd be happy to be mistaken, but if not, IMO we must
> provide efficient tools for dealing with bugs, including pinging
> assignees after predefined period of time, reassignment requests after
> a predefined number of pings, efficient search of bug database for
> related issues, a good tagging system for quickly finding related
> issues, etc.

Probably the most complicated about the current bug tracker, at least
from irregular contributor's POV, is interacting to a existing bug:
Where do I send the email to? Who do I CC? How do I set In-Reply-To?

I think GitLab can help a lot here. Contributors can type a reply
directly using the web UI. When a reply is made, GitLab also sends out
that by email to everyone subscribed. When you have interacted with the
ticket, you are subscribed, or you can subscribe manually, or you can
configure to be subscribed to everything.

On debbugs, I also always forget how to use the control server
commands. GitLab fixes that by showing buttons for actions like
close/reopen/label/assign...

And the great thing, I think there is nothing(?) you can do on the web
UI, that you cannot do by email. Because GitLab has similar control
commands, called Quick Actions:
https://docs.gitlab.com/ce/user/project/quick_actions.html

> Next, it is not clear to me how will this affect my Git workflows.
> Before I push a changeset, I like to build Emacs on my system, perhaps
> run Emacs under a debugger and look around at relevant variables, run
> some tests that I think are relevant, etc.  It sounds like with Gitlab
> all that must be done remotely, on some other machine?  And if I want
> it on my machine, I will need to checkout a non-master branch and
> build it?  That would be inconvenient, to say the least.  One of the
> main advantages of a dVCS is that you can do so many things locally,
> even when your network connection is down.

This probably still a shortcoming in GitLab. You are right, to get the
code locally, you need to fetch and checkout the feature branch the
contributor created. Unfortunately, GitLab does not send out an email
with patches whenever the author pushes changes to their feature
branch. I will add that to the referred issue on gitlab.com.

But at the moment you can get the diff of a merge request as patch
format, e.g.:
https://emba.gnu.org/emacs/emacs/merge_requests/1.patch

But that also does not help when you don't have an internet connection.

> Last, but not least: the email interface.  First, please don't
> under-estimate its importance.  For people who are involved in several
> projects beside Emacs, and cannot afford sitting all day long staring
> at the Gitlab UI in the browser, email is important because it doesn't
> require polling, it brings the stuff pretty much into one's face.  But
> it must be done efficiently.  And here my admittedly limited
> experience with Gitlab is abysmally bad: the one project that migrated
> to Gitlab basically flooded my inbox with unimportant notifications
> like assigning and reassigning issues, changing the issue's severity,
> and other similar litter.  I tried to configure the notifications, but
> failed to do so (perhaps due to insufficient permissions?), and the
> only thing that worked was to disable them altogether.  I think the
> email interface must be very good, flexible, and powerful, if we want
> to encourage migration.

Yes, I tried to stress the importance of email too. I regret to hear the
email interface of GitLab didn't work for you. I'll have a look whether
I can suggest changes to make the "litter" configurable. But besides
from that, are there any other annoyances you've encountered so far?

I hate to admit it, if email is the top priority, then maybe
https://sourcehut.org/ is a better alternative than GitLab. It is built
with an email/patch flow as first-class citizen. But TBH, I haven't used
it, so I cannot tell more about it and if we consider that, I suggest
someone with more experience on it will drive the possible path to
migration.

> And one more thing: Emacs is I think special in how we work as a
> team.  Most of the people who respond to bug report and review patches
> have write access to the repository, and many of them are trusted to
> push changes without approval.  It sounds like Gitlab has a very
> different team organization in mind, but maybe I'm mistaken.

GitLab shouldn't try to force you in some organisation structure, I
think there are many projects operating in very different ways, GitLab
should support that, and not counter it.

> I think this is enough for now.  Thanks for listening.

Thanks, I appreciate your extensive reply.


-- 
Toon

signature.asc
Description: PGP signature