Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

Eli Zaretskii <address@hidden> writes:

>> Cc: address@hidden, address@hidden, address@hidden,
>>  address@hidden
>> From: Dmitry Gutov <address@hidden>
>> Date: Fri, 10 May 2019 19:33:56 +0300
>> 
>> On 10.05.2019 17:19, Eli Zaretskii wrote:
>> 
>> > Yes, my point was that having to work via a Web browser will need to
>> > switch frequently between it and Emacs.  Which is an annoyance, to say
>> > the least.
>> 
>> I can believe that, even if I don't really understand it.
>
> Let me try to explain.
>
> In any editing environment that is not Emacs I lack many features that
> make my work significantly more efficient.  I miss the almost instant
> completion with M-/ (since I have the Emacs manuals and the TAGS
> tables loaded into Emacs at all times, all the symbols are instantly
> found, and I seldom if ever need to type long names like
> mark_window_display_accurate_1).  I miss my abbrevs (which also allow
> me to fix some of my more frequent typos, or type stuff like "naïve" o
> "façade" without switching keyboard).  I miss the convenience of being
> able to jump to any function/macro/typedef with just "C-u M-."  (or
> even just M-. if I'm in a code buffer).  I miss the multi-buffer
> search capabilities and Grep.  I miss a more-or-less immediate access
> to the Git repository.  I miss the capability to apply a patch which
> I'm looking at, and be able to compile the result right after that,
> right from the editor.
>
> And these are just the tools I use almost all the time.
>
> Instead, GitLab wants me to use the Web browser for most of these.
> This means the Web browser now becomes a very important program for
> me, I need to start learning it much more than I bothered until now, I
> need to keep it updated at all times, I need to customize it (more
> things to learn and try), etc.  And after all that I still get an
> abysmally inadequate text editing widget, lacking most if not all of
> the features I mentioned above, while for tasks other than
> writing/editing text you ask me to switch between the browser and
> Emacs.  That's a massive degradation of my quality of life.
>
> I wonder if I'm the only one here who feels that way.  I mean, one of
> the more important advantages of Emacs is that it lets you do many
> things only tangentially related to editing program sources, and now
> we suddenly are willing to give that up?  Really??
>
>> Anyway, IIRC your current stance on that issue is that we'll need an 
>> Emacs-based client anyway, even just for the issues tracker.
>
> I don't have a "stance".  My personal preference is to do as much as
> possible from within Emacs, certainly any significant text/source code
> editing related to Emacs maintenance.  I would be very unhappy if
> forced instead to use a text-editing widget of a browser, and its
> rudimentary email capabilities.
>
> Two possible ways of working with an issue tracker that don't require
> me to switch from Emacs are: (1) email and (2) an Emacs front-end.
> Either one, or even a combination of them, will, for me, be much
> better than a pure Web UI.
>
> I'm very interested in hearing opinions of other core maintainers and
> developers.

FWIW, though I'm relatively comfortable with GitLab/GitHub UIs and
workflows and understand why they are more popular with and seem more
familiar and intuitive to new contributors, I too would be sad to see
Emacs move away from a text- and email- to a web-based UI.  Working
within Emacs simply offers too many conveniences, as you have already
described, to gladly give up.

Re: configuring or improving GitLab's support for an email workflow vs
having an Emacs client - I think the former is always a nice-to-have,
but I'm not sure to what extent it can be achieved in a practical sense,
so the latter is probably a must-have.

One example that comes to mind is inline edits.  Debbugs data is pretty
static - once an email has been sent, it can't be edited.  GitLab
comments, OTOH, can be edited, deleted, reacted to with "thumbs up" and
"thumbs down", etc.  Sure, notification of these events by email can be
tweaked so that other participants are made aware, but I bet there will
always be either a loss or deluge of certain information - the web UI
just seems inherently more dynamic than email.  So a debbugs-like
client, which fetches the latest state of an issue or merge request
being visited each time, seems more realistic/applicable to me.

Thanks,

-- 
Basil