I've just read through: #131 Red Hat Bugzilla: GNOME packages are in
bad shape.
https://pagure.io/fedora-workstation/issue/131
I always like to know the background of people who are talking to me so
here's a little, appropriate to this topic, background on me.
I'm one of those who help out with testing. My involvement with RHBZ
bugs is filing them and providing information to help with trouble shooting.
I've been an engineer working on hardware design and software for my
whole career. I'm very familiar with the processing of bug and reports
with other titles that basically said either I or someone else had a
problem to solve. I fully understand many bugs are never resolved and
the reasons why. I've attended and led many meetings where bugs were
discussed, prioritized, etc.
That was hard enough to manage, in the context of a company where
everyone was an employee working on a single project, but as I consider
the number of teams of people and individuals who are involved with the
software in Fedora Linux I am greatly impressed that the bug systems
involved work as good as they do.
I agree though, that improvements can be made. One advantage that the
company environments have is that when a bug is not going to be worked
on, everyone knows it and why. In RHBZ or GitLab Issues bugs just hang
around. Perhaps this could be improved by requiring all bugs to be
triaged at least to the extent where it can be determined if it will be
worked on and if not give a reason such as "no bandwith for this release
please reassign to Rawhide", "Please file upstream". This initial triage
could probably be best done by the person that a bug is initially
assigned to.
I understand that their are likely hundreds of new bugs filed each
release cycle. If other fedora folks could be invested with the general
reasons why bugs don't get worked on they could help with this initial
triage and avoid filing such bugs. One thing I've learned is not to file
bugs on applications that are not installed by Anaconda in RHBZ. Even
for those installed by Anaconda it seems best to only file bugs on
"system" items rather that those that are "general user". These might be
triage points. Another suggestion is that at the beginning of a cycle
someone could check the groups to see what sort of bugs they will or
won't have bandwidth for. This sort of approach might be more achievable
than trying to get the report systems to work together. I suspect that a
major problem for the bug / issue database clutter is lack of person
hours. So quick, but intelligent sort outs may help. Even an automated
system could check for "Is this bug against something Anaconda installed?"
Yes, I agree, closing bugs for such reasons might be harmful to moral of
those filing bugs. However, having their bugs just hang around with no
apparent action isn't good for moral. At least the early sort out keeps
the database cleaner so developers don't need to have so many sorts on
their view of RHBZ, let folks know status, and maybe some bugs get fixed
that wouldn't have been seen due to view sorts in RHBZ.
I have tried filing bugs in both directions (RHBZ and GitLab Issues)
with mixed results.
I have one I have been watching for a while now (over a year). I filed
the bug with RHBZ and I have considered filing a report with upstream
with Firewalld. I'm not a member of any of their teams so I doubt I
could even file a report. My experience with trying to file reports with
other upstream teams has not been good; so I've been ambivalent about
trying it with the Firewalld team.
I have from time to time, when I have bugs that have been hanging around
for two or more revisions, just closed them. I don't like cluttering up
databases with reports that are of no value to the team. I have been
able to find other ways to accomplish what I need to do; so I can live
without software that has the unresolved bug.
Please let me know if there are things I can do to help. Also, please
let me know if this kind of input is useful.
Have a Great Day!
Pat (tablepc)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
