[Top][All Lists]

[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: Fri, 26 Apr 2019 02:16:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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

What do you mean by categorization?  It does include determining the

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]