[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.
Again:
- 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
course.
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
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.
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.
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
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.
- Re: [RFE] Migration to gitlab, (continued)
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/25
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/25
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/25
- Re: [RFE] Migration to gitlab, Michael Albinus, 2019/04/26
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/26
- Re: [RFE] Migration to gitlab, Michael Albinus, 2019/04/26
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/26
- Re: [RFE] Migration to gitlab,
Dmitry Gutov <=
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/27
- Re: [RFE] Migration to gitlab, Ricardo Wurmus, 2019/04/26
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/26
Re: [RFE] Migration to gitlab, Toon Claes, 2019/04/23