[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: Sat, 27 Apr 2019 04:40:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.

So, okay, every step but the first (receiving the email?).

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.


- Searching the bug tracker for duplicates.
- Tagging the bug.
- Changing priority.
- Closing it as a duplicate, maybe.

All of these require interacting with Debbugs. Usually through the control server.

Every one of these actions is noticeably slower here than what I'm used
to in other projects. More error-prone, too.

<Shrug> 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.

Or, in the case of search, it's usually more intuitive and, most importantly, *faster*.

"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.

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). The ones that are categorized wrongly, I could forward to someone else.

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'!)

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.

And at least for me, a sentence or two explaining
why you think the bug is in my backyard is much better than just a
message "assigned to you" with no explanation whatsoever.  YMMV, of

Sometimes it's very obvious. But if the person doing the triage has something meaningful to add to the bug report, then yes, by all means.

I think having all bugs assigned but without a personal message is still better than not having all bugs assigned. You could always ask if you think they made the wrong choice.

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?

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.

Indeed, we can't just get a "better Debbugs". Someone would have to
sacrifice something, at least a little.

More importantly, you get fed features and issues you never asked for,
that you need to decide whether you want in the first place.

Yes, you'll need to decide. Just try to weigh that against other people *finally* getting to use said features.

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.

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.

We would have a separate dedicated place and workflow for handling code

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.

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? At this point we're drowning in nested subthreads, and it's not so great to read in my email client.

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.

reply via email to

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