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: Thu, 25 Apr 2019 18:01:19 +0300 Message-ID: <6391f225-1d4d-06ae-eef5-9f069ef6878f@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> 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="54140"; 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 Thu Apr 25 17:01:38 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 1hJfsX-000Dv3-M3 for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 17:01:37 +0200 Original-Received: from localhost ([127.0.0.1]:59011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJfsV-0004OL-S6 for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 11:01:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJfsM-0004Mg-NR for emacs-devel@gnu.org; Thu, 25 Apr 2019 11:01:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJfsL-0003JW-91 for emacs-devel@gnu.org; Thu, 25 Apr 2019 11:01:26 -0400 Original-Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]:51855) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJfsL-0003Iz-1S; Thu, 25 Apr 2019 11:01:25 -0400 Original-Received: by mail-wm1-x342.google.com with SMTP id 4so9707728wmf.1; Thu, 25 Apr 2019 08:01:24 -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=Z+6q7CN1dEsX1Gcz2Vd/bBmKUgIgWkYv4ujDzhs15S0=; b=ixPCD85Eemj/yJUKH3GmO6AXJNEomNU4KetP0z6WSK/hedM6UXRAgp6IH9gzjMqojh c/QPrkviHyyVpiF2mhRQEntsp6NFCv/66KoVVjS/ksiuG2UVpQjPYIXEiJZDNeRcLWsg iuisMHNVH/aLl8lXcrBs+yKYsGa3bawDCf+eavbZsq1JTD/wBMYcqidd0vohzlveVTI5 2QurUmxToUrxpYxQHsVyy1+RNoIMntSK8vPbeqd7f80YpkvK01vURqclqQHPa5IN7lio om3/EgkbOO3Q6lCl9eQ3Brumh7c0JQT0crZf2safU+63FxnlvGnnJBEs66/OTUzoBgyq AnYw== 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=Z+6q7CN1dEsX1Gcz2Vd/bBmKUgIgWkYv4ujDzhs15S0=; b=oZTZYfnOztmo1JZtXrjFzYtMlxWkjI5v2bDniSuNuKybdmhDhKV+jZi8vH62BVlKm+ e/E5t0dpjF35sdjm43XIfsX0WD0W77EwB1ibZrh72xBSRZyWGpfXNER1RY1V1fdT3LM7 MRCVkB9IhtHVvpq+0Lm3KyEe/omrek/hIz/SbmYc8+g1oz/cvhOhIVbXtBceo+nShQDQ jHu7NGZsArtbrM7yDjbmAQv1xLAtnxDJgaDubAu+FP9G3AY0Q2/I/JLJKmby3+wIMaFo YMl8m44DuU3MVvD/yTy2BdTkuTB8CCOi5RiFqc8BNVjGPPHBsPHY6tB3pixeh4yppZPB yTaQ== X-Gm-Message-State: APjAAAXOOoi6aUEfXFN3lNfQ7O3kN4JLqizpHFTzQrA+D9pgocEHjoYF hgP6v+VuB9MzG7r1rBT2jM46XKq1 X-Google-Smtp-Source: APXvYqxNMIOCDPl+XNzaKZI2ENYTWxZIt9bNF6nS4dkeGBvuUkxDRFTGtWDtxLqyQ9WtPPZOFvde6A== X-Received: by 2002:a1c:4102:: with SMTP id o2mr3668841wma.91.1556204483784; Thu, 25 Apr 2019 08:01:23 -0700 (PDT) Original-Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id t24sm20433804wmi.10.2019.04.25.08.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 08:01:21 -0700 (PDT) In-Reply-To: <83imv2z74u.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::342 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:235927 Archived-At: 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. Which is a perspective I'm not particularly hopeful about. OR We discuss the options, and we're open to making some changes (minor or major), as long as we agree that they are for the common good. We can also test-drive any new changes in advance before committing to them. I might be misunderstanding your use of the word "criterion", though. >> A lot of big, popular projects (and especially those) have huge >> numbers of untriaged bugs because it's simply a function of a >> project's popularity. > > 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. Which is basically impossible to do when one severely dislikes the current bug tracker. Debbugs aside, not every project has "try to reproduce" as one of the steps in bug triage. The bigger ones don't AFAIK. 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. On the other hand, the current triage notes mention no categorization step, or assignment to responsible parties. Which would be helpful in its own right. Third, since admin/notes/bug-triage is inside admin/, we apparently do not expect drive-by contributors in participate in the triage process. Even though the steps are relatively simple, and one does not have to possess much in-depth knowledge to perform it. 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! That also works to confirm that a bug should be made a priority (old report, users still commenting on it). 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. >> 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. But it's no guarantee that the ratio is ever going to reach 100%, or even 80%, and stay there. >> If you look back at the list I wrote, only the step of Migration off >> Debbugs (the last one) should be considered distant. > > So you propose that we use debbugs and Gitlab concurrently? How's > that supposed to work? I think we have a sub-thread in this discussion that's better suited for this question. 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). I'm hoping this can be a step to easy the transition to using GitLab full-time, but it can continue for a while (and never end, basically). 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.