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: Sat, 27 Apr 2019 12:43:06 +0300 Message-ID: <834l6jwzpx.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> <83sgu5yi5p.fsf@gnu.org> <83d0l9xkbz.fsf@gnu.org> <16b894b3-fde4-02bb-eb64-096fe444c514@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71986"; mail-complaints-to="usenet@blaine.gmane.org" Cc: theophilusx@gmail.com, hi-angel@yandex.ru, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 27 11:44:13 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 1hKJsR-000IdJ-AX for ged-emacs-devel@m.gmane.org; Sat, 27 Apr 2019 11:44:11 +0200 Original-Received: from localhost ([127.0.0.1]:57969 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKJsQ-0008AM-BW for ged-emacs-devel@m.gmane.org; Sat, 27 Apr 2019 05:44:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKJri-00089p-5x for emacs-devel@gnu.org; Sat, 27 Apr 2019 05:43:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hKJrh-0001eM-Lu; Sat, 27 Apr 2019 05:43:25 -0400 Original-Received: from [176.228.60.248] (port=1557 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hKJre-0003QY-Un; Sat, 27 Apr 2019 05:43:23 -0400 In-reply-to: <16b894b3-fde4-02bb-eb64-096fe444c514@yandex.ru> (message from Dmitry Gutov on Sat, 27 Apr 2019 04:40:06 +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:235983 Archived-At: > From: Dmitry Gutov > Date: Sat, 27 Apr 2019 04:40:06 +0300 > Cc: theophilusx@gmail.com, emacs-devel@gnu.org, hi-angel@yandex.ru > > 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. Then please consider this one of them. > > 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. Not required, just a nice bonus. > - 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.) 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. 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. > >> 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. "Essay" being those couple of sentences that describe your take of the issue? Another exaggeration, I'd say. Clicking a button loses information, because things you learned during the triage are not communicated to the next person who will handle it. 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. > Or, in the case of search, it's usually more intuitive and, most > importantly, *faster*. 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. > >> "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. > 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. 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? > >> 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'!) 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. 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 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?) 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. > >> 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. We don't have subgroups. We do have a kind of ad-hoc subsystem list, see admin/MAINTAINERS. CC'ing the relevant person should be good enough, as we don't have much overlap anyway. I'd welcome extensions of this and perhaps making debbugs aware of that, feel free to work on that. But I think these are very minor aspects, certainly compared to the larger issues we have now. > 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. 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. > > 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. > 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? And why do you think the frequency of that is related to the issue tracker being used? Could it perhaps be related to the relative complexity of the projects being compared? > > 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. > >> 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. You've changed the subject. The specific issue here was that using 2 separate places, one for bugs and another for patches, is a step backward. It was your proposal to use 2 separate places. If you now say we could do it in one place, then please describe how this will work with MR being the vehicle. What would be the workflow, when there's no patch to start an issue? > >> 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? No need, just respond to that other thread, where I described my main concerns with the Gitlab proposal. > 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. > >> 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.