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: F24, small backward steps

[Jóhann B . Guðmundsson]

On 09/13/2016 04:41 PM, Bastien Nocera wrote:



- Original Message -


- Original Message -

I'm seeing 24 bugs at:
https://apps.fedoraproject.org/packages/fprintd/bugs/all
including a potential security one: https://bugzilla.redhat.com/1333882

Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
that abundantly clear I think.

I said "garbage fire" when I meant "tire fire". It keeps on burning and I'm
too lazy/busy to handle those bugs downstream when the majority of the work,
triaging and discussions happen upstream.


From the reporters point of view their distribution is seen to them as 
"upstream" so they don't want to run around the internet chasing down 
bug trackers ( which they should not have to do if the distribution 
package maintainers are doing their due diligence ).


From upstream point of view their issue tracker the point of origin and 
they dont want to be chasing down bug trackers in those gazillion 
downstream distribution using their application or application stack ( 
which again they should not have to do if the distribution package 
maintainers are doing their due diligence ).


So basically your are just seeing two sides of the same problematic coin.

And this problem remains unsolvable while bug trackers and policy 
surrounding them is so fragmented in the linux ecosystem.




I should also note that the Red Hat bugzilla is far too coarse for handling
split-up projects like gnome-control-center and gnome-settings-daemon, both of
which are connected to multiple system layers (the kernel, systemd, a lot
of specialised daemons, windowing systems, and their dependencies) and which
have separate maintainers upstream.


Could not agree more.

Mozilla bugzilla is horrific tool in using and trying to resolve this 
issue and even if it was not, it cannot be improved to be made even 
remote usable issue tracker in this scenario due to it not being Fedora 
only.


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Neal Gompa]

On Wed, Sep 14, 2016 at 2:35 PM, Josh Boyer  wrote:
> On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa  wrote:
>> On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
>>  wrote:
>>> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
 > Yes, THIS. Our current model does not really allow us to express this
 > at all -- there's "orphaned", but that's not user-visible.
 Our current model actually could express this though.  We could put
 the weakly maintained packages in COPRs, and editions that wish to
 include them can do so in their default repos.  There is also the
 previous idea of the curated COPR playground.
 We have the tools, we just need to use them.
>>>
>>> One problem is that weakly maintained packages are often dependencies
>>> and libraries. They're weakly maintained because the person packaging
>>> them never really cared about them for their own sake, only for some
>>> other application which needs them. That application may be strongly
>>> maintained, but the various deps only updated when some issue affects
>>> that app. I guess the whole thing could go into a COPR in this kind of
>>> case, but I'm not sure that's quite right.
>>>
>>>
>>
>> The fundamental problem with this in COPR is that COPR doesn't know
>> how to do automatic rebuilds based on changes in the repos it uses.
>> For example, with my OBS projects, when the Rawhide repodata is
>> updated, OBS automatically properly bumps the Release and rebuilds the
>> package so that it works properly with whatever changed in the
>> repositories. COPR lacks this capability, but it is needed for
>> something like that to work.
>
> Koji doesn't do this either, yet we seem to get by.  I'm not sure I
> follow why auto-rebuild is a requirement versus a (very) nice to have.
>

Koji doesn't do it, because packagers are supposed to rebuild things
when they update stuff. When everything is in one place (a single Koji
instance), it's easy enough to pull off. And Bodhi catches dep errors
on submission of updates if the checks are enabled.
Once things are scattered across different systems or instances of
systems, it gets really messy and broken.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
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: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Josh Boyer]

On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa  wrote:
> On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
>  wrote:
>> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
>>> > Yes, THIS. Our current model does not really allow us to express this
>>> > at all -- there's "orphaned", but that's not user-visible.
>>> Our current model actually could express this though.  We could put
>>> the weakly maintained packages in COPRs, and editions that wish to
>>> include them can do so in their default repos.  There is also the
>>> previous idea of the curated COPR playground.
>>> We have the tools, we just need to use them.
>>
>> One problem is that weakly maintained packages are often dependencies
>> and libraries. They're weakly maintained because the person packaging
>> them never really cared about them for their own sake, only for some
>> other application which needs them. That application may be strongly
>> maintained, but the various deps only updated when some issue affects
>> that app. I guess the whole thing could go into a COPR in this kind of
>> case, but I'm not sure that's quite right.
>>
>>
>
> The fundamental problem with this in COPR is that COPR doesn't know
> how to do automatic rebuilds based on changes in the repos it uses.
> For example, with my OBS projects, when the Rawhide repodata is
> updated, OBS automatically properly bumps the Release and rebuilds the
> package so that it works properly with whatever changed in the
> repositories. COPR lacks this capability, but it is needed for
> something like that to work.

Koji doesn't do this either, yet we seem to get by.  I'm not sure I
follow why auto-rebuild is a requirement versus a (very) nice to have.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Neal Gompa]

On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
 wrote:
> On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
>> > Yes, THIS. Our current model does not really allow us to express this
>> > at all -- there's "orphaned", but that's not user-visible.
>> Our current model actually could express this though.  We could put
>> the weakly maintained packages in COPRs, and editions that wish to
>> include them can do so in their default repos.  There is also the
>> previous idea of the curated COPR playground.
>> We have the tools, we just need to use them.
>
> One problem is that weakly maintained packages are often dependencies
> and libraries. They're weakly maintained because the person packaging
> them never really cared about them for their own sake, only for some
> other application which needs them. That application may be strongly
> maintained, but the various deps only updated when some issue affects
> that app. I guess the whole thing could go into a COPR in this kind of
> case, but I'm not sure that's quite right.
>
>

The fundamental problem with this in COPR is that COPR doesn't know
how to do automatic rebuilds based on changes in the repos it uses.
For example, with my OBS projects, when the Rawhide repodata is
updated, OBS automatically properly bumps the Release and rebuilds the
package so that it works properly with whatever changed in the
repositories. COPR lacks this capability, but it is needed for
something like that to work.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

How to handle "weakly maintained packages" [was Re: F24, small backward steps]

[Matthew Miller]

On Wed, Sep 14, 2016 at 01:27:45PM -0400, Josh Boyer wrote:
> > Yes, THIS. Our current model does not really allow us to express this
> > at all -- there's "orphaned", but that's not user-visible.
> Our current model actually could express this though.  We could put
> the weakly maintained packages in COPRs, and editions that wish to
> include them can do so in their default repos.  There is also the
> previous idea of the curated COPR playground.
> We have the tools, we just need to use them.

One problem is that weakly maintained packages are often dependencies
and libraries. They're weakly maintained because the person packaging
them never really cared about them for their own sake, only for some
other application which needs them. That application may be strongly
maintained, but the various deps only updated when some issue affects
that app. I guess the whole thing could go into a COPR in this kind of
case, but I'm not sure that's quite right.


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

[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: F24, small backward steps

[Josh Boyer]

On Wed, Sep 14, 2016 at 1:23 PM, Matthew Miller
 wrote:
> On Wed, Sep 14, 2016 at 04:44:38PM +, Debarshi Ray wrote:
>> (a) The maintenance status of a package is not a binary variable. It
>> is easy to imagine a third state - weakly maintained.
>
> Yes, THIS. Our current model does not really allow us to express this
> at all -- there's "orphaned", but that's not user-visible.

Our current model actually could express this though.  We could put
the weakly maintained packages in COPRs, and editions that wish to
include them can do so in their default repos.  There is also the
previous idea of the curated COPR playground.

We have the tools, we just need to use them.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Matthew Miller]

On Wed, Sep 14, 2016 at 04:44:38PM +, Debarshi Ray wrote:
> (a) The maintenance status of a package is not a binary variable. It
> is easy to imagine a third state - weakly maintained.

Yes, THIS. Our current model does not really allow us to express this
at all -- there's "orphaned", but that's not user-visible. 




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

[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: F24, small backward steps

[Kevin Fenzi]

On Wed, 14 Sep 2016 11:43:31 -0500
Michael Catanzaro  wrote:

> On Wed, 2016-09-14 at 08:33 +0200, Jakub Filak wrote:
> > Does GNOME Bugzilla support XMLRPC? Is there any testing instance
> > ABRT team
> > can play with?  
> 
> Yes and yes, but is XMLRPC being removed from upstream Bugzilla? I
> think I read that somewhere (but can't find a reference now when I
> search). It'd be a bad idea to use it if so.

They added a REST api in 5.0 and want people to move to that. 

"One big addition is a new REST-like endpoint alongside the existing
XML-RPC and JSON-RPC endpoints. This will allow clients to access
Bugzilla data using standard HTTP calls for easy development. Note:
XML-RPC and JSON-RPC are deprecated in favor of REST and will likely be
removed in the Bugzilla 7.0 release. "

> > One problem I can see is that Fedora users will have to register to
> > every
> > single upstream bug tracking tool. Using Red Hat Bugzilla as a proxy
> > to
> > upstream bug tracking tools is pretty convenient.  
> 
> I guess Launchpad-style comment proxying is probably too ambitious.

Note that hopefully with 5.0 we will have SAML auth, so if
bugzilla.gnome.org also picked that up (and other places) people could
just login with their Fedora account to all of them. 

kevin


pgpmnj29Nlssg.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)

[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: F24, small backward steps

[Michael Catanzaro]

On Wed, 2016-09-14 at 09:51 +0200, Pierre-Yves Chibon wrote:
> So, I'm going for the crazy idea front here, now that RHBZ is hooked
> onto
> fedmsg, should we try to write a tool creating bugs on GBZ for each
> gnome bugs
> created on RHBZ and sync comments between both instances? (well, we
> would have
> to see if we can get the GBZ onto a message bus of any sort)

This would be awesome, but someone has to implement it.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Debarshi Ray]

On Tue, Sep 13, 2016 at 04:24:02PM -0400, Stephen John Smoogen wrote:
> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
> 
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.
> 3. If someone isn't going to read the bugzillas why do we even have
> them in bugzilla or the distribution?

Because:

(a) The maintenance status of a package is not a binary variable. It
is easy to imagine a third state - weakly maintained.

(b) The maintenance activity can ebb and flow.

(c) Just because a package is unmaintained and has unattended bugs, it
doesn't mean that it isn't working in the majority of cases.

Sometimes I own a package (let's say) FOO simply because it is in the
dependency chain of something else that I am actively interested
in. At some point in the past, FOO was actively maintained, but that
changed over time. Now, I see the bugs accumulate, and every once in a
couple of cycles when I get some free time I try to go through some of
them. Sometimes somebody else steps up. And if we are lucky, then
things might again pick up in the future.

Yes, strictly speaking, we should remove FOO but that is often not
practical unless the functionality offered by FOO is not interesting
anymore, or there is a suitable replacement. Even if there is a
replacement, it might take a while to do the port (webkitgtk3/WebKit1
comes to mind).


pgpYkf9BBLaUb.pgp
Description: PGP 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)

[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: F24, small backward steps

[Ian Malone]

On 13 September 2016 at 21:24, Stephen John Smoogen  wrote:
> On 13 September 2016 at 16:03, Michael Catanzaro  wrote:

> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
>
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.

Sometimes an application can be working though upstream is dead and
keeping it going on a best-effort basis can provide some functionality
that wouldn't exist otherwise. Of course library churn and general
moving on of other technology will eventually kill it despite a
maintainer's best efforts. This doesn't apply for security issues
where providing software with known unpatched problems may be actively
harmful.



-- 
imalone
http://ibmalone.blogspot.co.uk
--
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

Re: F24, small backward steps

[Florian Weimer]

On 09/13/2016 07:44 PM, Josh Boyer wrote:


That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.


We could have a “Tire Fire” product besides the “Fedora” product in 
bugzilla.redhat.com, and move the GNOME components to this product, to 
make clear that these components are treated differently.


Florian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 01:20:06PM -0500, Michael Catanzaro wrote:
> On Tue, 2016-09-13 at 18:49 +0200, Pierre-Yves Chibon wrote:
> > If ABRT is a firehose of bugs flying to RH's bugzilla, would the
> > situation be
> > really better if the reports were sent to gnome's BZ?
> 
> Yes, it would. Keep in mind that upstream maintainers are responsible
> for far fewer packages than Fedora maintainers. A busy GNOME maintainer
> might maintain 2-5 packages upstream, but 20-50 Fedora packages (not
> counting comaintainence, then we're talking hundreds). It's a lot
> easier to look at crashes for 2-5 packages than 20-50 packages.

So, I'm going for the crazy idea front here, now that RHBZ is hooked onto
fedmsg, should we try to write a tool creating bugs on GBZ for each gnome bugs
created on RHBZ and sync comments between both instances? (well, we would have
to see if we can get the GBZ onto a message bus of any sort)

This would:
* allow bugs to be reported upstream where more people can look at them
* allow bugs to be reported upstream without the need for the original reporter
  to create yet another account on yet another BZ
* keep the discussion in both places
* eventually allow us to tweak things so that we try to report only bugs that
  are of interest
  (for example, we could start by reporting all the user-reported bugs, as
  opposed to those opened by automated tools (ABRT & others))

Call me crazy, but that was in essence my idea behind the question: `would 
things
be really better if the bugs were opened on GBZ?` and you replied `yes` :)


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 07:19 PM, Paul Wouters wrote:

On Tue, 13 Sep 2016, Ralf Corsepius wrote:


 This is a truly awful experiance from POV of a Fedora user filing
bugs :-(
 We've set a silent trap for them with no warning of the fact that their
 bug reports are going to be ignored until Fedora EOL procedure closes
 them :-(


One lesson I have learnt in Fedora, is that filing bugs reports
against packages owned by certain people equals to sending bugs to
/dev/null.

IMHO, Fedora should consider to take disciplinary measures against
these people.


And get less packagers?


Yes, why not? A non-responsive maintainer, who is systematically not 
processing the bugs having been filed against his packages in RHBZ is 
cheating himself, Fedora's users and the Fedora project. He is not doing 
his Fedora job.


To cut a long story short: Such a person is harmful to everyone being 
involved and therefore should be facing sanctions.



It would be useful if package co-owners would automatically get added to
the bugzilla bug, instead of only the package owner. Most packages don't
have dedicated aliases for that.

Urgh? I thought this was the case?

Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Jakub Filak]

On 09/13/2016 05:00 PM, Michael Catanzaro wrote:
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. 

That's why https://retrace.fedoraproject.org/faf/ exists.
Overloaded developers can focus on the hottest problems.

This link points to F24 and F25 hottest problems in components where Bastien
is in charge of maintenance:

https://retrace.fedoraproject.org/faf/problems/?opsysreleases=122=123=51


Jakub
ABRT
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 07:44 PM, Josh Boyer wrote:


That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.


IMO, it should be mandatory for Fedora maintainers to look into RH 
Bugzilla, because that's the product they are "maintaining" and what 
users are using.


Them not looking into RHBZ to me qualifies as them not doing their job 
as package maintainer.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Jakub Filak]

On 09/13/2016 06:32 PM, Bastien Nocera wrote:
> 
> 
> - Original Message -
> 
> 
> A couple of things could be done to help with that:
> - Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream 
> bugs

Does GNOME Bugzilla support XMLRPC? Is there any testing instance ABRT team
can play with?

One problem I can see is that Fedora users will have to register to every
single upstream bug tracking tool. Using Red Hat Bugzilla as a proxy to
upstream bug tracking tools is pretty convenient.

> - Make ABRT reports more useful (right now it's attaches a *lot* of extra
>   information, basically everything it can, as files). It's not possible
>   to search for parts of backtraces in the query tool.

Every ABRT report includes either 10 most relevant frames (so called
truncated backtrace) or entire backtrace if it's short enough.

We would love to make ABRT reports more useful. I am keen to hear
suggestions and ideas.


Jakub
ABRT
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Peter Hutterer]

On Fri, Sep 09, 2016 at 03:53:06PM -0400, Roger Wells wrote:
> Just a couple of smallish things after upgrading (via dnf) from F23 to
> F24 a couple of months ago:
> 
> 1. deja-dup gui:
> 
> one has to deselect then reselect the Overview option in order
> to be offered the "Backup Now" option.
> 
> The details option in the progress dialog will only display two
> or three lines, is not resizeable, and does not follow resizing the
> entire dialog
> 
> The progress dialog does not wait to be dismissed at the end,
> causing any messages about problems (like failure to backup a particular
> file) to not be seen
> 
> 2. fingerprint identification:
> 
> The laptop has a fingerprint reader and it works fine.  However
> I prefer not to use it. The user set up specifies that fingerprint login
> is disabled.
> 
> However whenever I am asked for a password the fingerprint
> reader blinks until I swipe a finger over it (even after using a
> password). 
> 
> No fingerprint is registered.
> 
> This is different than F23 where it never blinked.
> 
> 3. Scrolling issues:
> 
> This, edge and natural scrolling via the touchpad, was covered
> nicely in a previous thread. 
> 
> Solutions offered there work well but should be better
> integrated as I am sure they will be.

what was the problem here? can you point me to the original thread?

Cheers,
   Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 14:46 -0700, Adam Williamson wrote:
> 
> I'm not sure it really is unmaintained. There was 34.2 release this
> April, by the looks of things.
> 
> http://koji.fedoraproject.org/koji/packageinfo?packageID=10035

Aaaand I do see it in Software now. At long last!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Adam Williamson]

On Tue, 2016-09-13 at 17:17 -0400, Roger Wells wrote:
> 
> if it is unmaintained why does its GUI operation change between Fedora
> versions?

I'm not sure it really is unmaintained. There was 34.2 release this
April, by the looks of things.

http://koji.fedoraproject.org/koji/packageinfo?packageID=10035
-- 
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: F24, small backward steps

[Kevin Fenzi]

On Tue, 13 Sep 2016 15:03:28 -0500
Michael Catanzaro  wrote:

> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
> > It was the first problem, the one with deja-dup  
> 
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
> 
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea

FYI, I fixed the visibility in gnome-software a while back and the
maintainer applied my patches. 

https://bugzilla.redhat.com/show_bug.cgi?id=1237364

kevin


pgpXYZkVN0YLj.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Notifying co-maintainers about bug reports (was: F24, small backward steps)

[Björn Persson]

Pierre-Yves Chibon wrote:
> Everyone having `watchbugzilla` on a package is automatically cc'ed
> to the bug reports.
> In the early days of pkgdb2, I had it be: everyone with
> `watchbugzilla` or `commit` but I was asked to remove that last
> condition [1].

Would it be possible to show that information in the web interface?
Explain what effects the various privileges have, and what effects they
don't have, so that co-maintainers can predict whether they will notice
when bugs are reported.

I'm surprised to learn that I won't notice bug reports to packages I co-
maintain. I've been assuming that "commit" implied "watchbugzilla" and
"watchcommits", because I thought that made sense. Apparently you also
thought so originally.

I see a link to documentation for sysadmins and developers, but in a few
minutes of searching I didn't find any explanations of the privileges
there. I don't see anything that explains the web interface to users.

Björn Persson


pgpu2gi_XbAgM.pgp
Description: OpenPGP digital signatur
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 04:03 PM, Michael Catanzaro wrote:
> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>> It was the first problem, the one with deja-dup
> 
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
> 
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea
> 
if it is unmaintained why does its GUI operation change between Fedora
versions?

> Michael
> 
> [1] https://bugs.launchpad.net/deja-dup
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Chris Murphy]

On Tue, Sep 13, 2016 at 2:24 PM, Stephen John Smoogen  wrote:
> On 13 September 2016 at 16:03, Michael Catanzaro  wrote:
>> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>>> It was the first problem, the one with deja-dup
>>
>> Where did you report the bug? The upstream bug tracker is [1]. If you
>> reported it somewhere else, of course you'd be told it's the wrong
>> place
>>
>> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
>> not likely to result in fixes. It's not even user-visible, for many
>> years, now due to some problem with the appdata file. But there's no
>> chance of a fix if the issue isn't reported, so still a good idea
>>
>
> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
>
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.
> 3. If someone isn't going to read the bugzillas why do we even have
> them in bugzilla or the distribution?


Yeah really, I thought this is what orphaned means?


-- 
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Stephen John Smoogen]

On 13 September 2016 at 16:03, Michael Catanzaro  wrote:
> On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
>> It was the first problem, the one with deja-dup
>
> Where did you report the bug? The upstream bug tracker is [1]. If you
> reported it somewhere else, of course you'd be told it's the wrong
> place
>
> Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
> not likely to result in fixes. It's not even user-visible, for many
> years, now due to some problem with the appdata file. But there's no
> chance of a fix if the issue isn't reported, so still a good idea
>

OK this is the most frustrating of a TON of frustrating parts of this
conversation.

1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
2. Why are people 'maintainers' of such packages if they know upstream
is dead and they aren't going to maintain things.
3. If someone isn't going to read the bugzillas why do we even have
them in bugzilla or the distribution?

I am saying this from the point of view that we have put various
people in no-win situations and then set them up to fight each other.
A. The developer who  has to watch N packages that they can't
maintain, don't want to maintain, and are going to ignore.
B. The user who gets told to file a bug which is never going to be looked at.

The only person who is making anything here is the Press person who
gets to write a yearly "Why is Fedora so messed up yet again?"

Either maintain and watch a package and its bugs or don't. If you
can't watch more than 5 packages.. then watch those packages and drop
the rest. If the f'ing distro drops down to 200 packages then we can
at least say we know those 200 are maintainable and the OS is usable.
Then we can ship snappacks of the rest of the software that the user
can have a nice big button saying "good luck"


> Michael
>
> [1] https://bugs.launchpad.net/deja-dup
> --
> 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

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 14:33 -0400, Roger Wells wrote:
> It was the first problem, the one with deja-dup

Where did you report the bug? The upstream bug tracker is [1]. If you
reported it somewhere else, of course you'd be told it's the wrong
place

Unfortunately, I think deja-dup is unmaintained, so reporting bugs is
not likely to result in fixes. It's not even user-visible, for many
years, now due to some problem with the appdata file. But there's no
chance of a fix if the issue isn't reported, so still a good idea

Michael

[1] https://bugs.launchpad.net/deja-dup
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 12:31 PM, Bastien Nocera wrote:
> For which one of the problems you listed? It would certainly have been 
> interesting to list those in your original mail.
It was the first problem, the one with deja-dup
> 
> - Original Message -
>> On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
>>> On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
 Hi,

 To be clear, the problem is that a small handful of package maintainers
 (including Bastien) are collectively "responsible" for all of the GNOME
 and freedesktop components in Fedora (including fprintd), and it's
 simply not reasonable to expect them to read all the bugs that are
 assigned to them, let alone take the time to forward them upstream. If
 you use Red Hat Bugzilla, the right developers may never notice your
 bug report at all.

 You have a much better chance filing bugs upstream. You should only use
 Red Hat Bugzilla for these components if you happen to know there is a
 specific maintainer who actually looks at the Red Hat bugs for that
 specific component, or if you're planning to propose it as a release
 blocker, or if you just don't care whether anybody sees your bug. If
 you have a packaging bug then it's the right place, but please ping
 someone to be sure it gets noticed.

 Of course this is not how Bugzilla is intended to work, but it is how
 it actually works for GNOME stuff. It's unfortunate, but without some
 Launchpad-style automatic bug forwarding, this is going to remain the
 case indefinitely.
>>>
>>> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
>>> We've set a silent trap for them with no warning of the fact that their
>>> bug reports are going to be ignored until Fedora EOL procedure closes
>>> them :-(
>>>
>>> Even if we can't enhance Red hat Bugzilla, we can at least do more to
>>> alert users to this so they stand a chance of doing the right thing.
>>>
>>> eg, update the component description to tell user to file in GNOME
>>> bugzilla instead, and have a bot that adds a comment to any new bugs
>>> that are still filed, closing them WONTFIX and asking the user to
>>> re-open against upstream GNOME bugzilla, instead of leaving the bug
>>> open and ignored until Fedora EOL.
>>>
>>> Regards,
>>> Daniel
>>>
>> Thanks for recognizing this.  I am the OP.  I pretty quickly got a
>> response suggesting that I file a bug report "upstream".  I did that, or
>> so I thought, and immediately got a response from someone that it was
>> the wrong place or list followed by another declaring the matter closed.
>> I went back to my day job.
>>
>>
>> --
>> Roger Wells, P.E.
>> leidos
>> 221 Third St
>> Newport, RI 02840
>> 401-847-4210 (voice)
>> 401-849-1585 (fax)
>> roger.k.we...@leidos.com
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

On Tue, 2016-09-13 at 18:49 +0200, Pierre-Yves Chibon wrote:
> If ABRT is a firehose of bugs flying to RH's bugzilla, would the
> situation be
> really better if the reports were sent to gnome's BZ?

Yes, it would. Keep in mind that upstream maintainers are responsible
for far fewer packages than Fedora maintainers. A busy GNOME maintainer
might maintain 2-5 packages upstream, but 20-50 Fedora packages (not
counting comaintainence, then we're talking hundreds). It's a lot
easier to look at crashes for 2-5 packages than 20-50 packages.

Now, it's not going to make things perfect. Some GNOME maintainers
don't look at upstream bugs either (but that's comparatively rare). And
many packages are just totally unmaintained. But for most components,
it would be a big improvement to file the bugs upstream where the right
maintainers will see it.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 01:19:04PM -0400, Paul Wouters wrote:
> On Tue, 13 Sep 2016, Ralf Corsepius wrote:
> 
> > >  This is a truly awful experiance from POV of a Fedora user filing bugs 
> > > :-(
> > >  We've set a silent trap for them with no warning of the fact that their
> > >  bug reports are going to be ignored until Fedora EOL procedure closes
> > >  them :-(
> > 
> > One lesson I have learnt in Fedora, is that filing bugs reports against
> > packages owned by certain people equals to sending bugs to /dev/null.
> > 
> > IMHO, Fedora should consider to take disciplinary measures against these
> > people.
> 
> And get less packagers?
> 
> It would be useful if package co-owners would automatically get added to
> the bugzilla bug, instead of only the package owner. Most packages don't
> have dedicated aliases for that.

Everyone having `watchbugzilla` on a package is automatically cc'ed to the bug
reports.
In the early days of pkgdb2, I had it be: everyone with `watchbugzilla` or
`commit` but I was asked to remove that last condition [1].

[1] https://fedorahosted.org/pkgdb2/ticket/10


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Josh Boyer]

On Tue, Sep 13, 2016 at 11:00 AM, Michael Catanzaro
 wrote:
> Hi,
>
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
>
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release

That is the crux of the problem with this approach.  It is impossible
for a user to determine which packages have maintainers that look in
RH Bugzilla and which do not.

josh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Paul Wouters]

On Tue, 13 Sep 2016, Ralf Corsepius wrote:


 This is a truly awful experiance from POV of a Fedora user filing bugs :-(
 We've set a silent trap for them with no warning of the fact that their
 bug reports are going to be ignored until Fedora EOL procedure closes
 them :-(


One lesson I have learnt in Fedora, is that filing bugs reports against 
packages owned by certain people equals to sending bugs to /dev/null.


IMHO, Fedora should consider to take disciplinary measures against these 
people.


And get less packagers?

It would be useful if package co-owners would automatically get added to
the bugzilla bug, instead of only the package owner. Most packages don't
have dedicated aliases for that.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 12:32:20PM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> 
> > This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> > We've set a silent trap for them with no warning of the fact that their
> > bug reports are going to be ignored until Fedora EOL procedure closes
> > them :-(
> > 
> > Even if we can't enhance Red hat Bugzilla, we can at least do more to
> > alert users to this so they stand a chance of doing the right thing.
> > 
> > eg, update the component description to tell user to file in GNOME
> > bugzilla instead, and have a bot that adds a comment to any new bugs
> > that are still filed, closing them WONTFIX and asking the user to
> > re-open against upstream GNOME bugzilla, instead of leaving the bug
> > open and ignored until Fedora EOL.
> 
> A couple of things could be done to help with that:
> - Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream 
> bugs
> - Make ABRT reports more useful (right now it's attaches a *lot* of extra
>   information, basically everything it can, as files). It's not possible
>   to search for parts of backtraces in the query tool.
> - More useful templates when filing bugs, explaining where to file RFEs and
>   non-packaging bugs. As (for GNOME and a lot of other tools) we simply
>   package upstream, it would be most better to point directly to the
>   right place to file bugs.

If ABRT is a firehose of bugs flying to RH's bugzilla, would the situation be
really better if the reports were sent to gnome's BZ?

I believe ABRT has the possibility to not send report for some application,
would it make more sense to just stop sending these reports then?
If no-one looks at them and all they do is clutter the BZ and give our user a
sense of being neglected, is it really interested?

Maybe we could list all the GNOME components and block all of which where ABRT
is more deleterious than beneficial?
Ideally, I guess we should revisit this list periodically to check with
maintainers if they still wish to be on that list or if they wish to give ABRT a
try again.


Food for thoughts :)
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> Could you elaborate a little on your reasoning/thoughts please?
> 
> I am quite interesting to understand your point of view.
> From where I stand, we are offering a way for someone to unlock someone's
> else
> computer without a password.
> I understand the procedure isn't straight forward:
> - Find unattended and unlocked laptop
> - Enroll your fingerprint
> - Gain access to the computer whenever you want
> 
> I do realise that to do the second step you need access to the machine, which
> is
> pretty much the third step.
> But enrolling your fingerprint is likely less noticeable by the owner of the
> machine then, say, changing their password (which actually asks for the
> current
> password first), but will give you want you ask: permanent access to the
> machine
> (physically).

Password prompts in GNOME do mention that the fingerprint reader is activated, 
so
it's not so much opening a backdoor as opening the bay window next to the front
door.

> This is all nicely theoretical but it still seems like something that should
> be
> fixed, no?

It keeps slipping by, and it's not super important, which is the reason why it
keeps getting forgotten.

I'll get to it next time I do maintenance on fprintd.

Cheers
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> - Original Message -
> > I'm seeing 24 bugs at:
> > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > including a potential security one: https://bugzilla.redhat.com/1333882
> 
> Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> that abundantly clear I think.

I said "garbage fire" when I meant "tire fire". It keeps on burning and I'm
too lazy/busy to handle those bugs downstream when the majority of the work,
triaging and discussions happen upstream.

I should also note that the Red Hat bugzilla is far too coarse for handling
split-up projects like gnome-control-center and gnome-settings-daemon, both of
which are connected to multiple system layers (the kernel, systemd, a lot
of specialised daemons, windowing systems, and their dependencies) and which
have separate maintainers upstream.

Apologies again for the vocabulary used.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

For which one of the problems you listed? It would certainly have been 
interesting to list those in your original mail.

- Original Message -
> On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
> > On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> >> Hi,
> >>
> >> To be clear, the problem is that a small handful of package maintainers
> >> (including Bastien) are collectively "responsible" for all of the GNOME
> >> and freedesktop components in Fedora (including fprintd), and it's
> >> simply not reasonable to expect them to read all the bugs that are
> >> assigned to them, let alone take the time to forward them upstream. If
> >> you use Red Hat Bugzilla, the right developers may never notice your
> >> bug report at all.
> >>
> >> You have a much better chance filing bugs upstream. You should only use
> >> Red Hat Bugzilla for these components if you happen to know there is a
> >> specific maintainer who actually looks at the Red Hat bugs for that
> >> specific component, or if you're planning to propose it as a release
> >> blocker, or if you just don't care whether anybody sees your bug. If
> >> you have a packaging bug then it's the right place, but please ping
> >> someone to be sure it gets noticed.
> >>
> >> Of course this is not how Bugzilla is intended to work, but it is how
> >> it actually works for GNOME stuff. It's unfortunate, but without some
> >> Launchpad-style automatic bug forwarding, this is going to remain the
> >> case indefinitely.
> > 
> > This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> > We've set a silent trap for them with no warning of the fact that their
> > bug reports are going to be ignored until Fedora EOL procedure closes
> > them :-(
> > 
> > Even if we can't enhance Red hat Bugzilla, we can at least do more to
> > alert users to this so they stand a chance of doing the right thing.
> > 
> > eg, update the component description to tell user to file in GNOME
> > bugzilla instead, and have a bot that adds a comment to any new bugs
> > that are still filed, closing them WONTFIX and asking the user to
> > re-open against upstream GNOME bugzilla, instead of leaving the bug
> > open and ignored until Fedora EOL.
> > 
> > Regards,
> > Daniel
> > 
> Thanks for recognizing this.  I am the OP.  I pretty quickly got a
> response suggesting that I file a bug report "upstream".  I did that, or
> so I thought, and immediately got a response from someone that it was
> the wrong place or list followed by another declaring the matter closed.
> I went back to my day job.
> 
> 
> --
> Roger Wells, P.E.
> leidos
> 221 Third St
> Newport, RI 02840
> 401-847-4210 (voice)
> 401-849-1585 (fax)
> roger.k.we...@leidos.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

Couldn't have put it better, thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 12:24:33PM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> > > 
> > > 
> > > - Original Message -
> > > > I'm seeing 24 bugs at:
> > > > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > > > including a potential security one: https://bugzilla.redhat.com/1333882
> > > 
> > > Fedora's bugzilla is a garbage fire as far as I'm concerned. I already 
> > > made
> > > that abundantly clear I think.
> > 
> > Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
> > https://bugzilla.redhat.com/1305770 which mentions:
> > ``
> > Upstream bug:
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=89407
> > ``
> > 
> > and:
> > ``
> > This issue has been reported as far back as 2011:
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=651196
> > ``
> > 
> > So, you may not care about Red Hat bugzilla, but there is a security bug
> > issued
> > in there for more than 6 months and which is referencing a bug "upstreamed"
> > for
> > 5 years.
> 
> Which I don't consider to be a security bug, hence the reason why I didn't 
> touch it.

Could you elaborate a little on your reasoning/thoughts please?

I am quite interesting to understand your point of view.
From where I stand, we are offering a way for someone to unlock someone's else
computer without a password.
I understand the procedure isn't straight forward:
- Find unattended and unlocked laptop
- Enroll your fingerprint
- Gain access to the computer whenever you want

I do realise that to do the second step you need access to the machine, which is
pretty much the third step.
But enrolling your fingerprint is likely less noticeable by the owner of the
machine then, say, changing their password (which actually asks for the current
password first), but will give you want you ask: permanent access to the machine
(physically).

This is all nicely theoretical but it still seems like something that should be
fixed, no?


Thanks,
Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -

> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> We've set a silent trap for them with no warning of the fact that their
> bug reports are going to be ignored until Fedora EOL procedure closes
> them :-(
> 
> Even if we can't enhance Red hat Bugzilla, we can at least do more to
> alert users to this so they stand a chance of doing the right thing.
> 
> eg, update the component description to tell user to file in GNOME
> bugzilla instead, and have a bot that adds a comment to any new bugs
> that are still filed, closing them WONTFIX and asking the user to
> re-open against upstream GNOME bugzilla, instead of leaving the bug
> open and ignored until Fedora EOL.

A couple of things could be done to help with that:
- Bring back the x-bugzilla .desktop metadata, and have ABRT file upstream bugs
- Make ABRT reports more useful (right now it's attaches a *lot* of extra
  information, basically everything it can, as files). It's not possible
  to search for parts of backtraces in the query tool.
- More useful templates when filing bugs, explaining where to file RFEs and
  non-packaging bugs. As (for GNOME and a lot of other tools) we simply
  package upstream, it would be most better to point directly to the
  right place to file bugs.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> > 
> > 
> > - Original Message -
> > > I'm seeing 24 bugs at:
> > > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > > including a potential security one: https://bugzilla.redhat.com/1333882
> > 
> > Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> > that abundantly clear I think.
> 
> Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
> https://bugzilla.redhat.com/1305770 which mentions:
> ``
> Upstream bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=89407
> ``
> 
> and:
> ``
> This issue has been reported as far back as 2011:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=651196
> ``
> 
> So, you may not care about Red Hat bugzilla, but there is a security bug
> issued
> in there for more than 6 months and which is referencing a bug "upstreamed"
> for
> 5 years.

Which I don't consider to be a security bug, hence the reason why I didn't 
touch it.

> To me it looks like there is something in your "garbage" that needs a little
> attention.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Rich Mattes]

On Tue, Sep 13, 2016 at 11:43 AM, Ralf Corsepius  wrote:
> On 09/13/2016 05:09 PM, Daniel P. Berrange wrote:
>
>> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
>> We've set a silent trap for them with no warning of the fact that their
>> bug reports are going to be ignored until Fedora EOL procedure closes
>> them :-(
>
>
> One lesson I have learnt in Fedora, is that filing bugs reports against
> packages owned by certain people equals to sending bugs to /dev/null.
>
> IMHO, Fedora should consider to take disciplinary measures against these
> people.
>
> Ralf
>

For what it's worth, there are a set of Package Maintainer
Responsibilities[1] on the wiki.  The section "Deal with reported bugs
in a timely manner" does offer suggestions for what to do if you find
yourself unable to handle bug reports, but there's no discussion of
what to do when a package maintainer is not living up to these
responsibilities.  I agree that it would be good to try to outline an
approach to address cases where a package maintainer is not honoring
these responsibilities, would a FESCo ticket be the correct forum?

Rich

[1] https://fedoraproject.org/wiki/Package_maintainer_responsibilities
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Ralf Corsepius]

On 09/13/2016 05:09 PM, Daniel P. Berrange wrote:


This is a truly awful experiance from POV of a Fedora user filing bugs :-(
We've set a silent trap for them with no warning of the fact that their
bug reports are going to be ignored until Fedora EOL procedure closes
them :-(


One lesson I have learnt in Fedora, is that filing bugs reports against 
packages owned by certain people equals to sending bugs to /dev/null.


IMHO, Fedora should consider to take disciplinary measures against these 
people.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Roger Wells]

On 09/13/2016 11:09 AM, Daniel P. Berrange wrote:
> On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
>> Hi,
>>
>> To be clear, the problem is that a small handful of package maintainers
>> (including Bastien) are collectively "responsible" for all of the GNOME
>> and freedesktop components in Fedora (including fprintd), and it's
>> simply not reasonable to expect them to read all the bugs that are
>> assigned to them, let alone take the time to forward them upstream. If
>> you use Red Hat Bugzilla, the right developers may never notice your
>> bug report at all.
>>
>> You have a much better chance filing bugs upstream. You should only use
>> Red Hat Bugzilla for these components if you happen to know there is a
>> specific maintainer who actually looks at the Red Hat bugs for that
>> specific component, or if you're planning to propose it as a release
>> blocker, or if you just don't care whether anybody sees your bug. If
>> you have a packaging bug then it's the right place, but please ping
>> someone to be sure it gets noticed.
>>
>> Of course this is not how Bugzilla is intended to work, but it is how
>> it actually works for GNOME stuff. It's unfortunate, but without some
>> Launchpad-style automatic bug forwarding, this is going to remain the
>> case indefinitely.
> 
> This is a truly awful experiance from POV of a Fedora user filing bugs :-(
> We've set a silent trap for them with no warning of the fact that their
> bug reports are going to be ignored until Fedora EOL procedure closes
> them :-(
> 
> Even if we can't enhance Red hat Bugzilla, we can at least do more to
> alert users to this so they stand a chance of doing the right thing.
> 
> eg, update the component description to tell user to file in GNOME
> bugzilla instead, and have a bot that adds a comment to any new bugs
> that are still filed, closing them WONTFIX and asking the user to
> re-open against upstream GNOME bugzilla, instead of leaving the bug
> open and ignored until Fedora EOL.
> 
> Regards,
> Daniel
> 
Thanks for recognizing this.  I am the OP.  I pretty quickly got a
response suggesting that I file a bug report "upstream".  I did that, or
so I thought, and immediately got a response from someone that it was
the wrong place or list followed by another declaring the matter closed.
I went back to my day job.


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Daniel P. Berrange]

On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

This is a truly awful experiance from POV of a Fedora user filing bugs :-(
We've set a silent trap for them with no warning of the fact that their
bug reports are going to be ignored until Fedora EOL procedure closes
them :-(

Even if we can't enhance Red hat Bugzilla, we can at least do more to
alert users to this so they stand a chance of doing the right thing.

eg, update the component description to tell user to file in GNOME
bugzilla instead, and have a bot that adds a comment to any new bugs
that are still filed, closing them WONTFIX and asking the user to
re-open against upstream GNOME bugzilla, instead of leaving the bug
open and ignored until Fedora EOL.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Michael Catanzaro]

Hi,

To be clear, the problem is that a small handful of package maintainers
(including Bastien) are collectively "responsible" for all of the GNOME
and freedesktop components in Fedora (including fprintd), and it's
simply not reasonable to expect them to read all the bugs that are
assigned to them, let alone take the time to forward them upstream. If
you use Red Hat Bugzilla, the right developers may never notice your
bug report at all.

You have a much better chance filing bugs upstream. You should only use
Red Hat Bugzilla for these components if you happen to know there is a
specific maintainer who actually looks at the Red Hat bugs for that
specific component, or if you're planning to propose it as a release
blocker, or if you just don't care whether anybody sees your bug. If
you have a packaging bug then it's the right place, but please ping
someone to be sure it gets noticed.

Of course this is not how Bugzilla is intended to work, but it is how
it actually works for GNOME stuff. It's unfortunate, but without some
Launchpad-style automatic bug forwarding, this is going to remain the
case indefinitely.

Michael
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 07:30:07AM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > I'm seeing 24 bugs at:
> > https://apps.fedoraproject.org/packages/fprintd/bugs/all
> > including a potential security one: https://bugzilla.redhat.com/1333882
> 
> Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
> that abundantly clear I think.

Well, https://bugzilla.redhat.com/1333882 is a security bug, blocking:
https://bugzilla.redhat.com/1305770 which mentions:
``
Upstream bug:

https://bugs.freedesktop.org/show_bug.cgi?id=89407
``

and:
``
This issue has been reported as far back as 2011:

https://bugzilla.gnome.org/show_bug.cgi?id=651196
``

So, you may not care about Red Hat bugzilla, but there is a security bug issued
in there for more than 6 months and which is referencing a bug "upstreamed" for
5 years.

To me it looks like there is something in your "garbage" that needs a little
attention.


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> I'm seeing 24 bugs at:
> https://apps.fedoraproject.org/packages/fprintd/bugs/all
> including a potential security one: https://bugzilla.redhat.com/1333882

Fedora's bugzilla is a garbage fire as far as I'm concerned. I already made
that abundantly clear I think.

> so I'm not sure what you call 'upstream bugs' but there are bugs reported
> against fprintd.

By upstream, I mean upstream. That's https://bugs.freedesktop.org for fprintd.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Pierre-Yves Chibon]

On Tue, Sep 13, 2016 at 07:05:32AM -0400, Bastien Nocera wrote:
> 
> 
> - Original Message -
> > 
> > 
> > Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> > > Just a couple of smallish things after upgrading (via dnf) from F23 to
> > > F24 a couple of months ago:
> > >
> > >
> > > 2. fingerprint identification:
> > >
> > > The laptop has a fingerprint reader and it works fine.  However
> > > I prefer not to use it. The user set up specifies that fingerprint login
> > > is disabled.
> > >
> > > However whenever I am asked for a password the fingerprint
> > > reader blinks until I swipe a finger over it (even after using a
> > > password).
> > >
> > > No fingerprint is registered.
> > >
> > > This is different than F23 where it never blinked.
> > >
> > >
> > 
> > 
> > If I am not mistaken "dnf remove fprintd-pam" should completely disable
> > the fingerprint reader, although you might observe some error messages
> > in your journal later.
> > 
> > But don't worry, the fprind daemon is broken for ages and nobody cares,
> > so it might work once, but then it crashes ...
> 
> There's no upstream bugs against fprintd specifically, so, like, you're wrong?

I'm seeing 24 bugs at:
https://apps.fedoraproject.org/packages/fprintd/bugs/all
including a potential security one: https://bugzilla.redhat.com/1333882

so I'm not sure what you call 'upstream bugs' but there are bugs reported
against fprintd.


Pierre
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Bastien Nocera]

- Original Message -
> 
> 
> Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> > Just a couple of smallish things after upgrading (via dnf) from F23 to
> > F24 a couple of months ago:
> >
> >
> > 2. fingerprint identification:
> >
> > The laptop has a fingerprint reader and it works fine.  However
> > I prefer not to use it. The user set up specifies that fingerprint login
> > is disabled.
> >
> > However whenever I am asked for a password the fingerprint
> > reader blinks until I swipe a finger over it (even after using a
> > password).
> >
> > No fingerprint is registered.
> >
> > This is different than F23 where it never blinked.
> >
> >
> 
> 
> If I am not mistaken "dnf remove fprintd-pam" should completely disable
> the fingerprint reader, although you might observe some error messages
> in your journal later.
> 
> But don't worry, the fprind daemon is broken for ages and nobody cares,
> so it might work once, but then it crashes ...

There's no upstream bugs against fprintd specifically, so, like, you're wrong?
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Vít Ondruch]

Dne 9.9.2016 v 21:53 Roger Wells napsal(a):
> Just a couple of smallish things after upgrading (via dnf) from F23 to
> F24 a couple of months ago:
>
>
> 2. fingerprint identification:
>
> The laptop has a fingerprint reader and it works fine.  However
> I prefer not to use it. The user set up specifies that fingerprint login
> is disabled.
>
> However whenever I am asked for a password the fingerprint
> reader blinks until I swipe a finger over it (even after using a
> password). 
>
> No fingerprint is registered.
>
> This is different than F23 where it never blinked.
>
>


If I am not mistaken "dnf remove fprintd-pam" should completely disable
the fingerprint reader, although you might observe some error messages
in your journal later.

But don't worry, the fprind daemon is broken for ages and nobody cares,
so it might work once, but then it crashes ...


Vít
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Adam Williamson]

On Fri, 2016-09-09 at 17:45 -0400, Roger Wells wrote:
> 
> Let me know if you think I should submit this upstream somewhere.

Probably to gnome-shell on bugzilla.gnome.org , I guess.
-- 
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: F24, small backward steps

[Roger Wells]

On 09/09/2016 04:44 PM, Adam Williamson wrote:
> On Fri, 2016-09-09 at 15:53 -0400, Roger Wells wrote:
>> Just a couple of smallish things after upgrading (via dnf) from F23 to
>> F24 a couple of months ago:
>>
>> 1. deja-dup gui:
>>
>> one has to deselect then reselect the Overview option in order
>> to be offered the "Backup Now" option.
>>
>> The details option in the progress dialog will only display two
>> or three lines, is not resizeable, and does not follow resizing the
>> entire dialog
>>
>> The progress dialog does not wait to be dismissed at the end,
>> causing any messages about problems (like failure to backup a particular
>> file) to not be seen
> 
> This really isn't anything particular to Fedora. deja-dup is just an
> app we ship. The appropriate place to report issues with it is to its
> upstream bug tracker.

Just did that.
> 
>> 2. fingerprint identification:
>>
>> The laptop has a fingerprint reader and it works fine.  However
>> I prefer not to use it. The user set up specifies that fingerprint login
>> is disabled.
>>
>> However whenever I am asked for a password the fingerprint
>> reader blinks until I swipe a finger over it (even after using a
>> password). 
>>
>> No fingerprint is registered.
>>
>> This is different than F23 where it never blinked.
> 
> This you should probably file a bug on (against, I guess, gnome-shell?
> But it depends a lot on the answer to my second question below...), but
> with a bit more detail. What exactly do you mean by "The user set up
> specifies that fingerprint login is disabled" - what "user set up" are
> you referring to exactly? When exactly does this happen - more detail
> on "whenever I am asked for a password". Thanks!

1. Press the button on the upper right corner of the Gnome desktop.
2. Press the settings button on the lower left of the menu
3. Select Users

On the resulting "Users" dialog one can select Fingerprint Login:
Disabled/Enabled

In my case it is Disabled

As far as when this occurs, at least:
1. at boot up login
2. after suspense login
and not
1. not when a browser asks for a password when visiting a site
2. when issuing a command using sudo, like mounting an external share

Once again, this did not occur on F23 and started as soon as I upgraded
to F24

Its no big deal.  We could do like windows 10 which just stops the
fingerprint reader when a password is entered.

Let me know if you think I should submit this upstream somewhere.

It feels like it may be similar to the scrolling problems mentioned that
seem be fixed after installing libinit and adjusting some configuration
files in /etc.  After doing that the Gnome "Mouse & Touchpad" settings
dialog (same place as the "Users" mentioned above) took on a whole new
meaningful life.

HTH,
thanks for your response

> 


-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Paul Wouters]

On Fri, 9 Sep 2016, Adam Williamson wrote:


2. fingerprint identification:

The laptop has a fingerprint reader and it works fine.  However
I prefer not to use it. The user set up specifies that fingerprint login
is disabled.

However whenever I am asked for a password the fingerprint
reader blinks until I swipe a finger over it (even after using a
password).

No fingerprint is registered.

This is different than F23 where it never blinked.


This you should probably file a bug on (against, I guess, gnome-shell?
But it depends a lot on the answer to my second question below...), but
with a bit more detail. What exactly do you mean by "The user set up
specifies that fingerprint login is disabled" - what "user set up" are
you referring to exactly? When exactly does this happen - more detail
on "whenever I am asked for a password". Thanks!


This happened to me too. I did not enable fingerprint based logins
(since half a dozen governments have my fingerprints) and whenever I
open my laptop or unlock the screensaver using a password, the green
fingerprint LED starts blinking. This did not happen on f23.

Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24, small backward steps

[Adam Williamson]

On Fri, 2016-09-09 at 15:53 -0400, Roger Wells wrote:
> Just a couple of smallish things after upgrading (via dnf) from F23 to
> F24 a couple of months ago:
> 
> 1. deja-dup gui:
> 
> one has to deselect then reselect the Overview option in order
> to be offered the "Backup Now" option.
> 
> The details option in the progress dialog will only display two
> or three lines, is not resizeable, and does not follow resizing the
> entire dialog
> 
> The progress dialog does not wait to be dismissed at the end,
> causing any messages about problems (like failure to backup a particular
> file) to not be seen

This really isn't anything particular to Fedora. deja-dup is just an
app we ship. The appropriate place to report issues with it is to its
upstream bug tracker.

> 2. fingerprint identification:
> 
> The laptop has a fingerprint reader and it works fine.  However
> I prefer not to use it. The user set up specifies that fingerprint login
> is disabled.
> 
> However whenever I am asked for a password the fingerprint
> reader blinks until I swipe a finger over it (even after using a
> password). 
> 
> No fingerprint is registered.
> 
> This is different than F23 where it never blinked.

This you should probably file a bug on (against, I guess, gnome-shell?
But it depends a lot on the answer to my second question below...), but
with a bit more detail. What exactly do you mean by "The user set up
specifies that fingerprint login is disabled" - what "user set up" are
you referring to exactly? When exactly does this happen - more detail
on "whenever I am asked for a password". Thanks!
-- 
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

F24, small backward steps

[Roger Wells]

Just a couple of smallish things after upgrading (via dnf) from F23 to
F24 a couple of months ago:

1. deja-dup gui:

one has to deselect then reselect the Overview option in order
to be offered the "Backup Now" option.

The details option in the progress dialog will only display two
or three lines, is not resizeable, and does not follow resizing the
entire dialog

The progress dialog does not wait to be dismissed at the end,
causing any messages about problems (like failure to backup a particular
file) to not be seen

2. fingerprint identification:

The laptop has a fingerprint reader and it works fine.  However
I prefer not to use it. The user set up specifies that fingerprint login
is disabled.

However whenever I am asked for a password the fingerprint
reader blinks until I swipe a finger over it (even after using a
password). 

No fingerprint is registered.

This is different than F23 where it never blinked.

3. Scrolling issues:

This, edge and natural scrolling via the touchpad, was covered
nicely in a previous thread. 

Solutions offered there work well but should be better
integrated as I am sure they will be.


Desktop is: gnome-desktop3-3.20.2-1.fc24.x86_64

laptop is Thinkpad X240 (Intel graphics)

Not to be a pita, just trying to help
I really like Fedora & the Gnome desktop

-- 
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.we...@leidos.com

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org