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


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.

reply via email to

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