Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[Dmitry Gutov]

On 18.11.2019 18:12, Eli Zaretskii wrote:
> > Cc: address@hidden, address@hidden, address@hidden
> > From: Dmitry Gutov <address@hidden>
> > Date: Mon, 18 Nov 2019 16:02:11 +0200
> >
> > > > Do we track that list of requirements somewhere?
> > >
> > > Depends on the meaning of "track", I guess.  And on the meaning of
> > > "we".
> >
> > OK, I found the report we filed back then:
> > https://gitlab.com/gitlab-org/gitlab/issues/28152
>
> If someone is interested in my personal perspective on this, it is
> here:
>
>    https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg01061.html

I'd like to comment on the "few major issues" there, to summarize the 
situation as I see it.

> main problem with Gitlab is that AFAIU it requires to do most of
the work from a Web browser

We can/should do an Emacs client. It shouldn't be too hard, at least one 
of the frequent contributors said that he'd probably work on it if we 
start migration in earnest. One major change, for users and developers: 
authentication.

> 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

I agree, and IMO the migration's biggest win would be in migrating to a 
new issue tracking system. Say what you want about Gitlab's problems, 
but it definitely has better capabilities for organizing bug reports 
than Debbugs (though it's a fairly low bar). The tagging system is 
there. Pinging assignees can be done using bots, which is a popular 
concept these days (basically a kind of plugin).

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

There's no "must" here. Gitlab has a CI, but it's like Hydra. You can 
still apply patches locally and build/test on your machine.

> And if I want it on my machine, I will need to checkout a non-master 
branch and build it?

What else do you do when somebody pushes as scratch/*** branch for 
review? Check it out and build.

Though of course you can create a diff between revisions and apply it to 
the current tree without switching branches or making any commits.

In any case, I don't think Gitlab will have to change this part of our 
workflow much.

> Last, but not least: the email interface.

It is important.

> 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.

IMHO you are somewhat biased by your current experience, and 
automatically consider some notifications unimportant because you don't 
receive them in the current system.

I *think* these can be configured to a better granularity, or we have a 
good chance of it being added in a future version of Gitlab. But failing 
that, email filters are still available to use.

Speaking of "unimportant notifications", I receive a large volume of 
email these days from the bug tracker, only a small percentage of which 
is actually interesting to me. And there is no way to manage that.

> 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.

I don't disagree.

On a different note, I think the chief difficulty vs the web interface 
will not be technical. We can have customizable notifications, feature 
parity, etc, but the mode of communication on Web UI bug trackers is not 
the same: people don't always quote previous messages (or when they do, 
quote them more briefly) because, in their mind, the previous message is 
so easy to read (it's displayed just above in the web interface). 
Certainly no nested quotes from preceding messages. Given the many 
complains I've already seen here about people cutting out context in 
replies, this would be exacerbated greatly. And I don't have a good 
solution for this, unfortunately. Except maybe by replacing email-based 
communication with a Emacs-based UI that mimics the Web UI in these 
respects.