Filing Bugs in Kubuntu

[Richard JOHNSON]

OK, maybe it might help a little if I go through the spec and comment on
some points.

> = Rationale =
> Kubuntu tracked packages currently get too many bug reports compared to the
> number of people doing active bug triage. It is necessary to revise the
> policy of bug triage so that bug triage and bug management can be more
> efficient.

I covered this in my previous reply, in regards to Bug Hug Days. These days
not only allow us to triage bugs together, but also provide the possibility
of bringing in new users, which I am fairly certain was a topic in
timelord.

> = Use Cases =
> * Alex is a Kubuntu user. From time to time he reports bugs against KDE
> packages at launchpad.net, his reports get processed quickly and resolved
> in the upcoming Kubuntu release. Important issues get resolved more
> quickly. Alex is happy to contribute something to the FLOSS community and
> sleeps well at night.

Isn't this use case promoting LP as the way to go or am I reading it wrong?

The use case with my name is good, and one I can agree with on sending bugs
upstream that aren't packaging bugs, but how are these being determined on
the user's end?

The one about Stephan scares me, as there are some upstream developers that
have animosity against Kubuntu in the first place. If we start pushing bugs
that only occur in Kubuntu, eventually Stephan may very well either ignore
reports coming from Kubuntu or just mark them INVALID w/o any reasoning. I
have seen this happen, and you can search bugs.kde.org for instances of
this.

> = New Policy =
> * Continue to track packaging issues, bugs/wishlist items for
> Kubuntu-maintained applications, and Kubuntu-specific wishlist items in
> Launchpad as usual.

How are these being reported by users? Wouldn't a user have to know it is a
packaging bug in order to file it in LP? As a Use Case, my brother would be
screwed. He has no clue, so he would end up reporting the bug in
bugs.kde.org instead of LP. Now, a lot of our regular users are used to
reporting them in LP, and may not even use the report a bug feature (which
I have a feeling is a big use case as well). New users are the ones I worry
about though, as they will not know what is going on. Even if we document
it until our legs fall off.

> * Only track upstream bugs of High or Critical severity, as well as
> Medium-severity bugs which would comply with SRU requirements.

How are we tracking these, in bugs.kde.org or are we referring to bugs
filed in LP? If we need to track them in b.k.o...hell I just confused
myself here. This bullet point needs clarification obviously.

> = Implementation =
> * Publicise policy change in various user venues, such as the Kubuntu and
> Ubuntu forums.

When is this going to occur? It seems this policy was implemented before
UDS, yet nothing was ever publicised, anywhere.

> * Investigate the status of the bugzilla launchpad plugin and convince KDE
> sysadmins to enable it so we can easily move bugs between KDE and Kubuntu
> bug trackers.

Any status on this? This would be a nice feature, regardless of policy.

> * The apport patch from kdelibs will be removed. C++ apps which are Kubuntu
> specific such as the new update notifier will need to have drkonqi turned
> off so Apport is used.

How is this carried out? Do we need to patch packages for this? If so,
there are well more than 50. This sounds like a fairly substantial task to
carry forward, especially for an LTS release where we should be
concentrating more on QA/Bugs than adding yet another patch to something if
that is how it happens.

----
There, I think I covered the ones I wanted.

-- 
 Name|  Richard JOHNSON
Title|  Developer
  WWW|  http://www.ubuntu.com
Email|  nixternal at ubuntu.com
GnuPG|  3578 0981 A21D D662 2A96  7623 F4C1 838C D8C4 4738
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20100123/d75cc8f7/attachment.pgp