Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

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,

Probably.

> 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
>>>> commands.
>>>
>>> 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
>> easy.
> 
> 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
>>>> close/reopen/label/assign...
>>>
>>> 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
> example.

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.