Re: [RFE] Migration to gitlab

[Eli Zaretskii <eliz@gnu.org>]

> Cc: hi-angel@yandex.ru, theophilusx@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 26 Apr 2019 02:16:34 +0300
> 
> > Why?  You think it's a tough criterion to meet?  I actually think the
> > bar is quite low.  How many new bugs get reported each day?  2? 5?
> > How hard is it to triage 80% of that, even given the relatively small
> > number of people who currently do that?
> 
> (I hope we're not talking about my own participation, with the backlog I 
> already have, and, well, Debbugs still being there).
> 
> On the one hand, you're probably right. On the other, there must be a 
> reason it still hasn't happened yet.

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.

> >> It's a relatively simple, but repetitive process that requires
> >> interacting with the bug tracker on every step.
> > 
> > Does it?  The bugs get mailed to you if you subscribe, so no
> > interaction is needed, until you send a short email after you finish
> > the triage.  I only ever need to interact with the tracker when
> > looking up an old bug report, or searching for related issues.  The
> > initial handling of a new bug almost never needs any interaction.
> 
> 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.

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

> >> Debbugs aside, not every project has "try to reproduce" as one of the
> >> steps in bug triage.
> > 
> > It isn't a requirement.  If you are able to triage or fix without
> > reproducing, no one will object.
> 
> "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.

> >> On the other hand, the current triage notes mention no categorization
> >> step
> > 
> > What do you mean by categorization?  It does include determining the
> > priority.
> 
> 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.

> >> or assignment to responsible parties.
> > 
> > It does, AFAICT:
> > 
> >    5. Who should be the owner?
> 
> OK. But to be pedantic, the document only tells me to ask the question, 
> but not what to do with the result. And there's no "owner" field in Debbugs.

The text is not cast in stone, it can be clarified.  (Though to me,
what to do is obvious, not to be pedantic.)

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

> >> Third, since admin/notes/bug-triage is inside admin/, we apparently do
> >> not expect drive-by contributors in participate in the triage process.
> > 
> > No, we don't.  But no one will object to them doing so.  No one needs
> > a permission to start responding to bug reports, everybody is welcome.
> 
> I'm saying you might want to move that information somewhere else. 
> CONTRIBUTE is already long, though. So I don't have a better proposal 
> for the *current* workflow.

CONTRIBUTE already encourages to look at and help dealing with bug
reports.

> >> Finally, in my own projects which are fairly mature, I sometimes fail to
> >> respond to bug reports. The users themselves find existing bug reports
> >> and comment to confirm that yes, the bug still exists and remains a
> >> problem. Triage success!
> > 
> > We have this on the bug list as well: people confirm that they see a
> > problem reported by someone else.
> 
> It is, of course, just my experience: but I see that a lot more often in 
> the GitHub bug tracker than over here in Debbugs. An order of magnitude 
> more often.

Not sure why this is important: IME, such messages are in many cases
of little help in investigating the issue and finding its causes.

> >> I remember certain people on this mailing list complaining about
> >> duplicates in the bug tracker (and users failing to do the search).
> >> Well, get a bug tracker with a user friendlier interface (visibility,
> >> searchability, etc), and the users will do more work for you.
> > 
> > All else being equal, sure.  But there isn't such a beast, TANSTAAFL.
> 
> 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.

> > And I'm not really sure searching debbugs is such a black art.
> > perhaps Noam and Glenn could share their experience and methods, and
> > we will all become better searchers.
> 
> 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.

> >> But in short, bug reports to in Debbugs, patch submissions to into
> >> GitLab (and also Debbugs sometimes, though we could automate some
> >> process to move them over to GitLab from there).
> > 
> > So we are supposed to have 2 sites/UIs open when dealing with a bug
> > report to which someone suggested a solution?  Is that an improvement?
> 
> 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.

> Stefan seemed enthusiastic enough about "a system where we can
> receive contributions via merge requests". The exact improvement would 
> depend on how well the reviewers would be able to take advantage of 
> GitHub's features (the web UI has a lot of them; whatever interface we 
> choose would either have to simplify or reimplement some of them).
> 
> That is, improvement from your side. The users who don't mind using the 
> web interface will likely benefit the most. And we'll likely see more 
> user attention as a result.
> 
> > Please read my notes about the main issues I see with Gitlab:
> 
> 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.

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

> First and foremost, email notifications and responding to reports via 
> email should already work. There are definite advantages to be gained 
> from migrating the bug tracker to GitLab, but we need some trial period, 
> and probably don't want to deal with two bug trackers at once.
> 
> Adding Merge Requests to our workflow first would force us to work out 
> the kinks in the more difficult parts of the integration, as well as 
> test drive also the same features that bug reports have (commenting 
> through email, searching, tagging, changing status, etc).

This again belongs to the other subthread, not here.