Re: [RFE] Migration to gitlab

[Dmitry Gutov]

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.