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: Thu, 25 Apr 2019 22:54:58 +0300 Message-ID: <83sgu5yi5p.fsf@gnu.org> 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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="31579"; mail-complaints-to="usenet@blaine.gmane.org" Cc: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 25 21:56:06 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 1hJkTW-00088C-HQ for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 21:56:06 +0200 Original-Received: from localhost ([127.0.0.1]:34371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJkTV-0003cN-ID for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 15:56:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJkSm-0003b2-Nd for emacs-devel@gnu.org; Thu, 25 Apr 2019 15:55:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJkSl-0007F9-2b; Thu, 25 Apr 2019 15:55:19 -0400 Original-Received: from [176.228.60.248] (port=4693 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hJkSk-0005jV-8h; Thu, 25 Apr 2019 15:55:18 -0400 In-reply-to: <6391f225-1d4d-06ae-eef5-9f069ef6878f@yandex.ru> (message from Dmitry Gutov on Thu, 25 Apr 2019 18:01:19 +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:235934 Archived-At: > Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 25 Apr 2019 18:01:19 +0300 > > On 25.04.2019 13:55, Eli Zaretskii wrote: > > >>> When close to 80% of bugs and patches posted to the issue tracker will > >>> wait less than a week before they get responded in some meaningful way > >>> (excluding a mere acknowledge of seeing the report), and not > >>> necessarily by yours truly. Sounds good? > >> > >> You mean only after that we can consider changing workflows? > > > > That's the criterion I propose, yes. > > I don't understand. Either you're saying that we simply wait and carry > on our workflows in exactly the same way until the aforementioned 80% > happens. Not "exactly the same", but without "significant changes", yes. > Which is a perspective I'm not particularly hopeful about. Why? You think it's a tough criterion to meet? I actually think the bar is quite low. How many new bugs get reported each day? 2? 5? How hard is it to triage 80% of that, even given the relatively small number of people who currently do that? > > I see no reason not to triage the bugs quickly, even if a large > > portion of the bugs gets triaged into the "unassigned" category. > > Triage is not a complex process. > > It's a relatively simple, but repetitive process that requires > interacting with the bug tracker on every step. Does it? The bugs get mailed to you if you subscribe, so no interaction is needed, until you send a short email after you finish the triage. I only ever need to interact with the tracker when looking up an old bug report, or searching for related issues. The initial handling of a new bug almost never needs any interaction. > Debbugs aside, not every project has "try to reproduce" as one of the > steps in bug triage. It isn't a requirement. If you are able to triage or fix without reproducing, no one will object. > And trying to do that would be more time-consuming, as well as > require one to familiarize themselves with features of Emacs they > have no experience/interest in. It's harder, yes. But that's the job, and it must be done. And it becomes easier with time, as you become familiar with more and more areas. > On the other hand, the current triage notes mention no categorization > step What do you mean by categorization? It does include determining the priority. > or assignment to responsible parties. It does, AFAICT: 5. Who should be the owner? > Third, since admin/notes/bug-triage is inside admin/, we apparently do > not expect drive-by contributors in participate in the triage process. No, we don't. But no one will object to them doing so. No one needs a permission to start responding to bug reports, everybody is welcome. > Finally, in my own projects which are fairly mature, I sometimes fail to > respond to bug reports. The users themselves find existing bug reports > and comment to confirm that yes, the bug still exists and remains a > problem. Triage success! We have this on the bug list as well: people confirm that they see a problem reported by someone else. But that's just the beginning of a triage, it just means the bug is not "not reproducible". > That also works to confirm that a bug should be made a priority (old > report, users still commenting on it). Not necessarily. Priority of a bug doesn't necessarily become higher with time, it could actually become low in some cases (people manage to get by). > I remember certain people on this mailing list complaining about > duplicates in the bug tracker (and users failing to do the search). > Well, get a bug tracker with a user friendlier interface (visibility, > searchability, etc), and the users will do more work for you. All else being equal, sure. But there isn't such a beast, TANSTAAFL. And I'm not really sure searching debbugs is such a black art. perhaps Noam and Glenn could share their experience and methods, and we will all become better searchers. > >> I honestly do not know what improvement is possible with our current > >> resources. The only way I know of improving the situation is to try, and > >> try, to attract new contributors. And that can happen if we use newer > >> tools which increase visibility into our development process, and makes > >> it more approachable for a new contributor. > > > > The situation actually improves quite steadily. Just slowly. > > The improvement is to be expected, given your more conservative approach > to Emacs development than the previous maintainer did. I'm talking about the situation with bug triage and patch review. Whatever my approach is, it cannot affect those, that's entirely up to the people who volunteer their time for doing that. I'm glad that the situation with this is slowly improving. > But in short, bug reports to in Debbugs, patch submissions to into > GitLab (and also Debbugs sometimes, though we could automate some > process to move them over to GitLab from there). So we are supposed to have 2 sites/UIs open when dealing with a bug report to which someone suggested a solution? Is that an improvement? > During that time you would evaluate how easy it is to review patches in > GitLab (maybe using some Emacs-based client, maybe over email), as well > as simply leave comments there. Please read my notes about the main issues I see with Gitlab: efficient handling of bugs for which there's no patch yet is much more important than efficient review of patches, primarily because we have much more bug reports than patches on any given day. A solution that makes patch review easier, but does nothing to improve bug handling is unlikely to get my vote, because I think this is backwards: we should be solving the most important bottlenecks first.