[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: |
Thu, 25 Apr 2019 18:01:19 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
On 25.04.2019 13:55, Eli Zaretskii wrote:
When close to 80% of bugs and patches posted to the issue tracker will
wait less than a week before they get responded in some meaningful way
(excluding a mere acknowledge of seeing the report), and not
necessarily by yours truly. Sounds good?
You mean only after that we can consider changing workflows?
That's the criterion I propose, yes.
I don't understand. Either you're saying that we simply wait and carry
on our workflows in exactly the same way until the aforementioned 80%
happens. Which is a perspective I'm not particularly hopeful about.
OR
We discuss the options, and we're open to making some changes (minor or
major), as long as we agree that they are for the common good. We can
also test-drive any new changes in advance before committing to them.
I might be misunderstanding your use of the word "criterion", though.
A lot of big, popular projects (and especially those) have huge
numbers of untriaged bugs because it's simply a function of a
project's popularity.
I see no reason not to triage the bugs quickly, even if a large
portion of the bugs gets triaged into the "unassigned" category.
Triage is not a complex process.
It's a relatively simple, but repetitive process that requires
interacting with the bug tracker on every step. Which is basically
impossible to do when one severely dislikes the current bug tracker.
Debbugs aside, not every project has "try to reproduce" as one of the
steps in bug triage. The bigger ones don't AFAIK. And trying to do that
would be more time-consuming, as well as require one to familiarize
themselves with features of Emacs they have no experience/interest in.
On the other hand, the current triage notes mention no categorization
step, or assignment to responsible parties. Which would be helpful in
its own right.
Third, since admin/notes/bug-triage is inside admin/, we apparently do
not expect drive-by contributors in participate in the triage process.
Even though the steps are relatively simple, and one does not have to
possess much in-depth knowledge to perform it.
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! That also works to confirm that a bug should be
made a priority (old report, users still commenting on it).
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.
I honestly do not know what improvement is possible with our current
resources. The only way I know of improving the situation is to try, and
try, to attract new contributors. And that can happen if we use newer
tools which increase visibility into our development process, and makes
it more approachable for a new contributor.
The situation actually improves quite steadily. Just slowly.
The improvement is to be expected, given your more conservative approach
to Emacs development than the previous maintainer did. But it's no
guarantee that the ratio is ever going to reach 100%, or even 80%, and
stay there.
If you look back at the list I wrote, only the step of Migration off
Debbugs (the last one) should be considered distant.
So you propose that we use debbugs and Gitlab concurrently? How's
that supposed to work?
I think we have a sub-thread in this discussion that's better suited for
this question.
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). I'm hoping this can be
a step to easy the transition to using GitLab full-time, but it can
continue for a while (and never end, basically).
During that time you would evaluate how easy it is to review patches in
GitLab (maybe using some Emacs-based client, maybe over email), as well
as simply leave comments there.
- Re: [RFE] Migration to gitlab, (continued)
- Re: [RFE] Migration to gitlab, Dmitry Gutov, 2019/04/20
- 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 <=
- 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, 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