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 14:16:30 +0300 Message-ID: <3b8e2195-07c0-a240-6164-8d34bcca344f@yandex.ru> 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> 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="20708"; 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: monnier@iro.umontreal.ca, agrambot@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii , Toon Claes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 13:19:03 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 1hP3YM-0005D6-I4 for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 13:19:02 +0200 Original-Received: from localhost ([127.0.0.1]:41404 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP3YL-0008Pl-Fz for ged-emacs-devel@m.gmane.org; Fri, 10 May 2019 07:19:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP3W1-0006xM-44 for emacs-devel@gnu.org; Fri, 10 May 2019 07:16:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP3Vz-0001CF-R3 for emacs-devel@gnu.org; Fri, 10 May 2019 07:16:37 -0400 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:38780) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hP3Vz-0001BJ-Kn; Fri, 10 May 2019 07:16:35 -0400 Original-Received: by mail-wm1-x329.google.com with SMTP id f2so7102336wmj.3; Fri, 10 May 2019 04:16:35 -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=HuxK3ohsrj/uUTKz8iVhonXhuw7mYgExZmcqPRRI0P8=; b=JQNfPOzaX6x6YtMXYwyDUdMdlV8sMjsNYVUwLlpW/8Lxgtdy4K3Ug3bTEInm+s7ljR s7Zy+5s0TmLb5vi2NyVJAHqn2rJ1bnwLNh9pf1xRn5PvjNF7kg/CFKLYm+Tx9xlfnlMT o6O2BS6JuHD/jOlpYjIShrmZfZevcasZyGVlvlGuvdDtUEEAcsjYMLfucH47NKQouavo hUpwdrnq3fcxGa7kxhhsCgFg3AhEDiYddpwoFQncktGADcWxoJ2g2fNWJTvy5OZD5N7W J37jjtqsHw6O1o8ayQv0En1EG794rNSX5vgtaxeWIp2bnZUBPN6Dn+8ANmrcfIUTDO1q QcNQ== 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=HuxK3ohsrj/uUTKz8iVhonXhuw7mYgExZmcqPRRI0P8=; b=PX+tO+8ONidC/6LBQysO42CS+iwQanYVUX/kcO1HAdNFieISm3oORoGF8LoLJoobD4 fNrv+ARPAd9yTvbuMZVPK5KHJUnN41THgKAGVQXNBrOjmYbnkdAptnJwjCU1rOWkBRvw r5YECt0aR2NUAMgR19xSKnkp0TiIIrxMr8HB/sWnN9/X/8UpIlB5Dpv9qtYDnwD1gIU0 cUaSj7ZaqqI83IGxdELGTD9RJNs5qrHpx7UG5yzTWBMMZ8GjmIHjQkjNeJuW6m5ezk7k iKj4gP5tfC0naxnxm8MB2NsCnp3Q5sJ09q1xvJEf90q36uuasx8iA0lLvFB3HdUFM/Ru dZcw== X-Gm-Message-State: APjAAAU3X2CUFCxXz9z4KWDZn89tKqX8l3RX4evu2/YIHPZAExnhZkEg sxxZbX0iIYRXJkSRbZoS9WU= X-Google-Smtp-Source: APXvYqzzRkKMvPlNmDXkmept9OWmuCgmvTl9gTc5GlKmij0RTaDgR/FuRUXNKY/VBUPEt6+jtB+eQw== X-Received: by 2002:a7b:cb85:: with SMTP id m5mr6847239wmi.75.1557486994443; Fri, 10 May 2019 04:16:34 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id x14sm4219233wmj.3.2019.05.10.04.16.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 May 2019 04:16:32 -0700 (PDT) In-Reply-To: <83k1eyfxls.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::329 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:236362 Archived-At: On 10.05.2019 12:49, Eli Zaretskii wrote: > 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. Like I also described previously, GitLab provides extra features for code reviews, so it's often natural to describe them first (as a sales pitch, so to speak). >> 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. I think you're already expecting the hypothetical person to have debbugs installed and Gnus configured, and view the bug through the debbugs package. Whereas a random user starts with staring at the (very bare-bones) bug report page in the browser. > 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, it's not hard to automate, and switch to it (if you're not worried about it doing something untoward in your Emacs). Most of the time, with smaller patches, you can just read them but still use Emacs to navigate inside the current version of the code, to get a decent understanding. That's my usual workflow, but maybe yours differs. >> 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. 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. >> 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? > 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. >> 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. How's that for an argument? >> 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. If you're saying that we don't change labels of reassign bugs often, how are occasional notifications for these actions a problem? 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). 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. >>> 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.