From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 10 May 2019 16:56:02 +0300 Message-ID: References: <1552789070.5272.1@yandex.ru> <87imwhmmt8.fsf@gmail.com> <87y347g1l3.fsf@iotcl.com> <9ac21e82-8e47-f9b5-f88d-23c0c56946d1@yandex.ru> <87pnpc1lby.fsf@iotcl.com> <83zhoezdqc.fsf@gnu.org> <87imuivfcr.fsf@iotcl.com> <83k1eyfxls.fsf@gnu.org> <3b8e2195-07c0-a240-6164-8d34bcca344f@yandex.ru> <83ftpmfp0y.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="250906"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: toon@iotcl.com, monnier@iro.umontreal.ca, agrambot@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 15:56:22 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hP60c-0013AP-7S for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 15:56:22 +0200 Original-Received: from localhost ([127.0.0.1]:43818 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP60b-0002iE-5D for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 09:56:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP60P-0002g2-Ck for emacs-devel@gnu.org; Fri, 10 May 2019 09:56:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP60N-0007aN-Rg for emacs-devel@gnu.org; Fri, 10 May 2019 09:56:09 -0400 Original-Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:47070) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hP60N-0007Zc-IY; Fri, 10 May 2019 09:56:07 -0400 Original-Received: by mail-wr1-x42d.google.com with SMTP id r7so7393086wrr.13; Fri, 10 May 2019 06:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nInWAgbMUATpJoMeDz0tlI241bNtzN+ZBwQcttM26bU=; b=QchO/2cimAZ3GNXhZVWnrp4Z7ZYbICrVgwjMeJYyiyIhlUmgY7oR9VoiQS+nugPDmr rFOiqm6GNUL8aKyMUQi0TbfMZ98NkMCCf1kkry7l0DDSQT40GUk+CPDEJOwTvFSe/pkN E1J84k8scVfcGkHB0OxtjaDNxMqFbx/ZouyGdSDeql57uPge5Lh/jRIgfiy1Aqc/3dtf G96mcIP15sekMg/ySM7Kg1P4f4ZSGHdz9xQOg/b6eCmIJtOh4GLSaVApDAGLAwt48Mos UPFSXMd286BDTqBxtrQ/yK5hSTvcyUmXsWShdPrYNqIPd6iOvd9DqLRUzxLoTvf1MsxB FqFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nInWAgbMUATpJoMeDz0tlI241bNtzN+ZBwQcttM26bU=; b=p7ttw2P+CEtEft7Ky1EpBNT7d21pGI1KA9cnWky0tA98FFlqwRtzIexVM1uF6fT3pk WPLrxGhUJd8q8OP3dZnkFgnyhxl5CXPABYLjfsgao7yzsVgnJUjCSvc8nI+iTUzeDrKZ e+Yt7s6Wde+JOCA/6kJBCVkuZ7tLAdnp1pktsoTrTcrSJ4X7lpgp5HMqjg/XGVil6MTa WRJa8TgUhK1rwWlQUOWPFuH8JVwYsSieZha0SIYUtT1CZlfhVzbrTusCa5twMtyJ7vWg u3k+G71uyPYz4a7lY7S9XYAiTHDc9P3w2QnoiZJeqwd+9e2eGdgXRpeHKrjtB9CKcxUr B7FQ== X-Gm-Message-State: APjAAAWSIfaihn3tmjbDTvQP1c/uGd1KjUQdAlOn6/zSWzdWXdNJALNm bd6EY14sLaxRj4RKE2sjOXg= X-Google-Smtp-Source: APXvYqwCUgRRt2xiG9rFzgi6PLu3SbLmk/44pThg2UgHEyGZyaGf7FX0GlNgjUtidiSqxoM89Vp0QA== X-Received: by 2002:a5d:4ec9:: with SMTP id s9mr8139296wrv.223.1557496566017; Fri, 10 May 2019 06:56:06 -0700 (PDT) Original-Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id o81sm9651213wmb.2.2019.05.10.06.56.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 06:56:03 -0700 (PDT) In-Reply-To: <83ftpmfp0y.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236371 Archived-At: 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.