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, 26 Apr 2019 02:16:34 +0300 Message-ID: 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> 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="150403"; 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 Fri Apr 26 01:32: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 1hJnqo-000d1F-PZ for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2019 01:32:23 +0200 Original-Received: from localhost ([127.0.0.1]:36619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJnqn-0001gi-Pi for ged-emacs-devel@m.gmane.org; Thu, 25 Apr 2019 19:32:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJnpk-0001CD-Sr for emacs-devel@gnu.org; Thu, 25 Apr 2019 19:31:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJnbc-0006GF-Ry for emacs-devel@gnu.org; Thu, 25 Apr 2019 19:16:42 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:36907) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJnbc-0006Cx-IO; Thu, 25 Apr 2019 19:16:40 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id r6so1705469wrm.4; Thu, 25 Apr 2019 16:16:39 -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=HPiV1RjDy6hbm47EWAeu3tC/Zjv/ZIenqIAz+PVe2L0=; b=qeQ0om7lnAko0ryEpQkDCuYE4ilBB1lqwennIv/6HGW8cEzETZOgMoGLmITFnIU73F OI5M0NL3Wi6QtFv4UkULlSiCMaA+QNEBWpaDGXdQ2McEodM1h70KuOQQpKMbwD77omeC ky/WKx+QcYKWzSyNwZsgc9Jw8midquG4g0pQ+S+EUaMW2+sDp/oVAHjEtKqbDgjnVrnG /y+Ltq1hJeEuGuk+QiAZ72M525sQUzLLvfHLU1i057bN08w7jiKlM9Sm+kJ94KMAgXvz 1UHWyCveTnKo72IiqI1YHZC3QpOzxJuWDlyv4fTVT5qJlZn+lTjFA6sbYqJ3Iu7/T8+B HTXQ== 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=HPiV1RjDy6hbm47EWAeu3tC/Zjv/ZIenqIAz+PVe2L0=; b=F1a9WKzyDa3OASE3cYh33WNIUbMoe9cTBgqAR83i028273cVll1euusxMnNw3BbfQm F8dbb0dA36/CsopuVv3HbGCJGuqLj/XrnUjXISRWZVD+Xr7tyJI+7JHDu7dQyWavpqok npXKPXVkjvurwcO1hce0FQOjnZzuPCK4cu+aZbjU5yc2hPTKMq/RyQZ2Tjtt4kw43ZrL LReGEnsbNVeZTuK/kyUFnX4RMSYnHIyzOMchHeQn6jMSW5QrTUkgkumIm3Y2ekeQTlFK wSadts/tDGOB8l96jj040daHjRrsvVeDh8UcOsrHQzhdZOakG6hw3oRdO2xpPzdFIxD+ +xdQ== X-Gm-Message-State: APjAAAUYZ9fYiwQziMnJLqwMHpG7SOBtvJnjPuvu7luCxQzGPA40l0vW D/5ni40S9Fu4kvJZyh2rUWtNJn+D X-Google-Smtp-Source: APXvYqyQrzB2cK0Cbe1OJWw9UMtEpUbET/wnWKdgzQIB6oIu4bIizFPOmc/MoP7RQpwH49mE5Gd7hw== X-Received: by 2002:adf:f2c5:: with SMTP id d5mr10031179wrp.293.1556234198205; Thu, 25 Apr 2019 16:16:38 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id r9sm28762182wrv.82.2019.04.25.16.16.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 16:16:36 -0700 (PDT) In-Reply-To: <83sgu5yi5p.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::433 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:235939 Archived-At: On 25.04.2019 22:54, Eli Zaretskii wrote: > Not "exactly the same", but without "significant changes", yes. I see. Probably. (We could discuss the meaning of "significant", but let's not). >> 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 hope we're not talking about my own participation, with the backlog I already have, and, well, Debbugs still being there). On the one hand, you're probably right. On the other, there must be a reason it still hasn't happened yet. >> 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. So, okay, every step but the first (receiving the email?). That changes very little. You need to search, tag, Cc somebody else, maybe. Every one of these actions is noticeably slower here than what I'm used to in other projects. More error-prone, too. >> 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. "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. > 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. To be honest: that's only an enticing prospect if I'm aiming to be an Emacs maintainer. There's not enough free space in my head already. >> On the other hand, the current triage notes mention no categorization >> step > > What do you mean by categorization? It does include determining the > priority. I rather meant assigning to an appropriate subsystem or subpackage (then someone responsible for it can take over). >> or assignment to responsible parties. > > It does, AFAICT: > > 5. Who should be the owner? OK. But to be pedantic, the document only tells me to ask the question, but not what to do with the result. And there's no "owner" field in Debbugs. 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. >> 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. I'm saying you might want to move that information somewhere else. CONTRIBUTE is already long, though. So I don't have a better proposal for the *current* workflow. >> 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. It is, of course, just my experience: but I see that a lot more often in the GitHub bug tracker than over here in Debbugs. An order of magnitude more often. >> 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). It works to confirm the priority when new users keep commenting on old bug reports. >> 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. Indeed, we can't just get a "better Debbugs". Someone would have to sacrifice something, at least a little. We might get close enough, though. > 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. 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. > 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. I'm glad that's happening, then. >> 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? We would have a separate dedicated place and workflow for handling code reviews. Stefan seemed enthusiastic enough about "a system where we can receive contributions via merge requests". The exact improvement would depend on how well the reviewers would be able to take advantage of GitHub's features (the web UI has a lot of them; whatever interface we choose would either have to simplify or reimplement some of them). That is, improvement from your side. The users who don't mind using the web interface will likely benefit the most. And we'll likely see more user attention as a result. > Please read my notes about the main issues I see with Gitlab: I've seen it, and I'll let Toon answer first. Let's not spread that detailed discussion over many subthreads. > 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. Bug handling is "easier" than doing code reviews in a lot of respects. First and foremost, email notifications and responding to reports via email should already work. There are definite advantages to be gained from migrating the bug tracker to GitLab, but we need some trial period, and probably don't want to deal with two bug trackers at once. Adding Merge Requests to our workflow first would force us to work out the kinks in the more difficult parts of the integration, as well as test drive also the same features that bug reports have (commenting through email, searching, tagging, changing status, etc).