[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
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).
- Re: [RFE] Migration to gitlab, (continued)
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/24
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/25
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/25
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/25
- Re: [RFE] Migration to gitlab,
Dmitry Gutov <=
- Re: [RFE] Migration to gitlab, Michael Albinus, 2019/04/26
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/26
- Re: [RFE] Migration to gitlab, Michael Albinus, 2019/04/26
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/26
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/26
- Re: [RFE] Migration to gitlab, Eli Zaretskii, 2019/04/27
- Re: [RFE] Migration to gitlab, Ricardo Wurmus, 2019/04/26
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/26
Re: [RFE] Migration to gitlab, Toon Claes, 2019/04/23