[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Wed, 15 May 2019 05:04:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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

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.

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

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

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

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]