On Wed, Sep 14, 2016 at 12:47 PM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > On 09/14/2016 06:24 PM, Josh Boyer wrote: >> >> On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> >> wrote: > > >>> In this areas I primarily see 2 groups: >>> - Maintainers, who are overloaded with BZs. >>> IMO, this primarily is an ego problem and partially a project >>> management/leadership problem. >> >> >> I mostly disagree, but even in the small amount I do agree I believe >> you have the order reversed in terms of the primary cause. > > > Well, openly said, if maintainers complain and excuse with "overload" they > in first place should ask themselves, why they can't do better. That is indeed a fair question to ask. > My impression is, in many cases, it's ego, which prevents to acknowledge > they need "to divert". I'm not sure what you mean by divert. If you mean ask for help, then sure. However, help is in very short supply already. Quite simply, there are valid cases where a maintainer, or a group of maintainers, cannot scale to the number of bugs a package can generate. The larger and more complex a package, the more likely that is. That isn't anyone's fault or anyone's ego getting in the way. >>> - A package triggering too many BZs. >>> IMO, this should question the package's quality. >> >> >> We have no bar for software quality, only for initial packaging of >> said software. We rely on package maintainers to ensure things work. >> Sometimes that isn't really known until a wider audience starts using >> the package. That essentially makes this a subset of your original >> problem group of too many BZs. > > > I was primarily referring to ABRT, here. If the reports it generates can not > be processed in reasonable manners, ABRT is useless. I disagree with that. It's rather useful, particularly the retrace side of things. That gives you measurable data on which bugs are being hit the most for a particular package. The generation of reports, whether done by ABRT or a large number of users, is not the problem. The problem is the ratio of people able to process vs. the number overall. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
