Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> From: Dmitry Gutov <address@hidden>
> Date: Sat, 27 Apr 2019 04:40:06 +0300
> Cc: address@hidden, address@hidden, address@hidden
> 
> 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.

Then please consider this one of them.

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

Not required, just a nice bonus.

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

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

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

"Essay" being those couple of sentences that describe your take of the
issue?  Another exaggeration, I'd say.

Clicking a button loses information, because things you learned during
the triage are not communicated to the next person who will handle
it.  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.

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

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.

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

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

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

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

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

We don't have subgroups.  We do have a kind of ad-hoc subsystem list,
see admin/MAINTAINERS.  CC'ing the relevant person should be good
enough, as we don't have much overlap anyway.

I'd welcome extensions of this and perhaps making debbugs aware of
that, feel free to work on that.  But I think these are very minor
aspects, certainly compared to the larger issues we have now.

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

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

> 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?  And why do you think the frequency of that is
related to the issue tracker being used?  Could it perhaps be related
to the relative complexity of the projects being compared?

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

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

You've changed the subject.  The specific issue here was that using 2
separate places, one for bugs and another for patches, is a step
backward.  It was your proposal to use 2 separate places.  If you now
say we could do it in one place, then please describe how this will
work with MR being the vehicle.  What would be the workflow, when
there's no patch to start an issue?

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

No need, just respond to that other thread, where I described my main
concerns with the Gitlab proposal.

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

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