>> After having opened a few GitLab issues in response to bug reports
>> on bug-lilypond, I find James extraordinarily patient for having
>> done this over the years. However, I don't get the value in this
>> system compared to letting people creating issues on GitLab
>> directly. When we transfer an issue to GitLab, it's usually just
>> pasting the text from the email report.
>
> No it is more than that.
There are two point of views. Some people (for example, the HarfBuzz
developers) don't want e-mail on their mailing list; they prefer that
users open issues for both user questions and bug reports. I guess
this works because HarfBuzz is a very specialized library, not to be
used by Joe User but by developers who already know how good bug
reports should look like.
The other point of view is that bug reports should be collected in a
database, being correctly tagged and as concise and compact as
possible. I agree with James that it makes sense to parse and filter
reports in advance to achieve that, so I'm on his side.
>> Right now, bug reports often take a week to be acknowledged,
Well, yes. Not a big problem IMHO.
>> So how about retiring bug-lilypond and directing to GitLab instead?
>> Tickets can be triaged there, closing invalid ones, adding a
>> minimal example if not present, perhaps changing the title. The
>> requirement from the same page of GNU guidelines,
>
> I don't see the difference between triaging GitLab vs triaging Bug
> apart from the fact that it is very easy to use bug-list interface
> to track email threads - it's so easy to spot of something on the
> bug list has had a reply or not. [...]
Since James is doing most of the work, I think we should do what he
prefers. This doesn't prevent other developers to chime in and help
with handling bug reports. And frequent *and experienced* bug
reporters should be told to directly use the bug tracker.
Werner
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
