Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

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.