[Bug corefiles/28636] New: usability suggestions for debuginfod client

[Bug corefiles/28636] New: usability suggestions for debuginfod client

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

            Bug ID: 28636
           Summary: usability suggestions for debuginfod client
           Product: gdb
           Version: unknown
            Status: NEW
          Severity: normal
          Priority: P2
         Component: corefiles
          Assignee: unassigned at sourceware dot org
          Reporter: fche at redhat dot com
                CC: amerey at redhat dot com, simark at simark dot ca
  Target Milestone: ---

With the recently integrated (gdb) set debuginfod* changes, things look
different and better in some ways.  Some suggestions for (re)consideration:

1. defaulting to "set debuginfod off" for batch usage is kind of unfortunate. 
Programs that use gdb under the covers to do backtracing or whatever now would
start to require an extra gdb command option just to work as well as gdb 10
did.  I -think- that batch usage of gdb is LESS latency / comfort sensitive, so
maybe the default should be "on" for them rather than "off".

2. displaying "Downloading -0.00 MB separate debug info for ..." is confusing. 
Maybe the files came down too quickly, and the client didn't pass a late enough
progress callback.  (If so, perhaps we could fix that on the debuginfod side,
but I think the code there is good.  GDB should get a notification for the last
download completion packet.)  It'd be better to omit the number, or perhaps
replace it from an actual fstat st_size kind of number if necessary.

3. having "set debuginfod ask" be the default is fine for interactive users -
that was the whole point of the patchset.  But answering "y" is purely
transient, as opposed to one-time.  Could gdb append a setting to its own
.gdbinit file so that the "y" sticks?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/28636] usability suggestions for debuginfod client

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
(In reply to Frank Ch. Eigler from comment #0)
> With the recently integrated (gdb) set debuginfod* changes, things look
> different and better in some ways.  Some suggestions for (re)consideration:
> 
> 1. defaulting to "set debuginfod off" for batch usage is kind of
> unfortunate.  Programs that use gdb under the covers to do backtracing or
> whatever now would start to require an extra gdb command option just to work
> as well as gdb 10 did.  I -think- that batch usage of gdb is LESS latency /
> comfort sensitive, so maybe the default should be "on" for them rather than
> "off".

If I understood correctly the original request, defaulting to "no" was for
privacy reasons, making sure to get the user's opt-in before the tool contacts
an external server.  If so, this would be important regardless of whether the
usage is interactive or not.
cessary.

> 3. having "set debuginfod ask" be the default is fine for interactive users
> - that was the whole point of the patchset.  But answering "y" is purely
> transient, as opposed to one-time.  Could gdb append a setting to its own
> .gdbinit file so that the "y" sticks?

Is the message telling the user to add the comment to their .gdbinit not
enough?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/28636] usability suggestions for debuginfod client

[amerey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

--- Comment #2 from Aaron Merey <amerey at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #0)
> With the recently integrated (gdb) set debuginfod* changes, things look
> different and better in some ways.  Some suggestions for (re)consideration:
> 
> 1. defaulting to "set debuginfod off" for batch usage is kind of
> unfortunate.  Programs that use gdb under the covers to do backtracing or
> whatever now would start to require an extra gdb command option just to work
> as well as gdb 10 did.  I -think- that batch usage of gdb is LESS latency /
> comfort sensitive, so maybe the default should be "on" for them rather than
> "off".

We introduced a first-use notice and made it interactive because we wanted
to make sure users were sufficiently informed that they'd be relying on an
external service.  This was done at the expense of adding an extra step
(responding to a prompt) to enable debuginfod.

Does this rational also apply to batch usage?  If we valued informed
consent enough to make the interactive prompt in the first place then
I think it's fair that enabling debuginfod during batch usage also
requires an additional step to ensure consent.  Personally I'd
be ok with debuginfod enabling by default but seemingly enough folks
have reasonable privacy concerns around this.  Ex. a tool quietly
downloading executables in the background via gdb by default.

> 2. displaying "Downloading -0.00 MB separate debug info for ..." is
> confusing.  Maybe the files came down too quickly, and the client didn't
> pass a late enough progress callback.  (If so, perhaps we could fix that on
> the debuginfod side, but I think the code there is good.  GDB should get a
> notification for the last download completion packet.)  It'd be better to
> omit the number, or perhaps replace it from an actual fstat st_size kind of
> number if necessary.

Yes "-0.00 MB" seems to coincide with small downloads. I'll try to
fix this on the gdb side.

> 3. having "set debuginfod ask" be the default is fine for interactive users
> - that was the whole point of the patchset.  But answering "y" is purely
> transient, as opposed to one-time.  Could gdb append a setting to its own
> .gdbinit file so that the "y" sticks?

I'm fine with the current default but I don't really have a good
sense of what the average user wants in this case. If the response
to this prompt persists across sessions and debuginfod was disabled
it might be useful to have a once-per-session reminder that debuginfod
is available. Something like:
  Debuginfod is currently disabled. Debuginfod can be enabled using "set
debuginfod enabled on"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/28636] usability suggestions for debuginfod client

[amerey at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

Aaron Merey <amerey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |amerey at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/28636] usability suggestions for debuginfod client

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

--- Comment #3 from Frank Ch. Eigler <fche at redhat dot com> ---
(In reply to Simon Marchi from comment #1)
> (In reply to Frank Ch. Eigler from comment #0)
> > With the recently integrated (gdb) set debuginfod* changes, things look
> > different and better in some ways.  Some suggestions for (re)consideration:
> > 
> > 1. defaulting to "set debuginfod off" for batch usage is kind of
> > unfortunate. [...]
> 
> If I understood correctly the original request, defaulting to "no" was for
> privacy reasons, making sure to get the user's opt-in before the tool
> contacts an external server.  If so, this would be important regardless of
> whether the usage is interactive or not.

The angle I'm focusing on here is that gdb is used by non-human-users to do
batch work.  I -suspect- that much? most? gdb -batch usage might in fact be
performed by automated tooling rather than humans.

(Rather than privacy, the motivation for this was more security, in case a
user might be concerned about downloading corrupted data.  There is
hardly any private information sent to a server.  Not sure this matters for
this topic.)


> Is the message telling the user to add the comment to their .gdbinit not
> enough?

IMHO it'd be better if gdb were to do that.  Is there any precedent for
persistent settings like this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug corefiles/28636] usability suggestions for debuginfod client

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28636

--- Comment #4 from Frank Ch. Eigler <fche at redhat dot com> ---
For an example of gdb batch mode use by tools: abrt.  They run gdb to generate
backtraces from crashed program coredumps.  There appears to be no way for a
user to interact with the prompt, so no obvious clue that they should even
consider adding something to their .gdbinit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.