Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Toon Claes <address@hidden>
> Gcc-Self: nnimap+soverin:Sent
> Date: Tue, 23 Apr 2019 23:08:17 +0200
> Cc: Stefan Monnier <address@hidden>, Alex <address@hidden>,
>       address@hidden
> 
> > I fear it's a bit premature, considering we've not worked out the
> > minimum requirements between ourselves yet, and Eli has not approved
> > even minimal steps toward moving to GitLab.
> 
> I know Eli didn't approve.

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

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.  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 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, because IMO many
of the issues were described in exaggerated form, 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.

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

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?).  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.  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?).  So I think having
efficient integration with Emacs is very important for making the
migration attractive, at least to me.

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.

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.

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.

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.

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