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 12:49:19 +0300 Message-ID: <83k1eyfxls.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="156180"; mail-complaints-to="usenet@blaine.gmane.org" Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, agrambot@gmail.com, emacs-devel@gnu.org To: Toon Claes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 11:50:47 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 1hP2Ax-000eVR-GO for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 11:50:47 +0200 Original-Received: from localhost ([127.0.0.1]:40157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP2Aw-0001IZ-EW for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 05:50:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50350) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP29l-0001FA-17 for emacs-devel@gnu.org; Fri, 10 May 2019 05:49:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP29k-00056F-0y; Fri, 10 May 2019 05:49:32 -0400 Original-Received: from [176.228.60.248] (port=4219 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hP29f-0004oN-Gz; Fri, 10 May 2019 05:49:28 -0400 In-reply-to: <87imuivfcr.fsf@iotcl.com> (message from Toon Claes on Fri, 10 May 2019 11:16:52 +0200) 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:236359 Archived-At: > From: Toon Claes > Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, agrambot@gmail.com, dgutov@yandex.ru > Date: Fri, 10 May 2019 11:16:52 +0200 > > Sorry it took me so long to reply, but we've had some family issues. We all have Real Lifes™, no need to apologize about that. I'm more worried that no one else responded to my description. > Let try to explain the contribution process on > GitHub/GitLab/BitBucket/etc. briefly. > > A contributor wants submit a change. Note how you again start from a change, not from a report of some issue/bug. As Emacs is a very old and stable project, most of our changes fix bugs, not add new features. Therefore, use cases that begin with issues are much more important to the workflow and to assessing the utility of the tools. > > because IMO many of the issues were described in exaggerated form > > Exaggerated in which sense? In the sense of representing various aspects of the current flow as abysmally inadequate, and the proposed solutions as no less than a panacea. > > I don't like that, mainly because text editing facilities of a browser > > are vastly inferior to what I'm used to expect from Emacs. > > I understand. That's why I want to figure out whether we can add changes > to GitLab, so (almost) everything also can be done outside the > webbrowser, and from emacs. Or maybe build something like the debbugs > package for emacs. Personally, I think an Emacs client is almost a must, if we want to consider something like GitLab seriously. > > Discussing a bug report or a patch in a browser is thus inefficient > > and quite frustrating, especially when advanced text editing and > > processing is needed. A browser also takes me a step further from the > > source code (you don't suggest that I use File->Open of the browser to > > browse the code, right?). > > Well, mention you mention a commit hash in your comments, the hash > becomes clickable 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. > 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. > 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. Besides, tricky control commands will give you that with any tool. > 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. > Yes, I tried to stress the importance of email too. I regret to hear the > email interface of GitLab didn't work for you. I'll have a look whether > I can suggest changes to make the "litter" configurable. But besides > from that, are there any other annoyances you've encountered so far? 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. > > 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. > > GitLab shouldn't try to force you in some organisation structure We'll need to explore this more, I think. It was my impression that many defaults there were configured for a certain hierarchical organization of the team, which is not what we have here.