[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 19:33:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 10.05.2019 17:19, Eli Zaretskii wrote:

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.

I can believe that, even if I don't really understand it.

Anyway, IIRC your current stance on that issue is that we'll need an Emacs-based client anyway, even just for the issues tracker.

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

Hmm. Let's see if it can be configured as well, or we can add that to the list of requirements on the GitLab-CE issue Toon opened.

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.

Same as above.

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 you log into EMBA (you might have to register first (*)) and navigate to this page: https://emba.gnu.org/profile/notifications

you will see two "notification level" dropdowns, one Global, and one for 'emacs'. I think you can change either.

Click on one of them and choose the last item: Custom. You will then be able to choose the events to get notifications for.

MR reassignments are in that list.

Here's also the same information on the API level: https://docs.gitlab.com/ee/api/notification_settings.html

Not sure if that list is exhaustive, or if there are emails we'd want to configure off but cannot. That would, again, be something to ask the GitLab developers for.

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.

But I already do, here.

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.

I try.

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?

No, I'm suggesting to use it as a sandbox at first. Post some random issues, close them, reopen them, write some comments, receive comments from others, respond to them over email, etc, and see how well that works, and what the main problems are.

To post a new issue, you can navigate to https://emba.gnu.org/emacs/emacs/issues and click "New issue". This also requires registration (at least, for now (**)).

(*) I think currently registration is only manual, so we'll need to ask Toon to create an account.

(**) IIUC later we can configure it to allow logging in with existing Google/Twitter/etc accounts, and, with some work, even authenticate with Savannah (https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md).

reply via email to

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