Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden,
>  address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 10 May 2019 16:56:02 +0300
> 
> 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?"

Which I already answered.

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

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.

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

You can interpret it as you like, but questions regarding CC and
In-Reply-To don't make sense in any context but email.

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

Not so easy, as most people do manage to DTRT.

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

It's worse, because debbugs doesn't send me notifications of closing
bugs, except when I close them, or when I was the one who filed the
bug.

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

Only once, yes.  I don't want notifications about the attributes of
the new bug being set as side effect of accepting it.

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

I hoped someone will explain how.  No one did.

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

Email filters are the last resort in my book.  It would also be in
yours, if you considered a possibility to work via email.

Once again, if you want to make a change in our workflow, please make
sure the change doesn't raise the bar for the core developers too
much, or else it will be a hard sell.

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

Not what was being discussed.

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

I don't think I understand what such an experiment would mean.  Do you
mean we will have to deal with each bug twice?  And what would be the
workflow in that case? can someone post some instructions?