Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 10 May 2019 14:16:30 +0300
> 
> On 10.05.2019 12:49, Eli Zaretskii wrote:
> 
> > Personally, I think an Emacs client is almost a must, if we want to
> > consider something like GitLab seriously.
> 
> 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.

> > I didn't mean the commit itself, I meant Emacs sources in general.  I
> > frequently need to look up source fragments and definitions of various
> > macros and structs when I review a patch.  Since the browser have no
> > idea where the sources are, and is not in general a good tool for
> > viewing sources of a software project, it is much less helpful here.
> 
> You can always pull the branch with changes that a user proposed

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.

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

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

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

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

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

> > 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.
And every bug is closed, which also causes a useless notification.
And when a patch is posted, I get another useless notification.
Etc. etc.

> 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.  On the rare occasion
that I do need to see that, I will gladly use a special UI for
browsing the history of an issue in some way, but that happens very
rarely, at least to me.

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

> >>> And one more thing: Emacs is I think special in how we work as a
> >>> team.  Most of the people who respond to bug report and review patches
> >>> have write access to the repository, and many of them are trusted to
> >>> push changes without approval.  It sounds like Gitlab has a very
> >>> different team organization in mind, but maybe I'm mistaken.
> 
> At work, we all have commit/push access to the project repositories.
> 
> And yet, the Merge Request workflow is still helpful, and it's what we 
> use to collaborate, discuss and push most features.
> 
> We could consider being able to access MR from people without commit 
> access as a bonus.
> 
> But the workflow is not set in stone, we as Emacs developers can choose 
> our own.

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.

Thanks.