[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]
Date: Mon, 2 Dec 2019 03:20:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

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

OK, I found the report we filed back then:

If someone is interested in my personal perspective on this, it is


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]