ubuntu-bugcontrol team mailing list archive

[Philip Muskovac <yofel@xxxxxxx>]

On Saturday 29 March 2014 18:49:50 Phillip Susi wrote:
> On 03/29/2014 04:51 PM, Dr. David Alan Gilbert wrote:
> > The reality though, is that it does make more sense to report them
> > upstream for a few reasons: 1) They tend to be up to date with
> > upstream 2) Ubuntu doesn't change them. 3) There is a single
> > upstream place to report them to 4) Upstream seems happy with
> > taking bugs reported from Ubuntu packages.
> >
> > Now that combination is rare - taking a random package it's
> > unlikely all 4 of those are true, so it doesn't make sense for it
> > to be the general Ubuntu triage/report policy.
> 
> It really doesn't make sense.  Upstream is quite happy to take bug
> reports as long as they also apply to the upstream package, which is
> why we forward them after verifying that they do, *and* continue to
> track them in Ubuntu.  Just because it also applies upstream is no
> reason to to declare the bug in ubuntu to be invalid.  We track bugs
> in Ubuntu so that people can find out what bugs are present, and so we
> can notice when it has been fixed upstream and be sure to update or
> backport the fix.
> 
> > If people were to report KDE bugs into ubuntu/lp then it's just a
> > delay while someone triages it and then reports it upstream - the
> > extra comms delay doesn't help anyone.
> 
> KDE is no different in this regard than any other package in Ubuntu,
> so it shouldn't have its own policy that differs from, and is not
> documented in, the Ubuntu bug triaging policy.

Hi,

to explain things, lets go a bit back into the past to around 2010. The situation with bug reports against KDE packages back then was essentially:
- Only very little triagers (i.e. 1-2, mostly a developer)
- These types of bugs:
	A) Bugs in the packaging that affect us, but not upstream
	B) Upstream bugs
	C) Long fixed upstream bugs that were never closed

Quite frankly, the only bugs we really care about are A), B) to the extent that they make sense for SRU's - otherwise not, same for C)

So to cope with the impossibility of keeping up with bugs AND complying with the ubuntu triaging policy we implemented our own one because:
- We cannot keep up with all the bugs because of a lack of triagers, so bugs were lying around without ever getting fixed or upstreamed. I doubt the reporters are happy about that.
- It's far more productive for the upstream triagers to talk to the reporter as they usually know more about the applications than we do.

This is currently done by having Help->Report Bug in KDE applications kept in it's original state which sends people directly to bugs.kde.org and by pointing the people that still report their bugs on launchpad to the KDE bugtracker after evaluating whether the bug is on our side or not.
At this point we close the bugs on launchpad because tracking it on launchpad has no value to us. KDE releases software rather frequently, and none of us have the time to  regularily look at the bugs fixed in some ~200 packages once a month (or for betas/rc's once a week. That's currently ~170 KDE SC source packages + other required things).

When it comes to SRU's, we have a microrelease permission for KDE SC so we upload the bugfix releases directly to -proposed after PPA testing. That requires a single SRU bug for management. Only when there is a high-impact or security bug we do fix it in all our supported releases and not only as part of the upstream bugfix release. That again requires developer evaluation before it happens, or the bug is directly reported with this intention.
Sure, someone could make a script that parses the "Fixed-In" field in kde git logs between version tags and matches those against the upstream tracking bugs on launchpad, but nobody sees enough value in this to implement it. (That would help with the issue that we never close bugs on launchpad after they're fixed upstream)

Also, I don't really see how our policy *conflicts* with the ubuntu triage policy (it should've been documented as a special workflow though I guess?)
We do not mess with the bug importance, most of our bugs are never moved from 'Undecided', otherwise the Ubuntu-wide rules apply, so no issue there.
When it comes to the status, all we do is close the bugs much earlier in the workflow. So if an ubuntu triager would triage a KDE bug following the ubuntu policy he wouldn't intefere with any workflow (unlike the 'Stop triaging bugs' thread we had last week). We would just go ahead and close it. If the bug wasn't fully triaged - by sending the reporter upstream, if it was fully triaged - by just closing it explaining why.

>From my very personal POV (as I originally come from the ubuntu side), the ubuntu triage policy is a very good workflow for bug management. It just doesn't scale for the Kubuntu team. Improvements welcome (but none that require us developers to spend more time that we don't have)

Philip Muskovac
Kubuntu Developer