Re: [RFE] Migration to gitlab

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 25 Apr 2019 18:01:19 +0300
> 
> 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.

Not "exactly the same", but without "significant changes", yes.

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

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.

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

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

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.

> On the other hand, the current triage notes mention no categorization 
> step

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

> or assignment to responsible parties.

It does, AFAICT:

  5. Who should be the owner?

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

> 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.  But that's just the beginning of a
triage, it just means the bug is not "not reproducible".

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

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

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.

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

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.

> 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?

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

Please read my notes about the main issues I see with Gitlab:
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.