Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

On 25.04.2019 22:54, Eli Zaretskii wrote:

> Not "exactly the same", but without "significant changes", yes.

I see. Probably. (We could discuss the meaning of "significant", but 
let's not).

>> Which is a perspective I'm not particularly hopeful about.
> 
> 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.

>> 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?). That changes 
very little. You need to search, tag, Cc somebody else, maybe.

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

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

> It's harder, yes.  But that's the job, and it must be done.  And it
> becomes easier with time, as you become familiar with more and more
> areas.

To be honest: that's only an enticing prospect if I'm aiming to be an 
Emacs maintainer. There's not enough free space in my head already.

>> 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 (then 
someone responsible for it can take over).

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

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.

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

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

>> That also works to confirm that a bug should be made a priority (old
>> report, users still commenting on it).
> 
> Not necessarily.  Priority of a bug doesn't necessarily become higher
> with time, it could actually become low in some cases (people manage
> to get by).

It works to confirm the priority when new users keep commenting on old 
bug reports.

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

We might get close enough, though.

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

> I'm talking about the situation with bug triage and patch review.
> Whatever my approach is, it cannot affect those, that's entirely up to
> the people who volunteer their time for doing that.  I'm glad that the
> situation with this is slowly improving.

I'm glad that's happening, then.

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

> efficient handling of bugs for which there's no patch yet is much more
> important than efficient review of patches, primarily because we have
> much more bug reports than patches on any given day.  A solution that
> makes patch review easier, but does nothing to improve bug handling is
> unlikely to get my vote, because I think this is backwards: we should
> be solving the most important bottlenecks first.

Bug handling is "easier" than doing code reviews in a lot of respects. 
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).