2:53 p.m.
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.wells(a)leidos.com
3:44 p.m.
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
4:39 p.m.
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
4:45 p.m.
On 09/09/2016 04:44 PM, Adam Williamson wrote:
--
Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells(a)leidos.com
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
4:56 p.m.
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
4:17 a.m.
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
6:05 a.m.
----- 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?
6:15 a.m.
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
6:30 a.m.
----- 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.
8:43 a.m.
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
11:24 a.m.
----- 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.
11:32 a.m.
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
11:49 a.m.
----- Original Message -----
<snip>
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
10 a.m.
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
10:09 a.m.
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 :|
10:26 a.m.
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.wells(a)leidos.com
11:31 a.m.
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.wells(a)leidos.com
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
1:33 p.m.
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.wells(a)leidos.com
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel(a)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.wells(a)leidos.com
3:03 p.m.
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
3:24 p.m.
On 13 September 2016 at 16:03, Michael Catanzaro <mcatanzaro(a)gnome.org> 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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
3:41 p.m.
On Tue, Sep 13, 2016 at 2:24 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 13 September 2016 at 16:03, Michael Catanzaro
<mcatanzaro(a)gnome.org> 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
11:09 a.m.
On 13 September 2016 at 21:24, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 13 September 2016 at 16:03, Michael Catanzaro
<mcatanzaro(a)gnome.org> 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
11:44 a.m.
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).
12:23 p.m.
On Wed, Sep 14, 2016 at 04:44:38PM +0000, 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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:27 p.m.
On Wed, Sep 14, 2016 at 1:23 PM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
On Wed, Sep 14, 2016 at 04:44:38PM +0000, 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
12:52 p.m.
New subject: How to handle "weakly maintained packages" [was Re: F24, small
backward steps]
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:25 p.m.
New subject: How to handle "weakly maintained packages" [was Re: F24, small
backward steps]
On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
<mattdm(a)fedoraproject.org> 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!
1:35 p.m.
New subject: How to handle "weakly maintained packages" [was Re: F24, small
backward steps]
On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
<mattdm(a)fedoraproject.org> 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
2:04 p.m.
New subject: How to handle "weakly maintained packages" [was Re: F24, small
backward steps]
On Wed, Sep 14, 2016 at 2:35 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Wed, Sep 14, 2016 at 2:25 PM, Neal Gompa
<ngompa13(a)gmail.com> wrote:
> On Wed, Sep 14, 2016 at 1:52 PM, Matthew Miller
> <mattdm(a)fedoraproject.org> 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!
4:17 p.m.
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(a)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.wells(a)leidos.com
4:46 p.m.
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
5:20 p.m.
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!
4:34 p.m.
On Tue, 13 Sep 2016 15:03:28 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> 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
10:43 a.m.
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
10:57 a.m.
On Tue, Sep 13, 2016 at 11:43 AM, Ralf Corsepius <rc040203(a)freenet.de> 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
12:19 p.m.
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
12:49 p.m.
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
4:33 p.m.
New subject: Notifying co-maintainers about bug reports (was: F24, small
backward steps)
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
2:46 a.m.
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
10:49 a.m.
On Tue, Sep 13, 2016 at 11:09 AM, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
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.
I don't think it's that easy. There's a whole class of bugs related
to packaging errors that do need to be dealt with by the Fedora
maintainer, and which don't make sense to send upstream.
Rich
11:32 a.m.
----- Original Message -----
<snip>
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.
11:49 a.m.
On Tue, Sep 13, 2016 at 12:32:20PM -0400, Bastien Nocera wrote:
----- Original Message -----
<snip>
> 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
1:20 p.m.
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
2:51 a.m.
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
11:47 a.m.
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
1:33 a.m.
On 09/13/2016 06:32 PM, Bastien Nocera wrote:
----- Original Message -----
<snip>
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
11:43 a.m.
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.
I don't remember the address of the testing instance, but it exists, we
can get you access.
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.
We would love to make ABRT reports more useful. I am keen to hear
suggestions and ideas.
I don't see a problem with the usefulness of the bug reports that we
get. ABRT always attaches a full backtrace of every thread. The reports
themselves are (almost always) good.
Michael
11:51 a.m.
On Wed, 14 Sep 2016 11:43:31 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> 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
11:32 a.m.
----- 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.
12:44 p.m.
On Tue, Sep 13, 2016 at 11:00 AM, Michael Catanzaro
<mcatanzaro(a)gnome.org> 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
1:57 a.m.
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
9:44 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24, small backward steps)
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> 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<
10:21 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 14 September 2016 at 10:44, Jason L Tibbitts III <tibbs(a)math.uh.edu> wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> 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(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
5:47 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, Sep 14, 2016 at 11:21:44AM -0400, Stephen John Smoogen wrote:
On 14 September 2016 at 10:44, Jason L Tibbitts III
<tibbs(a)math.uh.edu> 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&ops...
[2]
https://retrace.fedoraproject.org/faf/problems/bthash/?bth=2dc809f76a6e96...
[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
10:50 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> 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
11:24 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 09/14/2016 04:44 PM, Jason L Tibbitts III wrote:
>>>>>>
>>>>>> "RC" == Ralf Corsepius <rc040203(a)freenet.de>
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
11:47 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/14/2016 06:24 PM, Josh Boyer wrote:
On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius
<rc040203(a)freenet.de> 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
12:01 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, Sep 14, 2016 at 12:47 PM, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 09/14/2016 06:24 PM, Josh Boyer wrote:
>
> On Wed, Sep 14, 2016 at 11:50 AM, Ralf Corsepius <rc040203(a)freenet.de>
> 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
12:12 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, 14 Sep 2016 13:01:14 -0400
Josh Boyer <jwboyer(a)fedoraproject.org> 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
12:26 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/14/2016 07:01 PM, Josh Boyer wrote:
> My impression is, in many cases, it's ego, which prevents to
acknowledge
> they need "to divert".
I'm not sure what you mean by divert.
This is a Dinglish "politically correct" phrase to describe "to
partially give up/step down", "make room to others" and "hire more
people".
What I mean, if you feel being overloaded, be honest to your self and
"downsize" your tasks/duties.
Ralf
12:03 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream
>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.
A package with a million users is going to get more bugs than a package
with ten regardless of the package quality. I have a feeling that a
rather large number of people use Gnome.
- J<
12:18 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream
On 09/14/2016 07:03 PM, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.
A package with a million users is going to get more bugs than a package
with ten regardless of the package quality.
Not necessarily.
Certainly, a package with a large user group is likely to receive more
bug reports than a package with a small user group, but ...
... should be identical
... if this amount of reports doesn't decrease over time, it questions
this package as whole and upstream's course.
I have a feeling that a
rather large number of people use Gnome.
Whether this is true or not, I don't
know. The last figure I saw, Gnome
was at 30% of all Fedora users.
Ralf
1:06 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream
On 09/14/2016 05:03 PM, Jason L Tibbitts III wrote:
>>>>> "RC" == Ralf Corsepius
<rc040203(a)freenet.de> writes:
RC> - A package triggering too many BZs.
RC> IMO, this should question the package's quality.
A package with a million users is going to get more bugs than a package
with ten regardless of the package quality. I have a feeling that a
rather large number of people use Gnome.
Most of them would be duplicates ( otherwise Gnome is in serious trouble
maintenance wise )
When I was exclusively triaging reports against a single components
systemd for couple of years the report classification was roughly one
third real bugs, one third RFE's and one third misfiles.
With my former QA hat on and thus involved in the triage process from
it's inception as well as being the last person along with Mike Ruckman
( afaik no one else has done it since then) looking into if the triage
process could be revived for what the fourth time I think I can say
without a shadow of doubt that triaging will never work in the
distribution due to wide variety of reasons which I will not go into
details in this response. ( Triaging can be made to work to certain
extent but not here in Fedora )
In the end of the day it's packager maintainer(s) responsibility to act
as the liaison between upstream and downstream, triage, test and forward
bugs upstream if they are not distribution specific and solve them
downstream if they are.
If the package maintainer does not have the time to do that he or she
needs to find more co-maintainers to distribute the load of him or
herself or drop the maintenance of the package in the distribution
altogether and hope that someone else that has the required time steps
up to maintain it but that is unlikely if he or she could not find
co-maintainer(s) to begin with in the distribution to distribute the load.
If the above as in package maintainer(s) for whatever reasons will not
perform their due maintenance diligence then there is but two
alternative and that's to drop the poorly maintained packaged ( since
it's doing the distribution end user disservice ) or redirect reporters
directly upstream but that has it's own set of pros and cons.
JBG
11:44 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/14/2016 02:44 PM, Jason L Tibbitts III wrote:
I disagree in general; when the bug volume exceeds a certain amount
bugzilla basically becomes useless. However, it would be really nice if
_someone_ looked at RH bugzilla for those packages and did something
with them.
This responsibility falls under those individuals that have signed
themselves up with maintaining the component(s) in question in the
distribution and call themselves "package maintainers"...
JBG
12:46 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, Sep 14, 2016 at 09:44:06AM -0500, Jason L Tibbitts III wrote:
I disagree in general; when the bug volume exceeds a certain amount
bugzilla basically becomes useless. However, it would be really nice if
_someone_ looked at RH bugzilla for those packages and did something
with them.
We used to have "bugzappers". What we really need is someone to do
triage and to forward bugs on to upstream when appropriate. This
obviously requires volunteers.
What I'd _really_ love to see is a layer separating bug trackers from
end users. In IT, there's often a distinction made between "incidents"
and "problems"¹. An incident is Something Bad That Happened to A User;
this may be caused by one or more problems. (And a single problem may
cause multiple incidents.) In big IT shops, it's common to have
helpdesk tickets for incidents, and those may then get linked to bug
tickets on the backend. (Either user-visible or not, depending on the
culture.)
So, what if we steer end users away from Bugzilla and bug-trackers
completely² and to Ask Fedora³ instead? The triage team could
supplement the people already working there to help people with their
questions, and rather than linking bug trackers, we could create a tool
where high-rep users could push a button to 1) create a bug in the
appropriate one and 2) add an answer like:
"This looks like it's caused by a bug in $whatever. I've created a
ticket in the tracking system for that project, which you can see at
$link. If this is sufficient, feel free to mark this as accepted.
Otherwise, this will be updated as the underlying bug is worked on."
1. http://www.itskeptic.org/content/how-itil-gets-incident-vs-problem-wrong
2. To be more nuanced: we wouldn't shut it down for technical users,
which for this purpose I will definie as "users able to identify the
right bugzilla for a particular problem", but we would change all of
our end-user-facing documentation to recommend the help system
instead.
3. Or something like it. Ask Fedora could use some development work,
but that's another story.... :)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:39 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/14/2016 05:46 PM, Matthew Miller wrote:
What I'd_really_ love to see is a layer separating bug trackers
from
end users.
That layer already exist in the form of irc forum and askbot does it not?
( someone from the support sub-community can provide information how
successful these are )
And from my former QA days I cant recall that end users issues being
mistakenly reported in bugzilla existed in the first place or was a
problem for that matter.
( The steps that are necessary to file a report to begin with, act as a
natural filter that prevents that from happening )
I'm only aware of one bug ( arguably misfiled ) against systemd in the
distribution that might fall under that category but that is entirely
due to the fact those changes slipped through the distribution
documentation and announcement radar ( which arguably should have been
covered in Gnome ) so end users/administrators simply dont know how they
are custom to configure things does not work in certain scenarios with
certain components.
JBG
6:09 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Wed, Sep 14, 2016 at 01:46:53PM -0400, Matthew Miller wrote:
On Wed, Sep 14, 2016 at 09:44:06AM -0500, Jason L Tibbitts III
wrote:
> I disagree in general; when the bug volume exceeds a certain amount
> bugzilla basically becomes useless. However, it would be really nice if
> _someone_ looked at RH bugzilla for those packages and did something
> with them.
>
> We used to have "bugzappers". What we really need is someone to do
> triage and to forward bugs on to upstream when appropriate. This
> obviously requires volunteers.
What I'd _really_ love to see is a layer separating bug trackers from
end users. In IT, there's often a distinction made between "incidents"
and "problems"¹. An incident is Something Bad That Happened to A User;
this may be caused by one or more problems. (And a single problem may
cause multiple incidents.) In big IT shops, it's common to have
helpdesk tickets for incidents, and those may then get linked to bug
tickets on the backend. (Either user-visible or not, depending on the
culture.)
So, what if we steer end users away from Bugzilla and bug-trackers
completely² and to Ask Fedora³ instead? The triage team could [...]
But there's no triage team. Adding another layer of indirection without
a dedicated new workforce would likely just divert resources away
from the existing bug fixing process.
Zbyszek
7:31 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Thu, 2016-09-15 at 23:09 +0000, 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
9:01 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Thu, Sep 15, 2016 at 05:31:31PM -0700, Adam Williamson wrote:
> > So, what if we steer end users away from Bugzilla and
bug-trackers
> > completely² and to Ask Fedora³ instead? The triage team could [...]
> But there's no triage team. Adding another layer of indirection without
> a dedicated new workforce would likely just divert resources away
> from the existing bug fixing process.
And before anyone asks - we've tried to have a triage team several
times and it has never really worked so far. It's a hard and relatively
Right, so, this is part of the context for my idea above. There *isn't*
a triage team, but there *is* a community around Ask Fedora, and we
could build from that. It wouldn't be the same at all as previous
efforts to "bugzilla-garden"
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9:44 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, 16 Sep 2016 10:01:30 -0400
Matthew Miller <mattdm(a)fedoraproject.org> 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
10:05 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, Sep 16, 2016 at 10:01 AM, Matthew Miller
<mattdm(a)fedoraproject.org> 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
11:42 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, 16 Sep 2016 10:01:30 -0400
Matthew Miller <mattdm(a)fedoraproject.org> 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?
12:19 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote:
On Fri, 16 Sep 2016 10:01:30 -0400
Matthew Miller <mattdm(a)fedoraproject.org> 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
12:27 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, 2016-09-16 at 17:19 +0000, 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
1:53 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, 16 Sep 2016 12:27:30 -0500
Michael Catanzaro <mcatanzaro(a)gnome.org> 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.
5:16 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 17/09/16 03:27, Michael Catanzaro wrote:
On Fri, 2016-09-16 at 17:19 +0000, 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
7:04 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Mon, 2016-09-19 at 08:16 +1000, Jeff Fearn wrote:
Hi, we might be able to extend the External Trackers extension in RH
Bugzilla to be able to create as
well as sync bugs.
We've shared the code with upstream to see if they like our approach
so far.
Fedora is our biggest user community, so we can certainly make some
Fedora specific changes to RH
Bugzilla should it be required.
That would be awesome!
Michael
5:27 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 09/18/2016 10:16 PM, Jeff Fearn wrote:
Hi, we might be able to extend the External Trackers extension in RH
Bugzilla to be able to create as
well as sync bugs.
Between which issue trackers is that supported?
JBG
5:48 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 19/09/16 20:27, Jóhann B. Guðmundsson wrote:
On 09/18/2016 10:16 PM, Jeff Fearn wrote:
> Hi, we might be able to extend the External Trackers extension in RH Bugzilla to be
able to create as
> well as sync bugs.
Between which issue trackers is that supported?
Currently, Bugzilla, Jira, and Salesforce.
Cheers, Jeff.
--
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
1:50 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, 16 Sep 2016 17:19:24 +0000
Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> 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.
6:03 p.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On 17/09/16 03:19, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote:
> On Fri, 16 Sep 2016 10:01:30 -0400
> Matthew Miller <mattdm(a)fedoraproject.org> 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
8:49 a.m.
New subject: Triaging RH Bugzilla and forwarding bugs upstream (Was: F24,
small backward steps)
On Fri, Sep 16, 2016 at 09:42:07AM -0700, stan wrote:
Wouldn't it make more sense to have a way for package maintainers
to
decide if a bug was local or upstream, and a button they could push to
automatically send it upstream?
I really like Stan's idea. The root of this
problem lies in the
historical fact that most packages just did not have issue tracking, so
Fedora and Bugzilla stepped in to orchestrate it on a distribution
level. This works splendidly, if God's willing and creeks don't rise: I
have a personal experience of submitting a bug, then a fix, and seeing a
fixed package enter the main distribution repository within a week or
so, fixing the problem for the entire world including myself. That's why
I still believe that Bugzilla is the default place to report the issues,
followed by coordination with the upstream, of course.
On the other hand, if the submitter and/or the Fedora packager can't
deliver the fix, the issues will linger; in that case upstream is really
where they should migrate to.
On 09/16/2016 01:19 PM, Zbigniew Jędrzejewski-Szmek wrote:
Automatically? If I receive a bug upstream, I want to receive it
without the distribution's embellishments: I want to know what
*upstream* version of the software was used, how I can reproduce the
bug using generic installation from sources, and not using the distro
package, etc. Also, I don't want to read the full history on the
distribution bugtracker, I want to see a concise summary of findings.
I want to see an explanation why the bug is an upstream bug, not a
distro-specific thing. The person who is forwarding bugs has to all of
this by hand, and doing this automatically is infeasible.
The better is the enemy
of the good. You're right that it would be ideal
if upstream got a cleaned up report along the lines you suggested, but
the automatic upstream report could essentially link to the Bugzilla
entry, which hopefully contains basic setup and reproducibility
information---at the very least it registers the issue and establishes
communication channel between the upstream developer and Fedora-based
reporter.
When I run into issues, I tend to follow the original Bugzilla entry
with a second comment that at least provides a stack dump showing the
crash environment (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=1359395 ); abrt does this
automatically. I believe this is helpful to the upstream developers, as
they sometimes explicitly confirm.
The downside of course is we don't want to firehose upstream with an
endless stream of reports, but Stan's idea involves a manual step and
therefore should keep that under control.
3:13 a.m.
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
2:10 a.m.
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&ops...
Jakub
ABRT
11:41 a.m.
----- 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.
3:53 p.m.
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
11:45 p.m.
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
2772
days inactive
2794
days old
86 comments
28 participants
participants (28)
-
Adam Williamson -
Bastien Nocera -
Björn Persson -
Chris Murphy -
Daniel P. Berrange -
Debarshi Ray -
Florian Weimer -
Ian Malone -
Jakub Filak -
Jason L Tibbitts III -
Jeff Fearn -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Matthew Miller -
Michael Catanzaro -
Neal Gompa -
Paul Wouters -
Peter Hutterer -
Pierre-Yves Chibon -
Przemek Klosowski -
Ralf Corsepius -
Rich Mattes -
Roger Wells -
stan -
Stephen John Smoogen -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek