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: Wed, 15 May 2019 05:04:21 +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> <83d0l9xkbz.fsf@gnu.org> <16b894b3-fde4-02bb-eb64-096fe444c514@yandex.ru> <834l6jwzpx.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="164606"; 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, hi-angel@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 15 04:04:45 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 1hQjHh-000gjb-8L for ged-emacs-devel@m.gmane.org; Wed, 15 May 2019 04:04:45 +0200 Original-Received: from localhost ([127.0.0.1]:57726 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQjHg-0003XN-1v for ged-emacs-devel@m.gmane.org; Tue, 14 May 2019 22:04:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35748) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hQjHY-0003X5-3d for emacs-devel@gnu.org; Tue, 14 May 2019 22:04:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hQjHW-00019h-5U for emacs-devel@gnu.org; Tue, 14 May 2019 22:04:35 -0400 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]:43146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hQjHT-00012j-SG; Tue, 14 May 2019 22:04:33 -0400 Original-Received: by mail-lj1-x22c.google.com with SMTP id z5so983220lji.10; Tue, 14 May 2019 19:04:27 -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=1FjqdWtu8E8KSkBnYZQRHgSM1a5v14nXF6C4gLGkXM8=; b=Ht55Uea8wyO/w01L3AV7BiQ8+K9AmpKK0H0ULROXJpLhLwL3ywC3plsjHesOyeTyU1 L0PYm5defuGMlzwyXKBKcwEr9PTizWGHmxyQj8IPgkbmMU8pdZXoAGBg7dFTOn8/cyd1 4sea29PuaOsQgo0AZFaG4LgoiuEPH72roSyw5gj+5NWEQCWsWJk1mJ+ecyGLkVWo648q SOQ0kGV0Di/ClkcgblaNvE8KSuyQqgamRmIzlZKyra2uEsYybWtsk/bVOVc6ipx7b8+w INM0SWXBn6Dd1h2ixCG8MQISCni7K3AyCrlomIYZXvJGKWGQMcDvDe1sTLsXZukNemPA LHBg== 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=1FjqdWtu8E8KSkBnYZQRHgSM1a5v14nXF6C4gLGkXM8=; b=MfBehhiogP25PzyM1CRbw2VASegKDyzS7mRrpASLItJ+FZ07LfxvzgKHOefdZ0kvGa IHWdElNj/Qh736VvlhNcKmELhpjkqNdeQZeYS4TrtTa+6gXdwU7lnzyhzLJ1B2RzMzKN YNGbED12liDxvsKAljcCOhK09Ep2wTcIR9HvzbKQ/CR+UWZ1IHotEP62zDp1vXNQYR61 VeaCXmCCwod6fvCeYJ2NPP81kYUmcytpMZz4WH64RYWXdx8xI6U9tVZO5NufbYDHX/6R fcpppwIIKfbj1aKpTcxl2etvrXch+JplxQVOH3bCwD97j0IIHUN+2bIt4AE9BVIgDIaz 1CUA== X-Gm-Message-State: APjAAAWXiCCo611GGeOlmA73utW9TF49l20EiWt4bziWI2m/RWhStHej 5IaH8eX3+V1/vAQMwwm/c2c= X-Google-Smtp-Source: APXvYqyxXHNcD3hqi5Eb/Y4yvsL4XBw2/4nEJ8DTfO036yfT+Km6SwyGLmAFSX+KqbEtWna/EQ7KvA== X-Received: by 2002:a2e:63d1:: with SMTP id s78mr19460417lje.166.1557885865545; Tue, 14 May 2019 19:04:25 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id h123sm102672lfe.65.2019.05.14.19.04.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 May 2019 19:04:24 -0700 (PDT) In-Reply-To: <834l6jwzpx.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::22c 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:236530 Archived-At: On 27.04.2019 12:43, Eli Zaretskii wrote: >> Repeated calls for help with triage on emacs-devel could do the trick, >> then. Maybe. > > Then please consider this one of them. *shrug* I look at the recent reports, and most are far from my interests. Lots of ones involving Tramp, Gnus, emailing and eww recently. I would know who to forward them to, though. >> - Searching the bug tracker for duplicates. > > Not required, just a nice bonus. It could be helpful to save time, or find other bug reports related to the subject. We very rarely do that (or at least I) in part because the available tools don't make that too easy. A quick (and maybe automated) search for duplicates would also be of help if we start getting more bug reports, which is a "danger" if we switch to a more user-accessible bug tracker. >> - Tagging the bug. >> - Changing priority. >> - Closing it as a duplicate, maybe. > > All done in a single step after triage is completed. (And if the bug > is a duplicate, it should be merged, not closed.) One still has to know or remember the syntax. > The main effort in the triage is something entirely unrelated to the > tracker. It has to do with understanding the report, perhaps > reproducing the issue, and then deciding what is the next step for its > processing. It doesn't all have to be done by the same person, however. > You somehow exaggerate the importance of interaction with > the bug tracker, and entirely omit the main part of the activity. > That doesn't seem to be a useful way of discussing this. You seem to insist that the amount of effort I *could* spend on bugs that aren't interesting to me is strictly insufficient. Okay. >> Because most of the time I can just click a button instead of having to >> write an essay. > > "Essay" being those couple of sentences that describe your take of the > issue? Another exaggeration, I'd say. Can we call it poetic wording? To get the emotion across. Of how the difference often feels. > Clicking a button loses information, because things you learned during > the triage are not communicated to the next person who will handle > it. Nobody is stopping me/you from adding that information in a comment as well. But when I just need to reopen a bug, or add a "fixed in" header, or so on, there's no extra information to be added. > Having the button to click invites people to go the easy way and > lose that information. It reminds me the GUI of some VCS I used to > use years ago, which allowed people to make a commit with an empty log > message. Guess how many of them actually wrote a log message. We can still write nonsense in Git logs. But we choose not to. > How much time does it take to write a couple of sentences? And doing > so will in many cases prompt you to have another look at the problem, > perhaps seeing additional, sometimes entirely new aspects of it. It > is a well-known trivium that explaining something to someone else > causes you to better understand the issue you are describing. It's a > net win, even though it will use up slightly more of your time. Or I could use the saved time and brain energy to work on a new feature. >>>> "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. > > Not IME. Would save time for me. >> 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). > > This is only relevant for issues created before you took charge. Nope. Even now I would very much like to see the lists of bug I fixed, ones I triaged but then got sidetracked, and ones I missed because of bad naming, or because I accidentally marked an email as read but then forgot to reply. > The > ones created after that arrive to you one by one; how many seconds > does it take for you to understand whether an issue is in your area or > not? Usually, not a lot. Though there are exceptions. That's largely irrelevant, though. See above. >> 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'!) > > Your examples are of the kind that is quite rare in Emacs maintenance. > Most of the bug reports are nowhere near being so clearly classified. And yet, I'm fairly sure about the Gnus/Tramp/EWW bug reports I'm seeing lately. > Even a problem with Ruby support could be due to something much > deeper, like syntax or font-lock or even regular expressions. That is > why I said that figuring out the subsystem is a large part of finding > the cause. It's no trouble if the original assignee finds that the problem is in another subsystem and forwards it to someone else later. > It could be that a quick-and-dirty classification of this kind is of > some help, assuming the person who is responsible for Ruby is active > enough to quickly take a look and reassign to someone else if needed. > (But if he/she is active, then why didn't they respond in the first > place?) People have lives, and this kind of system would allow certain feature owners to unsubscribe from all bugs, and yet handle bugs they are equipped to handle. That could keep some otherwise busy people semi-active in Emacs development. > However, even under this assumption, what do you do with > reports related to code in simple.el or in faces.el or in frame.el? > Emacs is an old and very stable project, so a large portion of > reported issues are not simple bugs in a recent commit. Forward to "core", or something. I would say that these kind of bugs are a minority, though. >> I think having all bugs assigned but without a personal message is still >> better than not having all bugs assigned. > > I don't see how that would be better. People who are motivated to > work on bugs read the bug list anyway, and people who are less > motivated are known not to respond to direct emails for weeks and > months on end. I think there's a place for the middle ground. Especially if there's suddenly a jump in Emacs's popularity, and the flow of bug reports increases significantly. > We are not an enterprise where a manager can cause > subordinates to get their act together by showing a list of assigned > but unhandled issues, so having a list of many unhandled issues > assigned to someone specific is of no particular importance for > resolving the issues, no better than having a list of unhandled issues > disregarding any assignments. That is also true. Even having an efficient triage strategy won't make up for the lack of people dealing with the actual bugs. >>> 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? > > Very little, and in some cases not at all. Okay then. I have found it helpful many times. >> 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. > > "More often" than what? Than for packages inside Emacs core that I maintain. > And why do you think the frequency of that is > related to the issue tracker being used? Because one bug tracker is easy for an average user to interact with, and another is not. > Could it perhaps be related > to the relative complexity of the projects being compared? Unlikely. I'm comparing third-party Emacs packages here with the core ones. So it's the same userbase and the effect is pretty apparent across packages with different complexities. As one example, js-mode probably has a lot more actual users than js2-mode, but there are significantly more bug reports in the latter's bug tracker, and a lot of them are about issues present in both packages (e.g. certain indentation problems, or support for new language features). It even comes to this: for most bug reports regarding indentation in js2-mode I usually reply to report them to js-mode instead (because js2-mode delegates to js-mode for indentation), and only a very small fraction of users actually file said reports with 'M-x report-emacs-bug'. >>> 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. > > The entire contents of the Emacs repository is reachable from a > browser, so this is not an issue. Reachability doesn't equate to ease of use. >> At this point we're drowning in nested subthreads > > We are? I see only 2 subthreads: this one, and that other one, where > my message didn't see any responses that discuss my concerns. I can just say that it wasn't trivial to find this exact email and finally respond to it. Not sure I can describe the alternative well, but when discussions are led in issues in GitHub or GitLab, there's no threading, each discussion is displayed as flat in the UI. And that often makes them more focused. If there's a branch that deserves additional discussion, a new issues can be filed and linked to from the original one. So for the present discussions I could create several interlinked issues: - Benefits/drawbacks of the switch. - The details of the new workflow, what will have to change. - The actual progress of the transition. >>>> 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. > > If you say so. My point was that having those features is much more > important than having features that facilitate patch review. No argument from me here.