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: Sat, 27 Apr 2019 04:40:06 +0300 Message-ID: <16b894b3-fde4-02bb-eb64-096fe444c514@yandex.ru> References: <1552789070.5272.1@yandex.ru> <1552791707.5272.2@yandex.ru> <1552793646.5272.3@yandex.ru> <1552821396.21432.0@yandex.ru> <83imwhwf4x.fsf@gnu.org> <837ecvux2q.fsf@gnu.org> <9c7cf558-a2d3-951e-d6e1-31b3ad5900cf@yandex.ru> <1553064994.13109.0@yandex.ru> <831s32t3fn.fsf@gnu.org> <93f38b88-059b-b243-49bf-df61f424fb3f@yandex.ru> <83o94zap79.fsf@gnu.org> <5161ae04-391e-49d8-e942-127c04062c27@yandex.ru> <83sgu6zbfe.fsf@gnu.org> <83imv2z74u.fsf@gnu.org> <6391f225-1d4d-06ae-eef5-9f069ef6878f@yandex.ru> <83sgu5yi5p.fsf@gnu.org> <83d0l9xkbz.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="218159"; 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: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 27 03:40:23 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 1hKCKE-000uYv-Cc for ged-emacs-devel@m.gmane.org; Sat, 27 Apr 2019 03:40:22 +0200 Original-Received: from localhost ([127.0.0.1]:54199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKCKD-0004V7-5I for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2019 21:40:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKCK7-0004Uq-4Q for emacs-devel@gnu.org; Fri, 26 Apr 2019 21:40:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hKCK4-00047H-Dy for emacs-devel@gnu.org; Fri, 26 Apr 2019 21:40:13 -0400 Original-Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]:38183) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hKCK4-00044T-2E; Fri, 26 Apr 2019 21:40:12 -0400 Original-Received: by mail-wm1-x343.google.com with SMTP id w15so6819562wmc.3; Fri, 26 Apr 2019 18:40:11 -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=uI/sqaRhbgvaf9H+lz+mvCneCKAe2W9gAA8pUQgAIPU=; b=WVLAUOCrwQxgsoCbuRDKQi8sNsYarVhVgvtSr5Km1xWDBoVD8wAc7QG/trzH4jIu6u DRedGUwbwAq9D5j5yEFJjELtmXnGtgH8Qb9WcrrXBnKC2S/2PMhUaDwbfsfWbl9CfT87 XsrJ0WD35L+4jt8eSMq8uksqf0SmuV11z9yYwYKD/W4aqbXTI9v1KLo9LnI7HE2RAvuo VOyHgey8f51IHyuIFCGvUWlEbQYMvbyW5MCpxmRe6Qltr4wEHxzooViLXRksLD4dAPya 7JluuVGlnw5wMM+biiLmQfRXxdOf8ZnN2+8qQQdrg4rETLI56pGuyMgu4HoE6FDg2CZ/ s1mQ== 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=uI/sqaRhbgvaf9H+lz+mvCneCKAe2W9gAA8pUQgAIPU=; b=OD73LclwSJT6HEjmavALaN/Zcx2vv7nM9AX5Roq05vCOZmhr9bg02/ofdu2ArgYiCl cEF4GY7z5jxUyteN13bak9t6D1+O4lr8daS7GJrJAmaQi18VPHa5ewOkR+4HUy6BGibA QhbZBw+LmmfUKFDicE2Ol9IvuYNBzgKtqsAwJiBAfldO8sUG4Xh3bvVox94Wm30xMHPZ M1qYu7+yqRmpBPbjttQuLnLifJrC7YuDcU5ktX2zRoNKgNaW58I3/JyzGrTlKaY5g/mx JNDbJw0V39WqueWEMbg3y189C9Krv2Ia+iRX+sFbGZi6jN7UMVJTMm+kWvq64CjMT68X pY5g== X-Gm-Message-State: APjAAAUv6av0XnkLfhhTKi4jfL35bL7r4Pq/uEsw/0e498Bq1FHw9lyL xWOT0fJ4As46FOH6MEyRQLyeSXGC X-Google-Smtp-Source: APXvYqxLLWzdHrACr2qHpYTKVzlYXmF+JHflr1pQNdLMsUNVeO6Xk1QRf6Ebm+nAS3sPbLKhDcf2zA== X-Received: by 2002:a7b:c38c:: with SMTP id s12mr3475379wmj.136.1556329209462; Fri, 26 Apr 2019 18:40:09 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id y127sm28511406wmg.29.2019.04.26.18.40.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 18:40:08 -0700 (PDT) In-Reply-To: <83d0l9xkbz.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::343 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:235973 Archived-At: On 26.04.2019 11:05, Eli Zaretskii wrote: > Maybe people are not aware how close we are to that goal. Or maybe > they didn't try to go out of the area of their immediate expertise for > fear of something that shouldn't frighten them. Repeated calls for help with triage on emacs-devel could do the trick, then. Maybe. >> So, okay, every step but the first (receiving the email?). > > No, all of the steps. Even the result of the triage is an email > message. And the triage itself has nothing to do with the tracker, it > requires understanding the report, some knowledge of Emacs, and common > sense. It can also include asking the OP some clarifying questions. Again: - Searching the bug tracker for duplicates. - Tagging the bug. - Changing priority. - Closing it as a duplicate, maybe. All of these require interacting with Debbugs. Usually through the control server. >> Every one of these actions is noticeably slower here than what I'm used >> to in other projects. More error-prone, too. > > I don't understand why. It's mostly writing text, which > should be the same speed everywhere. Because most of the time I can just click a button instead of having to write an essay. Or, in the case of search, it's usually more intuitive and, most importantly, *faster*. >> "Manage". I mean that not trying to reproduce is the norm: the >> volunteers look for similar bug reports, categorize them and forward to >> relevant teams. > > I fail to see how this would be useful. It saves time for other people. For instance, I would be delighted to be able to see the list of bugs that someone at some point thought I could take care of best (as, say, tagged me as their owner). The ones that are categorized wrongly, I could forward to someone else. >> I rather meant assigning to an appropriate subsystem or subpackage > > That's usually a very large portion of figuring out the reason for the > bug. Someone who got that far should just go on and describe the > reasons themselves. They don't have to find out the reason with 100% certainty. A lot of the time, the general area of responsibility is pretty obvious (Ruby support? tag with 'ruby'!) >> I'd have to search some files inside the Emacs repo (which could be >> outdated or don't have the full info), Cc somebody if I find them, and >> write a full, grammatically correct sentence (or more) to bring it to >> the owner's attention. > > Any bug tracker will require all of that, with the possible exception > of the last part. If there was a pre-defined list of subsystems, bugs could be forwarded to those, with the forwarder not having to remember the exact people responsible. And then either the bug tracker has the necessary emails (and all people in the subgroup get notified), or each individual developer could once in a while do a search for tags within their area of responsibility. Could be a combination of both. > And at least for me, a sentence or two explaining > why you think the bug is in my backyard is much better than just a > message "assigned to you" with no explanation whatsoever. YMMV, of > course. Sometimes it's very obvious. But if the person doing the triage has something meaningful to add to the bug report, then yes, by all means. I think having all bugs assigned but without a personal message is still better than not having all bugs assigned. You could always ask if you think they made the wrong choice. > Not sure why this is important: IME, such messages are in many cases > of little help in investigating the issue and finding its causes. Again: knowing that the bug is still reproducible and knowing it still bothers people. Is that not useful in your book? Also, users describe their workarounds, offer their half-baked solutions, and even sometimes end up offering patches. This, again, IME happens more often in my projects that use the GitHub issue tracker. >> Indeed, we can't just get a "better Debbugs". Someone would have to >> sacrifice something, at least a little. > > More importantly, you get fed features and issues you never asked for, > that you need to decide whether you want in the first place. Yes, you'll need to decide. Just try to weigh that against other people *finally* getting to use said features. >> That's not the point. I know how to search Debbugs (it's annoying and >> slow, but I get the results). A lot of our users do not. > > If the advice is readily available and discoverable, it might help > others. To really be discoverable it would need to be easy to use from the web interface. Like them or not, they are popular, and they're here to stay. >> We would have a separate dedicated place and workflow for handling code >> reviews. > > That's not how issue-tracking systems I'm familiar with work. They > let you have a single locus where the issue is described, discussed, > suggested patches are linked to, and the changeset(s) committed to > resolve can be easily called up and reviewed. Separate place for > patch review sounds like a step back to me, as currently we have them > in the same place as the bug reports. In short: MR provide the same features as issues, but more. You can still lead discussions and post textual patches, but they also include a specialized review-and-merge UI. >> I've seen it, and I'll let Toon answer first. Let's not spread that >> detailed discussion over many subthreads. > > So I won't respond to above comments about merge requests, because > that's exactly the stuff of the other subthread. Do you want to open a new thread for that? At this point we're drowning in nested subthreads, and it's not so great to read in my email client. >> Bug handling is "easier" than doing code reviews in a lot of respects. > > IME, it's actually the other way around, assuming that "bug handling" > includes all the way until the bug's root causes are revealed and > understood. By "easier", I mean technically simpler, in terms of UI features involved. So the said features would be easier to re-implement in a dedicated Emacs-based client.