[Sugar-devel] tracking upstream bugs

[David Farning]

On Fri, Dec 19, 2008 at 1:06 PM, Morgan Collett
<morgan.collett at gmail.com> wrote:
> 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

Thanks, as always, for the through response.  I'll file a bug against
dev.sl.org about the launchpad integration extension for trac.

david