Re: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)

[Przemek Klosowski]

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)

[Jeff Fearn]

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)

[Jóhann B . Guðmundsson]

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)

[Michael Catanzaro]

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)

[Jeff Fearn]

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)

[Jeff Fearn]

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)

[stan]

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)

[stan]

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)

[Michael Catanzaro]

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)

[Zbigniew Jędrzejewski-Szmek]

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)

[stan]

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)

[Josh Boyer]

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)

[Kevin Fenzi]

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)

[Matthew Miller]

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)

[Adam Williamson]

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)

[Zbigniew Jędrzejewski-Szmek]

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)

[Zbigniew Jędrzejewski-Szmek]

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=123=51
[2] 
https://retrace.fedoraproject.org/faf/problems/bthash/?bth=2dc809f76a6e964ae97bca1d5ab19c6e44a52e37=3d180ca127e69c831065f0528626b2dfb4bb2a97=5c45986c061edd916962c68b83caa7540ac07c82=722d98e99bc0a4898af9622f92ca103d0bf2bc38=94e4a7c759fa0e9888ec9abe4255a4e1a6026c86=9786755e1049db543438f825966598ebd2cc1647=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)

[Jóhann B . Guðmundsson]

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)

[Matthew Miller]

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)

[Ralf Corsepius]

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)

[Kevin Fenzi]

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)

[Josh Boyer]

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)

[Ralf Corsepius]

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)

[Jóhann B . Guðmundsson]

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)

[Josh Boyer]

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)

[Ralf Corsepius]

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)

[Stephen John Smoogen]

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)

[Jason L Tibbitts III]

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