Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote: Wouldn't it make more sense to have a way for package maintainers to decide if a bug was local or upstream, and a button they could push to automatically send it upstream? I really like Stan's idea. The root of this problem lies in the historical fact that most packages just did not have issue tracking, so Fedora and Bugzilla stepped in to orchestrate it on a distribution level. This works splendidly, if God's willing and creeks don't rise: I have a personal experience of submitting a bug, then a fix, and seeing a fixed package enter the main distribution repository within a week or so, fixing the problem for the entire world including myself. That's why I still believe that Bugzilla is the default place to report the issues, followed by coordination with the upstream, of course. On the other hand, if the submitter and/or the Fedora packager can't deliver the fix, the issues will linger; in that case upstream is really where they should migrate to. On 09/16/2016 01:19 PM, Zbigniew Jędrzejewski-Szmek wrote: Automatically? If I receive a bug upstream, I want to receive it without the distribution's embellishments: I want to know what *upstream* version of the software was used, how I can reproduce the bug using generic installation from sources, and not using the distro package, etc. Also, I don't want to read the full history on the distribution bugtracker, I want to see a concise summary of findings. I want to see an explanation why the bug is an upstream bug, not a distro-specific thing. The person who is forwarding bugs has to all of this by hand, and doing this automatically is infeasible. The better is the enemy of the good. You're right that it would be ideal if upstream got a cleaned up report along the lines you suggested, but the automatic upstream report could essentially link to the Bugzilla entry, which hopefully contains basic setup and reproducibility information---at the very least it registers the issue and establishes communication channel between the upstream developer and Fedora-based reporter. When I run into issues, I tend to follow the original Bugzilla entry with a second comment that at least provides a stack dump showing the crash environment (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1359395 ); abrt does this automatically. I believe this is helpful to the upstream developers, as they sometimes explicitly confirm. The downside of course is we don't want to firehose upstream with an endless stream of reports, but Stan's idea involves a manual step and therefore should keep that under control. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 19/09/16 20:27, Jóhann B. Guðmundsson wrote: > On 09/18/2016 10:16 PM, Jeff Fearn wrote: > >> Hi, we might be able to extend the External Trackers extension in RH >> Bugzilla to be able to create as >> well as sync bugs. > > Between which issue trackers is that supported? Currently, Bugzilla, Jira, and Salesforce. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer PnT - DevOps - Development Red Hat Asia Pacific Pty Ltd http://dilbert.com/fast/2004-08-17/ PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/18/2016 10:16 PM, Jeff Fearn wrote: Hi, we might be able to extend the External Trackers extension in RH Bugzilla to be able to create as well as sync bugs. Between which issue trackers is that supported? JBG ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Mon, 2016-09-19 at 08:16 +1000, Jeff Fearn wrote: > Hi, we might be able to extend the External Trackers extension in RH > Bugzilla to be able to create as > well as sync bugs. > > We've shared the code with upstream to see if they like our approach > so far. > > Fedora is our biggest user community, so we can certainly make some > Fedora specific changes to RH > Bugzilla should it be required. That would be awesome! Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 17/09/16 03:19, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote: >> On Fri, 16 Sep 2016 10:01:30 -0400 >> Matthew Miller wrote: >> >>> On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: >> So, what if we steer end users away from Bugzilla and >> bug-trackers completely² and to Ask Fedora³ instead? The triage >> team could [...] > But there's no triage team. Adding another layer of indirection > without a dedicated new workforce would likely just divert > resources away from the existing bug fixing process. And before anyone asks - we've tried to have a triage team several times and it has never really worked so far. It's a hard and relatively >>> >>> Right, so, this is part of the context for my idea above. There >>> *isn't* a triage team, but there *is* a community around Ask Fedora, >>> and we could build from that. It wouldn't be the same at all as >>> previous efforts to "bugzilla-garden" >> >> Wouldn't it make more sense to have a way for package maintainers to >> decide if a bug was local or upstream, and a button they could push to >> automatically send it upstream? > > Automatically? If I receive a bug upstream, I want to receive it > without the distribution's embellishments: I want to know what > *upstream* version of the software was used, how I can reproduce the > bug using generic installation from sources, and not using the distro > package, etc. Also, I don't want to read the full history on the > distribution bugtracker, I want to see a concise summary of > findings. I want to see an explanation why the bug is an upstream bug, > not a distro-specific thing. The person who is forwarding bugs has to > all of this by hand, and doing this automatically is infeasible. It could probably be made light weight though. Say a button you click that copies in the OP from the bug, pops up a box for the clicker to enter some useful text in, includes a back link to RH BZ, and creates a bug upstream with that information. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer PnT - DevOps - Development Red Hat Asia Pacific Pty Ltd http://dilbert.com/fast/2004-08-17/ PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 17/09/16 03:27, Michael Catanzaro wrote: > On Fri, 2016-09-16 at 17:19 +, Zbigniew Jędrzejewski-Szmek wrote: >> Automatically? If I receive a bug upstream, I want to receive it >> without the distribution's embellishments: I want to know what >> *upstream* version of the software was used, how I can reproduce the >> bug using generic installation from sources, and not using the distro >> package, etc. Also, I don't want to read the full history on the >> distribution bugtracker, I want to see a concise summary of >> findings. I want to see an explanation why the bug is an upstream >> bug, >> not a distro-specific thing. The person who is forwarding bugs has to >> all of this by hand, and doing this automatically is infeasible. > > I don't care so much about all that (it's more important for systemd > due to distro integration), I just want the bug reporter CCed on the > upstream bug, and able to respond when I ask a question. Hi, we might be able to extend the External Trackers extension in RH Bugzilla to be able to create as well as sync bugs. We've shared the code with upstream to see if they like our approach so far. Fedora is our biggest user community, so we can certainly make some Fedora specific changes to RH Bugzilla should it be required. Cheers, Jeff. -- Jeff Fearn Senior Software Engineer PnT - DevOps - Development Red Hat Asia Pacific Pty Ltd http://dilbert.com/fast/2004-08-17/ PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, 16 Sep 2016 12:27:30 -0500 Michael Catanzaro wrote: [snip] > I don't care so much about all that (it's more important for systemd > due to distro integration), I just want the bug reporter CCed on the > upstream bug, and able to respond when I ask a question. Yeah, that would probably be important for everyone. But an email address is available for anyone who can file a bugzilla, so this should be possible. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, 16 Sep 2016 17:19:24 + Zbigniew Jędrzejewski-Szmek wrote: > Automatically? If I receive a bug upstream, I want to receive it > without the distribution's embellishments: I want to know what > *upstream* version of the software was used, how I can reproduce the > bug using generic installation from sources, and not using the distro > package, etc. Also, I don't want to read the full history on the > distribution bugtracker, I want to see a concise summary of > findings. I want to see an explanation why the bug is an upstream bug, > not a distro-specific thing. The person who is forwarding bugs has to > all of this by hand, and doing this automatically is infeasible. You don't want much, do you? :-) A person who can do what you require might as well fix the bug, because they have to know the application almost as well as a developer. (I understand that this an exaggeration, hyperbole, but there is some truth to it also.) 'what upstream version' The version of the problem software is easy to pull out of the src.rpm. 'reproduce the bug using generic installation from sources' The environment where the software runs is *part* of the bug. If the software can't deal with various environments properly, that's a bug in the software. Is upstream saying, our software only works in generic environments and we don't guarantee it, or fix it, anywhere else? If so, they should explicitly state that, or their development environment, and disclaim any other usage. This might make sense if I'm Joe Blow, and I'm running my custom distribution, but for Fedora, Ubuntu, Suse, Debian, Arch, Gentoo, where there are standardization processes? I don't think so. The software resources and scope also matters. If I've created a small app to display some proc variables by myself, with a single computer, that's a different situation than a program like gcc or gnome or kde. 'want to see a concise summary of findings' 'want to see an explanation why the bug is an upstream bug, not a distro-specific' If I'm killing flies or mosquitoes, I want them to land on a block and stand still while I swat them with the fly swatter. But they don't seem to co-operate. Bugs in software are like that. I agree with you that the person who is doing this triage has to have some domain knowledge, and provide a first filter, but I think the filter can be much coarser than you do. That is, I put more onus on the developers than you do. Upstream is free to ignore these tickets like they are being ignored in redhat bugzilla. But if there are a thousand tickets from redhat, ubuntu, debian, suse, arch, debian with the same complaint, I think it would be evidence that there is something wrong with the upstream software (just my opinion), and the developers might want to focus some attention on the problem. i.e. where there's smoke, there's probably fire. This was only a suggestion, in the spirit of mind mapping, or brainstorming, where wild and outrageous ideas of solutions are thrown out to trigger thinking outside the box. And, if nothing else, I learned more about the problem because of your feedback. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, 2016-09-16 at 17:19 +, Zbigniew Jędrzejewski-Szmek wrote: > Automatically? If I receive a bug upstream, I want to receive it > without the distribution's embellishments: I want to know what > *upstream* version of the software was used, how I can reproduce the > bug using generic installation from sources, and not using the distro > package, etc. Also, I don't want to read the full history on the > distribution bugtracker, I want to see a concise summary of > findings. I want to see an explanation why the bug is an upstream > bug, > not a distro-specific thing. The person who is forwarding bugs has to > all of this by hand, and doing this automatically is infeasible. I don't care so much about all that (it's more important for systemd due to distro integration), I just want the bug reporter CCed on the upstream bug, and able to respond when I ask a question. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote: > On Fri, 16 Sep 2016 10:01:30 -0400 > Matthew Miller wrote: > > > On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: > > > > > So, what if we steer end users away from Bugzilla and > > > > > bug-trackers completely² and to Ask Fedora³ instead? The triage > > > > > team could [...] > > > > But there's no triage team. Adding another layer of indirection > > > > without a dedicated new workforce would likely just divert > > > > resources away from the existing bug fixing process. > > > And before anyone asks - we've tried to have a triage team several > > > times and it has never really worked so far. It's a hard and > > > relatively > > > > Right, so, this is part of the context for my idea above. There > > *isn't* a triage team, but there *is* a community around Ask Fedora, > > and we could build from that. It wouldn't be the same at all as > > previous efforts to "bugzilla-garden" > > Wouldn't it make more sense to have a way for package maintainers to > decide if a bug was local or upstream, and a button they could push to > automatically send it upstream? Automatically? If I receive a bug upstream, I want to receive it without the distribution's embellishments: I want to know what *upstream* version of the software was used, how I can reproduce the bug using generic installation from sources, and not using the distro package, etc. Also, I don't want to read the full history on the distribution bugtracker, I want to see a concise summary of findings. I want to see an explanation why the bug is an upstream bug, not a distro-specific thing. The person who is forwarding bugs has to all of this by hand, and doing this automatically is infeasible. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, 16 Sep 2016 10:01:30 -0400 Matthew Miller wrote: > On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: > > > > So, what if we steer end users away from Bugzilla and > > > > bug-trackers completely² and to Ask Fedora³ instead? The triage > > > > team could [...] > > > But there's no triage team. Adding another layer of indirection > > > without a dedicated new workforce would likely just divert > > > resources away from the existing bug fixing process. > > And before anyone asks - we've tried to have a triage team several > > times and it has never really worked so far. It's a hard and > > relatively > > Right, so, this is part of the context for my idea above. There > *isn't* a triage team, but there *is* a community around Ask Fedora, > and we could build from that. It wouldn't be the same at all as > previous efforts to "bugzilla-garden" Wouldn't it make more sense to have a way for package maintainers to decide if a bug was local or upstream, and a button they could push to automatically send it upstream? Suppose that if a fedora package has an upstream bug tracker, *fedora* owns a login to their bug tracker. Then, when the maintainer looks at the bug, he or she decides whether to send it upstream by clicking a button. If it is sent upstream, the [yet to be designed and built application] converts it to the appropriate format, logs in to the upstream bug tracker, and puts it there. And it places a message in the bug on redhat bugzilla stating that the bug has been sent upstream for resolution. That leaves the package maintainer dealing only with local bugs, and new releases. Sort of like abort for packages. Lots of issues here, but it greatly simplifies the package maintainer's job.I have 10 bugs today. I look at them and send those for upstream there, with a click. Leaving me 4. Much more manageable. But it takes work to have this happen, mostly one time, but with some ongoing maintenance. Database of upstream logins and passwords has to be built and maintained. Getting a package approved requires a fedora login and password to be approved, or an exception if it doesn't exist, and entry into the database. I don't know how many different kinds of bug trackers there are, but translating bugzilla to multiple other layouts might be an issue. Maybe instead, just place a link to the fedora bugzilla on their bug tracker. Still, this requires programming and maintenance. Is the trade-off of resources worth it? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, Sep 16, 2016 at 10:01 AM, Matthew Miller wrote: > On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: >> > > So, what if we steer end users away from Bugzilla and bug-trackers >> > > completely² and to Ask Fedora³ instead? The triage team could [...] >> > But there's no triage team. Adding another layer of indirection without >> > a dedicated new workforce would likely just divert resources away >> > from the existing bug fixing process. >> And before anyone asks - we've tried to have a triage team several >> times and it has never really worked so far. It's a hard and relatively > > Right, so, this is part of the context for my idea above. There *isn't* > a triage team, but there *is* a community around Ask Fedora, and we > could build from that. It wouldn't be the same at all as previous > efforts to "bugzilla-garden" I appreciate the idea, but I'm not sure it will actually pan out that way. Right now, the bulk of problem reports for users still go to bugzilla either via ABRT or manual filing. Ask is used more for true newbies or for issues where the person doesn't even know where to file the bug. The community helping there can handle the type and number of issues being reported. It's users helping users. If we start directing users to Ask instead of bugzilla in a coordinated effort, I'm afraid a few things will happen: a) The problem of maintainers ignoring bug reports will become even more prevalent because asking them to monitor multiple locations for problem reports. b) Regardless of whether A happens or not, we run the risk of information loss and excess process being implemented. Bugzilla and Ask could be linked somehow, but bridges rarely work well. c) We'll quickly burn the existing Ask community out. This works in IT because they have dedicated customer support teams. We do not. The problem we face is not really the tools we have, but the lack of people dedicated to customer support. Trying to jumpstart one from the Ask community seems to be asking an awful lot. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Fri, 16 Sep 2016 10:01:30 -0400 Matthew Miller wrote: > On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: > > > > So, what if we steer end users away from Bugzilla and > > > > bug-trackers completely² and to Ask Fedora³ instead? The triage > > > > team could [...] > > > But there's no triage team. Adding another layer of indirection > > > without a dedicated new workforce would likely just divert > > > resources away from the existing bug fixing process. > > And before anyone asks - we've tried to have a triage team several > > times and it has never really worked so far. It's a hard and > > relatively > > Right, so, this is part of the context for my idea above. There > *isn't* a triage team, but there *is* a community around Ask Fedora, > and we could build from that. It wouldn't be the same at all as > previous efforts to "bugzilla-garden" So, before we start using ask for more things, I'd prefer it be in a better place from a infrastructure point of view at least. Right now ask is running on RHEL6, using an old version of Django and various other old bits. The current plan was to wait until Aurélien gets mailman3/hyperkitty all reviewed and in EPEL7. Then we can package up the newer askbot and use the same Django 1.8 that mailman3 uses. That said, upstream hasn't had a release in about 1.5 years. There's a number of bugs and things that don't work that don't seem to get much attention from upstream. (twitter integration, mailing daily digests of questions/answers, etc) We have been trying to setup a Fedora theme for... well, since we set it up at first. There is now the latest attempt setup on stg: https://ask.stg.fedoraproject.org/en/questions/ It's also not super clear how active the community is there. I see a lot of "No answer" questions on the first page at least, so I am not sure if it would work to try and get them to answer user problems and file bugs. On the other hand, It doesn't hurt to try and see how it goes. :) kevin pgp6_y8ko_BKk.pgp Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote: > > > So, what if we steer end users away from Bugzilla and bug-trackers > > > completely² and to Ask Fedora³ instead? The triage team could [...] > > But there's no triage team. Adding another layer of indirection without > > a dedicated new workforce would likely just divert resources away > > from the existing bug fixing process. > And before anyone asks - we've tried to have a triage team several > times and it has never really worked so far. It's a hard and relatively Right, so, this is part of the context for my idea above. There *isn't* a triage team, but there *is* a community around Ask Fedora, and we could build from that. It wouldn't be the same at all as previous efforts to "bugzilla-garden" -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Thu, 2016-09-15 at 23:09 +, Zbigniew Jędrzejewski-Szmek wrote: > > So, what if we steer end users away from Bugzilla and bug-trackers > > completely² and to Ask Fedora³ instead? The triage team could [...] > > > But there's no triage team. Adding another layer of indirection without > a dedicated new workforce would likely just divert resources away > from the existing bug fixing process. And before anyone asks - we've tried to have a triage team several times and it has never really worked so far. It's a hard and relatively thankless job which volunteers rapidly get sick of, and no-one seems terribly interested in paying for it. If someone wants to try again, go for it, but I think any of us who's tried before wouldn't be optimistic about the chances... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, Sep 14, 2016 at 01:46:53PM -0400, Matthew Miller wrote: > On Wed, Sep 14, 2016 at 09:44:06AM -0500, Jason L Tibbitts III wrote: > > I disagree in general; when the bug volume exceeds a certain amount > > bugzilla basically becomes useless. However, it would be really nice if > > _someone_ looked at RH bugzilla for those packages and did something > > with them. > > > > We used to have "bugzappers". What we really need is someone to do > > triage and to forward bugs on to upstream when appropriate. This > > obviously requires volunteers. > > What I'd _really_ love to see is a layer separating bug trackers from > end users. In IT, there's often a distinction made between "incidents" > and "problems"¹. An incident is Something Bad That Happened to A User; > this may be caused by one or more problems. (And a single problem may > cause multiple incidents.) In big IT shops, it's common to have > helpdesk tickets for incidents, and those may then get linked to bug > tickets on the backend. (Either user-visible or not, depending on the > culture.) > > So, what if we steer end users away from Bugzilla and bug-trackers > completely² and to Ask Fedora³ instead? The triage team could [...] But there's no triage team. Adding another layer of indirection without a dedicated new workforce would likely just divert resources away from the existing bug fixing process. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, Sep 14, 2016 at 11:21:44AM -0400, Stephen John Smoogen wrote: > On 14 September 2016 at 10:44, Jason L Tibbitts III > wrote> > I disagree in general; when the bug volume exceeds a certain amount > > bugzilla basically becomes useless. However, it would be really nice if > > _someone_ looked at RH bugzilla for those packages and did something > > with them. I disagree: _any_ bugtracker becomes less useful, or more correctly, bugtracking in general becomes harder and more draining when the bug count becomes so high that you cannot remember all the open bugs. Bugzilla might not be the least cumbersome of trackers, but the real problem is having too many bugs and too little maintainers. > > We used to have "bugzappers". What we really need is someone to do > > triage and to forward bugs on to upstream when appropriate. This > > obviously requires volunteers. > > > > I think this is an excellent job for someone who wants to help out. > > Does Gnome have documentation on performing bug triage like our kernel > > team does? https://fedoraproject.org/wiki/KernelBugTriage > > > > All volunteers would really need is accounts at the upstream trackers, > > the will to search for duplicate bugs there, and some basic knowledge of > > when to ask for more information and how to properly select components > > upstream. I would imagine that a large number of the bugs that are > > filed are duplicates of existing bugs anyway. > > > > Note that I sadly don't have any free time to actually help with this. > > I've tried to do kernel bug triage, and it's very, very difficult and > > time consuming. But that's the kernel; I would hope that just sorting > > out Gnome bugs wouldn't be quite so bad. > > > > It is just as bad for pretty much the same reasons: > 1) Do you have access to that system. > 2) Is the problem in the app or in X or in the kernel or the hardware. > 3) If it is in the hardware is it a monitor/video card/motherboard issue > 4) If you think it is in the kernel go to kernel triage > 5) If you thinking it is in X follow the kernel triage but use s/kernel/X/ > 6) If it is in the app can you even figure out what configuration caused it? > 7) Is the bug really in the app or in some side app which it talks to? I think you're painting an overly bleak picture: for most backtraces somebody who knows the code well can tell what's wrong. I don't know the gnome codebase at all, but I look a lot at systemd backtraces, and there's very few "unresolvable" ones for which we cannot determine the reason. I don't think gnome would be different here. Taking the list that Jakub Filak posted [1] as an example. The second most frequent trace on that list is an assertion failure in gdk_event_source_check [2], and the first is a segmentation fault in thumbnail generation [3]. I doesn't sound like hardware issues. [1] https://retrace.fedoraproject.org/faf/problems/?opsysreleases=122&opsysreleases=123&associate=51 [2] https://retrace.fedoraproject.org/faf/problems/bthash/?bth=2dc809f76a6e964ae97bca1d5ab19c6e44a52e37&bth=3d180ca127e69c831065f0528626b2dfb4bb2a97&bth=5c45986c061edd916962c68b83caa7540ac07c82&bth=722d98e99bc0a4898af9622f92ca103d0bf2bc38&bth=94e4a7c759fa0e9888ec9abe4255a4e1a6026c86&bth=9786755e1049db543438f825966598ebd2cc1647&bth=e6ca80c9f6ea0704148d59c89228af59df54ae32 [3] https://bugzilla.redhat.com/attachment.cgi?id=1187004 #0 cmsGetColorSpace (hProfile=hProfile@entry=0x0) at cmsio0.c:934 Icc = 0x0 Looks like a standard NULL point crash. > On the other hand, we have this conversation every (or every other) > mid release cycle... so maybe we should just do the play one more > time. Some drama about how Gnome sucks, gets special treatment, or > isn't as special as systemd, is always put upon.. Dunno, to me both systemd and gnome "suffer" the problem of too many users and not enough maintainers. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/14/2016 05:46 PM, Matthew Miller wrote: What I'd_really_ love to see is a layer separating bug trackers from end users. That layer already exist in the form of irc forum and askbot does it not? ( someone from the support sub-community can provide information how successful these are ) And from my former QA days I cant recall that end users issues being mistakenly reported in bugzilla existed in the first place or was a problem for that matter. ( The steps that are necessary to file a report to begin with, act as a natural filter that prevents that from happening ) I'm only aware of one bug ( arguably misfiled ) against systemd in the distribution that might fall under that category but that is entirely due to the fact those changes slipped through the distribution documentation and announcement radar ( which arguably should have been covered in Gnome ) so end users/administrators simply dont know how they are custom to configure things does not work in certain scenarios with certain components. JBG -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, Sep 14, 2016 at 09:44:06AM -0500, Jason L Tibbitts III wrote: > I disagree in general; when the bug volume exceeds a certain amount > bugzilla basically becomes useless. However, it would be really nice if > _someone_ looked at RH bugzilla for those packages and did something > with them. > > We used to have "bugzappers". What we really need is someone to do > triage and to forward bugs on to upstream when appropriate. This > obviously requires volunteers. What I'd _really_ love to see is a layer separating bug trackers from end users. In IT, there's often a distinction made between "incidents" and "problems"¹. An incident is Something Bad That Happened to A User; this may be caused by one or more problems. (And a single problem may cause multiple incidents.) In big IT shops, it's common to have helpdesk tickets for incidents, and those may then get linked to bug tickets on the backend. (Either user-visible or not, depending on the culture.) So, what if we steer end users away from Bugzilla and bug-trackers completely² and to Ask Fedora³ instead? The triage team could supplement the people already working there to help people with their questions, and rather than linking bug trackers, we could create a tool where high-rep users could push a button to 1) create a bug in the appropriate one and 2) add an answer like: "This looks like it's caused by a bug in $whatever. I've created a ticket in the tracking system for that project, which you can see at $link. If this is sufficient, feel free to mark this as accepted. Otherwise, this will be updated as the underlying bug is worked on." 1. http://www.itskeptic.org/content/how-itil-gets-incident-vs-problem-wrong 2. To be more nuanced: we wouldn't shut it down for technical users, which for this purpose I will definie as "users able to identify the right bugzilla for a particular problem", but we would change all of our end-user-facing documentation to recommend the help system instead. 3. Or something like it. Ask Fedora could use some development work, but that's another story :) -- Matthew Miller Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/14/2016 07:01 PM, Josh Boyer wrote: 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. This is a Dinglish "politically correct" phrase to describe "to partially give up/step down", "make room to others" and "hire more people". What I mean, if you feel being overloaded, be honest to your self and "downsize" your tasks/duties. Ralf -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, 14 Sep 2016 13:01:14 -0400 Josh Boyer wrote: > 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. Agreed. Additionally, there's packages we have that have 0 bugs actually filed against them, but don't work or have serious problems. So, IMHO all this boils down to 'It depends', 'we should try and improve tools for maintainers' and 'we should try and do the best we can with the tools and processes we have'. I think this post (from 6 years ago now) could be helpful: http://www.rants.org/2010/01/bugs-users-and-tech-debt/ If you don't want to click through (but you should, it's a good read), the author posits two things: You shouldn't be worried that you have more bugs and bugs are not actually technical debt so you shouldn't think of them that way. kevin pgpONvSmtv6it.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, Sep 14, 2016 at 12:47 PM, Ralf Corsepius wrote: > On 09/14/2016 06:24 PM, Josh Boyer wrote: >> >> On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius >> 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@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/14/2016 06:24 PM, Josh Boyer wrote: On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius 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. My impression is, in many cases, it's ego, which prevents to acknowledge they need "to divert". - 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. Ralf -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/14/2016 02:44 PM, Jason L Tibbitts III wrote: I disagree in general; when the bug volume exceeds a certain amount bugzilla basically becomes useless. However, it would be really nice if _someone_ looked at RH bugzilla for those packages and did something with them. This responsibility falls under those individuals that have signed themselves up with maintaining the component(s) in question in the distribution and call themselves "package maintainers"... JBG -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius wrote: > On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote: >>> >>> "RC" == Ralf Corsepius writes: >> >> >> RC> IMO, it should be mandatory for Fedora maintainers to look into RH >> RC> Bugzilla, because that's the product they are "maintaining" and what >> RC> users are using. >> >> I disagree in general; > > Whom do you report problems with HW to in real life? To the manufacturer or > to a component's manufacturer? > > Almost certainly the manufacturer and not to a component's manufacturer. > >> when the bug volume exceeds a certain amount >> bugzilla basically becomes useless. > > > When the bug volume becomes too large, the causes for this should be > analysed and be addressed. > > 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. > - 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. josh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote: "RC" == Ralf Corsepius writes: RC> IMO, it should be mandatory for Fedora maintainers to look into RH RC> Bugzilla, because that's the product they are "maintaining" and what RC> users are using. I disagree in general; Whom do you report problems with HW to in real life? To the manufacturer or to a component's manufacturer? Almost certainly the manufacturer and not to a component's manufacturer. when the bug volume exceeds a certain amount bugzilla basically becomes useless. When the bug volume becomes too large, the causes for this should be analysed and be addressed. 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. - A package triggering too many BZs. IMO, this should question the package's quality. Ralf -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
On 14 September 2016 at 10:44, Jason L Tibbitts III wrote: >> "RC" == Ralf Corsepius writes: > > RC> IMO, it should be mandatory for Fedora maintainers to look into RH > RC> Bugzilla, because that's the product they are "maintaining" and what > RC> users are using. > > I disagree in general; when the bug volume exceeds a certain amount > bugzilla basically becomes useless. However, it would be really nice if > _someone_ looked at RH bugzilla for those packages and did something > with them. > > We used to have "bugzappers". What we really need is someone to do > triage and to forward bugs on to upstream when appropriate. This > obviously requires volunteers. > > I think this is an excellent job for someone who wants to help out. > Does Gnome have documentation on performing bug triage like our kernel > team does? https://fedoraproject.org/wiki/KernelBugTriage > > All volunteers would really need is accounts at the upstream trackers, > the will to search for duplicate bugs there, and some basic knowledge of > when to ask for more information and how to properly select components > upstream. I would imagine that a large number of the bugs that are > filed are duplicates of existing bugs anyway. > > Note that I sadly don't have any free time to actually help with this. > I've tried to do kernel bug triage, and it's very, very difficult and > time consuming. But that's the kernel; I would hope that just sorting > out Gnome bugs wouldn't be quite so bad. > It is just as bad for pretty much the same reasons: 1) Do you have access to that system. 2) Is the problem in the app or in X or in the kernel or the hardware. 3) If it is in the hardware is it a monitor/video card/motherboard issue 4) If you think it is in the kernel go to kernel triage 5) If you thinking it is in X follow the kernel triage but use s/kernel/X/ 6) If it is in the app can you even figure out what configuration caused it? 7) Is the bug really in the app or in some side app which it talks to? Normally you work backwards down the list but you have to cover all the bases as a good many crashes are from something you have nothing to control. Which is why various people find that they go to XYZ bugtracker and get told it isn't the distributions problem because it isn't the OS they used and they can't duplicate. [I am using XYZ because this problem can be generalized to Gnome/KDE/XFCE/Libreoffice/etc.] One of the reasons that bugzappers seemed to fall apart was it was a slog of work that burned out people without much in the way of reward because it never ends. The remaining bugzappers then took more of the load over and over again until you ended up with 1-2 people? Which is also happening with package maintainers. You get packagers with piles of packages burning out and the remaining people taking more and more packages over time. This ends up with people with hundreds of packages that they have under their belt and no way to actually keep track of the bugs on them. On the other hand, we have this conversation every (or every other) mid release cycle... so maybe we should just do the play one more time. Some drama about how Gnome sucks, gets special treatment, or isn't as special as systemd, is always put upon.. then a dramatic quitting around beta and general agreement that we will all do better for the next release. It's just like Shakespeare without iambic pentameter. > - J< > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
> "RC" == Ralf Corsepius writes: RC> IMO, it should be mandatory for Fedora maintainers to look into RH RC> Bugzilla, because that's the product they are "maintaining" and what RC> users are using. I disagree in general; when the bug volume exceeds a certain amount bugzilla basically becomes useless. However, it would be really nice if _someone_ looked at RH bugzilla for those packages and did something with them. We used to have "bugzappers". What we really need is someone to do triage and to forward bugs on to upstream when appropriate. This obviously requires volunteers. I think this is an excellent job for someone who wants to help out. Does Gnome have documentation on performing bug triage like our kernel team does? https://fedoraproject.org/wiki/KernelBugTriage All volunteers would really need is accounts at the upstream trackers, the will to search for duplicate bugs there, and some basic knowledge of when to ask for more information and how to properly select components upstream. I would imagine that a large number of the bugs that are filed are duplicates of existing bugs anyway. Note that I sadly don't have any free time to actually help with this. I've tried to do kernel bug triage, and it's very, very difficult and time consuming. But that's the kernel; I would hope that just sorting out Gnome bugs wouldn't be quite so bad. - J< -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org