From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [RFE] Migration to gitlab Date: Fri, 10 May 2019 15:54:37 +0300 Message-ID: <83ftpmfp0y.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="212950"; mail-complaints-to="usenet@blaine.gmane.org" Cc: toon@iotcl.com, monnier@iro.umontreal.ca, agrambot@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 14:55:11 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 1hP53O-000tBb-Qt for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 14:55:11 +0200 Original-Received: from localhost ([127.0.0.1]:42803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP53N-0001Y8-Nj for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 08:55:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP53D-0001Xi-Qc for emacs-devel@gnu.org; Fri, 10 May 2019 08:55:01 -0400 Original-Received: from fencepost.gnu.org ([209.51.188.10]:58441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP53A-0008Cw-LX; Fri, 10 May 2019 08:54:56 -0400 Original-Received: from [176.228.60.248] (port=3734 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hP536-0006BG-43; Fri, 10 May 2019 08:54:54 -0400 In-reply-to: <3b8e2195-07c0-a240-6164-8d34bcca344f@yandex.ru> (message from Dmitry Gutov on Fri, 10 May 2019 14:16:30 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:236365 Archived-At: > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com > From: Dmitry Gutov > 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.