[Libreoffice-qa] Where should users report bugs?

[Robinson Tryon]

On Wed, Nov 6, 2013 at 10:14 AM, bjoern <bjoern.michaelsen at canonical.com> wrote:
> On Tue, Nov 05, 2013 at 08:46:36AM -0500, Robinson Tryon wrote:
>> => What bugs should be reported to our LibreOffice bugtracker?
>
> IMHO, all bugs. It provides much better visibility of the issues at hand. And
> yes, I even think bugs that 'happen only with the Ubuntu builds, but not with
> the TDF builds' should be reported upstream. Here is why: Most of the time even
> those issues are root caused in upstream code, but do not manifest in the
> upstream builds. An example is fdo#68210, which:
> - was caused by changes in LibreOffice upstream
> - did NOT manifest in TDF or Debian build (both were not using mergedlibs)
> - did manifest in Ubuntu and Gentoo builds
>
> Pushing this "downstream" to distros too early only slows down communication --
> as e.g. devs wont easily comment on other BTSes, and vice versa as accounts are
> missing.

Very interesting.

So we've got the minimalist approach: Only accept bugs filed against TDF builds,
and the "Get all the bugs....and thus all of the data".

Regarding bugs in other BTSes, it makes perfect sense that LibreOffice
devs won't necessarily look in or have accounts for each distro. My
general hope would be that maintainers/packagers would push bugs up to
FDO, but regardless of how on-the-ball these people are, it's true
that there's still going to be a delay, and there's still an added
piece of technical/meatspace complexity subject to failure.

>> => What bugs should be reported to distros?
>>
>>   (Classic Example: Bug filed against EOL version supported in distro)
>
> For Ubuntu: Every bug that affect a supported version of Ubuntu should be
> reported to launchpad too, BUT -- and this is the important part -- with remote
> tracking the fdo bug[1] (and adding the launchpad bug in "see also:" on fdo). The
> only exception would be if its not supported anymore upstream (e.g. LibreOffice
> 3.5.7).

Drawing a dividing line between TDF-supported and EOL builds sounds
good to me, but from a user perspective (and even from a LO community
perspective), that line is much harder to keep track of than a
dichotomy such as TDF build vs. Distro build.

Our current discussion point re: limiting the BSA to only
TDF-supported builds of LibreOffice seems like it could be very
helpful in simplifying the bug-reporting process. It would be great if
our process was as simple as "Go to the BSA, and follow the
instructions there". Given that users currently have to have an FDO
account before they can use the BSA, it would be nice if we could
determine their LO version *before* we require a login so we could ask
them to...
- Download a supported build of LibreOffice or
- File a bug with their distro

Rob -- Any suggestions on how we might accomplish that with the BSA?

> This double bug tracking is some annoying overhead, so one has to consider if
> it is worth is: E.g. will there be downstream dupes of the bug anyway? Will
> there be valuable triage info from those (then its likely worth it)? etc.

If the devs could be best-served by having the bug reports in our bug
tracker, then that seems like a reasonable place for them to live. As
long as we're willing to resolve bugs as NOREPRO, we can stay on top
of the volume of bug reports and keep our development process from
drowning in input that's not actionable.

>> => What bugs should be reported elsewhere?
>>
>>   (e.g. Extension bugs go to extension devs?)
>
> If the root cause is by all likeliness not rooted in our code base (which is
> admittedly hard to guess often).

True, true.

>> => What plans do we have in place to slurp-up bugs reported downstream?
>>
>>   (Can we make it easier for downstream to push bugs to us? Bjoern - Thoughts?)
>
> For launchpad there is launchpadlib:
>
>  https://help.launchpad.net/API/launchpadlib
>
> which allows scripting in Python. This could be using to e.g.:
> - find all bugs on launchpad against "LibreOffice (ubuntu)"
> - copy the bug description into a new bug on fdo
> - link both bugs:
>   - mark the fdo bug as a remote tracking bug in lp
>   - add the lp bug as a "see also:" on fdo
>
> If someone volunteers on this I suggest getting in contact with Chris
> (https://launchpad.net/~penalvch) or Ubuntu Bugcontrol
> (https://launchpad.net/~ubuntu-bugcontrol).

That would be a great way to get downstream-filed bugs into Bugzilla.
I'm sure that other distros are using other tools, but given our large
number of Ubuntu users, this seems like a great place to start.

>> => What should we support in the BSA?
>>
>>   (The answer to this one depends upon our answers to the rest of the Q's)
>
> IMHO we already have a somewhat decent 'staging' of reports for upstream bugs:
> Inexperienced users might ask their incomplete bug reports/support requests on
> ask.libreoffice.org without needing anything but OpenID. Most of these reports
> are support requests and the rest need additional info to be complete bug
> reports anyway. As such, completing the report on ask and then file it on fdo
> (linking between both) does not seem too unattractive to me.

Per our discussions in the past, I think we'd really need to get
OpenID working with Bugzilla and have some kind of tool to help move
entries between Ask and Bugzilla before we could make this a sane
workflow :-)

In general, it does sound like we could have a consistent bug filing
policy if we limit the BSA to TDF-supported versions, and collect all
bugs, regardless of which organization created the build. In that
case, would it be helpful if we collected information on whether a
build comes from TDF or from a distro? E.g. 3.5.7 vs. 3.5.7-0ubuntu4 ?

Cheers,
--R