Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@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.

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