[Top][All Lists]

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

Re: [RFE] Migration to gitlab

From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Fri, 10 May 2019 16:56:02 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 10.05.2019 15:54, Eli Zaretskii wrote:

I think you're already expecting the hypothetical person to have debbugs
installed and Gnus configured, and view the bug through the debbugs package.

No, because the current flow is email-based, so having an email client
is 80% enough.

Recall the original question: "Where do I send the email to? Who do I CC? How do I set In-Reply-To?"

Simply having an email client doesn't answer any of these questions. You first need an email to respond to. And that's basically limited to the "inner circle" of Emacs developers who are already subscribed to the bug tracker emails.

I think this is a misunderstanding,


I wasn't talking about the patches
at all, I was talking about the rest of the sources.  I tried to
explain that above.  As an example, suppose a patch touches some
function or variable, and I want to see how that function/variable is
used in Emacs.

I open Emacs. It's usually one or two Alt-Tab's away, a much quicker interaction that what most things that have to do with the bug tracker require of me.

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?

In any decent MUA (certainly with Emacs MUAs), this is almost trivial:
the defaults always DTRT.  You don't need to think about any of that.

Again, that already requires that the user is starting with an email.

The original question was clearly about doing this via email.

No, it was about how a user can interact with a bug report. But since email is the only option, of course it enumerated the details one has to get right to write the said email.

Also: is GMail a "decent MUA"? I haven't used it for years, but it's the
most popular MUA on the planet now. And that's a fact.

If you mean the decision whether to click "Reply" or "Reply all" in
the Gmail UI, then yes, the user will have to learn to click the
latter.  If that's a burden, then I guess Gmail is not "reasonable".

You can surely remember yourself that every once in a while somebody clicks "Reply" instead of "Reply All", because it's an easy mistake to make.

But see above, the question is not about which of these two buttons to choose.

On debbugs, I also always forget how to use the control server

Having a need to use the control command is rare, so I don't think
this is a serious disadvantage.

Rare to set the "found in" or "fixed in" versions? Or retitle a bug? Or
reopen? Or assign it to somebody?

Yes, all of the above.  Just look at how much these are used in Emacs.

Not nearly enough. Especially if we're talking about "fixed in". Retitling is also helpful when used judiciously.

Besides, tricky control commands will
give you that with any tool.

That's simply not true. A good tool will make a certain set of commands

I guess we have different experiences about that.

I'm pretty sure you have seen a web UI for GitHub or GitLab. "Close issue", or "reopen issue", or "set label" are only a mouse click away, and you don't have to search the Control Server documentation to figure out how to do either.

GitLab fixes that by showing buttons for actions like

There are maybe 2 or 3 people in the Emacs project who use these
actions, so I'm not sure why we should be so interested in them.

If they were easier to do, *I* would do them more often.

What for?  Why would you need to do that?

For instance, to assign a bug to somebody who is not subscribed to all bug reports, but who I know is knowledgeable in the subject.

Thankfully, I remember how to close a bug or set the "fixed in" header, but if I forgot to add that header while closing, adding "fixed in" later is not so easy. Reopening bugs is not easy either.

I don't know.  If the email notifications can be configured to work
reasonably well, and could be responded to by email, that might be
enough to start a more serious evaluation of the workflow.

If you're saying that we don't change labels of reassign bugs often, how
are occasional notifications for these actions a problem?

Who are "we"?  The few people who do that tend to do it quite a lot.

We as Emacs developers. But if you're saying it's okay that only a handful of people ever do that... OK.

And every bug is closed, which also causes a useless notification.

You mean the ones Debbugs sends? I've never considered that much of a problem. But at least GitLab can't be worse in that respect.

Also: if I myself closed the bug, GitLab wouldn't send the notification to me (that would be extraneous).

And when a patch is posted, I get another useless notification.

Sorry, you lost me here. Don't you expect to be notified for every message in the bug tracker?

I've tried to recall whether I receive them as well at my day job (we
use GitLab) and... at first, I thought I don't get them at all. Them I
remembered that MR reassignment emails do get sent. It just happens very
rarely. But if it happens, that's an important action, so I don't
understand why you don't want to be notified (they can probably be
configured anyway).

MR reassignments are important to just 2 people: the old and the new
assignee, possibly just the latter.  I certainly don't want to know
about all the reassignments of all the issues.

I don't know if I agree, but hopefully it can be configured this way.

If the email workflow is used, though, you can also do what I've seen many people recommend to others who complained about excessive emails here (or being Cc'd on discussions they do not want to read, which is more of a problem, IMHO): set up email filters. Decent MUAs support that.

More importantly, one can easily *unsubscribe* from particular
discussions. For instance, when the bug been forwarded to somebody who
has all the necessary expertise and responsibility. That can cut down on
email traffic quite a bit.

In my position, I don't think I will be able to unsubscribe, so this
is not a good option for someone who wants to read most of the
issue-related traffic.  People who do the triage are like that, for

That might make contributing more comfortable for some others, though, which is still a plus.

I understand, but that doesn't address my concerns.  However, this
particular aspect of GitLab is not a major one, I guess we will see
when we get to that.

Whenever you feel like it, we can go ahead and experiment with the bug tracker that's part of the EMBA installation. And see how far we can go with email-only workflow, without an Emacs-based client.

reply via email to

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