[Sugar-devel] tracking upstream bugs

[Morgan Collett]

On Thu, Dec 18, 2008 at 19:14, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Fri, Dec 19, 2008 at 09:33:49AM +1800, David Farning wrote:
>>Is the upstream bug tracking feature of lauchpad correctly set up to
>>push Sugar bugs through debian or directly up to the Sugar Labs bug
>>tracker?  If not, should I follow up?

Yes it is, in that we can link Ubuntu bugs to upstream bugs on either
dev.laptop.org or dev.sugarlabs.org Trac instances, and watch the
upstream bugs. For an example, see
https://bugs.launchpad.net/ubuntu/+source/sugar/+bug/295113 which is
linked to both.

There is some sort of Trac plugin for additional Launchpad integration
which can pull comments from the upstream bug tracker too. It would be
great to have that installed on dev.sugarlabs.org - Luke Faraone knows
a bit more about it.

> I have no knowledge on Ubuntu-specific mechanisms like their BTS, so
> cannot tell you specifically about above.
>
> Passing on bugreports upstream is generally A Good Thing(tm).
>
> I believe, however, that it makes best sense for bugreports to be passed
> back upstream through same channels as code is pulled downstream. That
> is, when Ubuntu users file bugreports against packages derived from
> Debian, it makes most sense to me that Ubuntu package maintainers file a
> bugreport against the origin Debian package. And similarly file a
> bugreport against Sugarlabs for non-local bugs in packages packaged
> directly from Sugarlabs.

I completely agree, and have probably missed a couple of opportunities
to file bugs against Debian when I filed them upstream.

We've got three main scenarios:
* Affects Ubuntu only: a packaging issue like Jigsaw Puzzle not
working, where Debian doesn't ship it
* Affects Ubuntu and Debian, but not upstream: problem is a packaging
bug like where activities were being installed to
/usr/share/activities instead of /usr/share/sugar/activities - we
filed this against Ubuntu and Debian
* Affects Ubuntu and upstream but not Debian: Support for Network
Manager 0.7 which isn't in Debian unstable even. Filed against Ubuntu
and linked to existing upstream bug reports.
* Affects Ubuntu, Debian and upstream: We would file against all three.

> Also, passing on bugreports should only be done when relevant: Ubuntu
> package maintainers should in each and every case consider if the bug is
> likely to be tied to upstream code/packaging or only relevant for their
> own customizations or system environment. In other words: Don't just
> blindly pass all bugreports upstream!

Absolutely, the first step is to check if it's just in Ubuntu. We do
have several of those.

> So if you (David) want Ubuntu to report to Sugarlabs _instead_ of to
> Debian then I disagree: Short-circuiting reporting chain might be
> beneficial short-term (by reducing risk of loosing or slowing down info)
> but hurts long-term interests of code-sharing IMHO.

Since I am an upstream developer, I'm generally aware or can find out
quickly if an issue is already known about upstream. We will report
issues relating to Debian in the Debian BTS, but won't necessarily
wait for Debian to then file the bug upstream - if it is an upstream
issue we'll file upstream and note that in the Debian bug as well.

> If Ubuntu is able to handle reporting back to multiple upstreams, i.e.
> bugs in Ubuntu-repackaged Debian-packaged Sugarlabs-originated software
> reported to Ubuntu should ideally be reported back to _both_ Sugarlabs
> and Debian, that would be good. Especially if including references to
> those other bugreports (not only reference to originating bugreport).
>
> I suspect, however, that the fundamental concept of Launchpad is to keep
> such info on relations between BTSes only in Launchpad, not to pass it
> on in the way most suitable to each BTS. I would be happy to be proven
> wrong :-)

Launchpad has a "model" of the upstream project, representing upstream
releases which it syncs from the upstream tarball URLs, so it
automatically populates this with known upstream releases for each
Sucrose component we track. This is independent of the actual distro
packaging, which is then linked to a specific upstream release series
(e.g. 0.82.x). It's of most significance where upstream is using
Launchpad as a bug tracker too, but also relevant in this case. For
those following along, see https://launchpad.net/sucrose for the
upstream project modeled in Launchpad.

For a given bug report in an Ubuntu package, we can link it to
Launchpad's model of the upstream releases, setting a bug watch on the
appropriate upstream bug tracker, and we can also link it to various
other distro BTS systems - for example we can link to a Fedora
bugzilla bug and watch that - which, strange as it may sound, may be
of assistance with Sugar, given that the OLPC distro work seems to be
moving more and more into the Fedora community.

Anyway, it means we can watch a Debian bug report. a Sugar Labs bug
report, and/or an OLPC bug report in Launchpad.

What I will endeavour to do, and encourage the rest of the Ubuntu team
to do, is to file appropriate bug reports against Debian's BTS as well
as upstream, consider an appropriate fix, and contribute it upstream,
then to Debian, then get it fixed in Ubuntu by syncing from Debian.
Where time is of the essence, or we are fixing the stable Ubuntu
release, we will have to patch the existing package rather than
syncing, but will aim to still fix it in Debian and sync to our
unstable branch (dropping any interim patches).

Regards
Morgan