FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 01-23-2010, 02:14 AM
Richard JOHNSON
 
Default Filing Bugs in Kubuntu

Hey,

I was working on some documentation this evening and I figured I would go
through and document filing bugs in Kubuntu. I went for the old way which
is now using DrKonqi instead of Apport. I remember people talking in the
past about filing bugs in Kubuntu at bugs.kde.org instead of Launchpad
because we don't have enough people to triage, and that we would utilize
KDE instead.

I went through meeting minutes and couldn't find anything to support that
decision, so I went to the mailing list and there was nothing there, and
then I went to the wiki and found our bug reporting procedure [1] which
specifies reporting bugs the old way.

I am sorry if I missed the discussion, but I am not going to sit here and
grep 5 years of IRC logs to try and piece it together. Was this a decision
that everyone voted on? If so, what was the reasoning behind this? I ask
that if you do provide reasoning that you do not state either of the
following:

* Apport sucks, DrKonqi is better

or

* Kubuntu is to small to triage

Apport sucks, DrKonqi is better is not a valid excuse. We should be filing
reports in Launchpad, everyone should be. When someone follows the
recommended and documented way of utilizing the Report a bug feature in the
Help Menu, it is going to KDE. How are we tracking these bugs? How are they
being triaged?

Kubuntu is to small to triage is another very bad excuse. KDE may be
larger, but it isn't large enough to throw resources at bugs which may very
well be valid. Only a few projects in KDE are triaging bugs rather quickly,
while there are still bugs filed from Kubuntu 3 and 4 years ago that
haven't been touched, even though the software has been updated many times
since the reports.

As you can probably tell, unless there is an amazing excuse to do it this
way, I find it bad practice. You can search through b.k.o and find a lot of
bugs that were Kubuntu related, or only valid in Kubuntu, that were marked
as invalid. If the reporter was lucky, someone may have said "File this in
Launchpad." I am fairly certain there are apps most of us don't use that
others are, and they are filing bugs upstream and we have no clue about
them.

If it is in deed the case, that bugs should be filed upstream and not LP,
is there an agreement at all with upstream on this? Is it in a policy
anywhere or documented anywhere? My guess is no to both of those.

[1] https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting

--
Name| Richard JOHNSON
Title| Developer
WWW| http://www.ubuntu.com
Email| nixternal@ubuntu.com
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 12:43 PM
Harald Sitter
 
Default Filing Bugs in Kubuntu

Am Samstag, 23. Januar 2010 04:14:10 schrieb Richard JOHNSON:
> Kubuntu is to small to triage is another very bad excuse. KDE may be
> larger, but it isn't large enough to throw resources at bugs which may very
> well be valid. Only a few projects in KDE are triaging bugs rather quickly,
> while there are still bugs filed from Kubuntu 3 and 4 years ago that
> haven't been touched, even though the software has been updated many times
> since the reports.

KDE is not one team doing all and everything, but loads of smaller teams doing
all parts of everything, making it more efficient no matter how you look at it.

Anyhow. Yes. This is part of the reasoning [1]. Kubuntu watches over some 50
source packages' bugs, making up for probably > 150 applications, and when I
say Kubuntu in that context I mean Jonathan Thomas, because he is about the
only person doing bug triage at the rate necessary to prevent all reports for
those 150 apps from rotting away.

Of course KDE does not have unlimited resources. But let's assume a user finds
a crash in kwrite, an app we do not ship by default, so the need of instant
triage is lower than usual, yet it gets reported against kdebase.
At this point it all depends on whether Jonathan or someone else decides that
it is triage worthy or not. If they do not (which is probably the case since
kwrite is not part of the default install), then the report does
a) clot the kdebase reports
b) prevent upstream from fixing a bug
c) appears as if Kubuntu did not care

This is the case up to the point where a triage squad comes by and happens to
triage all of kdebase so the bug can move along, by which time it will either
be fixed or already reported upstream anyway.

The ratio of Kubuntu-only bugs is so horribly low that it simply does not
justify letting hundreds of bugs rot in malone, which from a user perspecitve
does not put good light on Kubuntu nor KDE.

Ultimately all reports would go to launchpad, but that implies that we have
the resources to pipe them through or get them triaged in a sensible time
frame, which is not the case.

So we can continue arguing about how it should be done, but unless we all get
a triage rate to compete with Jonathan's, I do not think that we have really
any say.

[1] https://wiki.kubuntu.org/Kubuntu/Specs/LucidBugTriagePolicy
--
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 03:57 PM
Yuriy Kozlov
 
Default Filing Bugs in Kubuntu

On Fri, Jan 22, 2010 at 10:14 PM, Richard JOHNSON <nixternal@ubuntu.com> wrote:
> Hey,
>
> I was working on some documentation this evening and I figured I would go
> through and document filing bugs in Kubuntu. I went for the old way which
> is now using DrKonqi instead of Apport. I remember people talking in the
> past about filing bugs in Kubuntu at bugs.kde.org instead of Launchpad
> because we don't have enough people to triage, and that we would utilize
> KDE instead.
>
> I went through meeting minutes and couldn't find anything to support that
> decision, so I went to the mailing list and there was nothing there, and
> then I went to the wiki and found our bug reporting procedure [1] which
> specifies reporting bugs the old way.
>
> I am sorry if I missed the discussion, but I am not going to sit here and
> grep 5 years of IRC logs to try and piece it together. Was this a decision
> that everyone voted on? If so, what was the reasoning behind this? I ask
> that if you do provide reasoning that you do not state either of the
> following:
>
> ** Apport sucks, DrKonqi is better
>
> or
>
> ** Kubuntu is to small to triage
>
> Apport sucks, DrKonqi is better is not a valid excuse. We should be filing
> reports in Launchpad, everyone should be. When someone follows the
> recommended and documented way of utilizing the Report a bug feature in the
> Help Menu, it is going to KDE. How are we tracking these bugs? How are they
> being triaged?
>
> Kubuntu is to small to triage is another very bad excuse. KDE may be
> larger, but it isn't large enough to throw resources at bugs which may very
> well be valid. Only a few projects in KDE are triaging bugs rather quickly,
> while there are still bugs filed from Kubuntu 3 and 4 years ago that
> haven't been touched, even though the software has been updated many times
> since the reports.
>
> As you can probably tell, unless there is an amazing excuse to do it this
> way, I find it bad practice. You can search through b.k.o and find a lot of
> bugs that were Kubuntu related, or only valid in Kubuntu, that were marked
> as invalid. If the reporter was lucky, someone may have said "File this in
> Launchpad." I am fairly certain there are apps most of us don't use that
> others are, and they are filing bugs upstream and we have no clue about
> them.
>
> If it is in deed the case, that bugs should be filed upstream and not LP,
> is there an agreement at all with upstream on this? Is it in a policy
> anywhere or documented anywhere? My guess is no to both of those.
>
> [1] https://wiki.kubuntu.org/Kubuntu/Bugs/Reporting
>
> --
> *Name| *Richard JOHNSON

Here are some reasons to use one vs. the other:
https://wiki.kubuntu.org/Kubuntu/Bugs/Apport/Discussion
I was hoping this would be discussed at UDS, but I don't know to what
extent that happened. However, a new policy was put in place:
https://wiki.kubuntu.org/Kubuntu/Specs/LucidBugTriagePolicy
This really took effect before UDS, so I don't know if there is some
log where it was decided.

I agree with you on most points, and if nothing else, this degrades
the user experience by having two different ways and UIs to report
problems that people have to learn about. However, from a practical
standpoint, sorting through all the upstream reports in Launchpad had
long ago become infeasible, and as Harald explains, having the bugs
piling up there was doing more harm than good. I get the impression
that there has been some benefit from the cleanup (done almost
entirely by Jonathan Thomas) and Launchpad has actually become useful
as a Kubuntu bug tracker, but I haven't actually been keeping track
and I would like to hear some evidence of this -- maybe a sort of
progress report on the Spec.

The Bugs/Reporting page was written before the change in policy. One
of the effects of the change is that the page needs to be updated but
we still need to keep instructions up for Karmic until its EOL. The
new instructions should be about the same as they would have been for
Jaunty, so the older releases shouldn't be an issue.

Note that the ubuntu-bug command is still available and Apport may
still be used for non-KDE applications, so the instructions need to
explain that, and apport-kde needs to be maintained (to my knowledge
it is still fairly broken in Karmic, and I'd like to see the UI more
KDE-like, maybe similar to Dr. Konqi.)

~ Yuriy

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 04:35 PM
Richard JOHNSON
 
Default Filing Bugs in Kubuntu

On Sat, Jan 23, 2010 at 02:43:43PM +0100, Harald Sitter wrote:
[...]
> KDE is not one team doing all and everything, but loads of smaller teams doing
> all parts of everything, making it more efficient no matter how you look at it.

I can agree with you on this point.

> Anyhow. Yes. This is part of the reasoning [1]. Kubuntu watches over some 50
> source packages' bugs, making up for probably > 150 applications, and when I
> say Kubuntu in that context I mean Jonathan Thomas, because he is about the
> only person doing bug triage at the rate necessary to prevent all reports for
> those 150 apps from rotting away.

I could totally accept it 100% if...Of course there is a if...Or maybe it
should be a but...Anyways, when was the last Kubuntu Bug Hug Day? I can't
remember to be honest. I know we did a couple a few release back in unison
with the regular Ubuntu Bug Hug Day. It seems that Jonathan was doing his
own bug days, and that's just one part of the reason why he rocks. I know
triaging bugs suck, but it is part of every developer community their is.
We should have been holding the hug days to not only triage our bugs, but
also attempt to get more contributors this way. Ubuntu does their hug day,
and they always get a bunch of new contributors. If you watch the BugSquad
membership at all, you will see it growing pretty much every day.

> Of course KDE does not have unlimited resources. But let's assume a user finds
> a crash in kwrite, an app we do not ship by default, so the need of instant
> triage is lower than usual, yet it gets reported against kdebase.
> At this point it all depends on whether Jonathan or someone else decides that
> it is triage worthy or not. If they do not (which is probably the case since
> kwrite is not part of the default install), then the report does
> a) clot the kdebase reports
> b) prevent upstream from fixing a bug
> c) appears as if Kubuntu did not care

I understand the aggravation that (a) causes, and in a lot of cases (b) is
already known upstream when it is filed in LP. As for (c), I would kind of
think we may not have cared. I know we do, but we never attempted to make
it seem like we cared.

> This is the case up to the point where a triage squad comes by and happens to
> triage all of kdebase so the bug can move along, by which time it will either
> be fixed or already reported upstream anyway.

Correct.

> The ratio of Kubuntu-only bugs is so horribly low that it simply does not
> justify letting hundreds of bugs rot in malone, which from a user perspecitve
> does not put good light on Kubuntu nor KDE.

Well, with the "Report a bug" feature now going to bugs.kde.org, how is a
new user to know if the crash is related to Kubuntu or not? What I am kind
of afraid of is this, a crash occurs, gets filed in b.k.o, it is because of
either packaging or a booged patch of ours/Debians. Now we have to rely on
upstream to triage it, in which case they say "This is Kubuntu, not us". So
now what does the new user do? More than likely, they may not be hip on
filing a bug in LP. We can document the process until our face turns blue,
hell we could even make it the default wallpaper. In a lot of cases, it is
a topic that will not even be read.

> Ultimately all reports would go to launchpad, but that implies that we have
> the resources to pipe them through or get them triaged in a sensible time
> frame, which is not the case.

If we would do Hug Days, then I think we could find the resources. KDE has
been doing amazing with their Hug Days, Ubuntu, openSUSE and Fedora as
well, who both have just as small of a team as we do.

> So we can continue arguing about how it should be done, but unless we all get
> a triage rate to compete with Jonathan's, I do not think that we have really
> any say.

See, I feel we took the easy way out, and I feel it may not be the correct
way. We never attempted to hold a triage day at all. I am definitely not
blaming anyone for not attempting this, as I am just as guilty if not more.
I know I could have taken the initiative to do so, and I wish I would have.
I have no problems with bugs going upstream at all. I kind of worry about
the instances where DrKonqi doesn't get enough information and doesn't
allow one to file a bug report. This happens plenty of times, especially
when one doesn't have the necessary packages installed. I just made
KEuroCalc crash, which isn't in KDE. Yet the KDE Crash Handler comes up,
provides you the "Report a bug" feature. If you go through the wizard, in
the end it doesn't allow you file a bug report. Of course because KEuroCalc
isn't in KDE. Now what does the user do? If the user isn't aware of filing
the bug report in LP instead, then this is a bug that doesn't get reported.
Kind of like the popups on Windows where you can send a report. People just
got used to hitting cancel, and I am afraid we could end up being like that
as well.

So with all of that rambling, I am still not convinced, even with the use
cases and everything reported in the triage spec.

--
Name| Richard JOHNSON
Title| Developer
WWW| http://www.ubuntu.com
Email| nixternal@ubuntu.com
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 04:54 PM
Richard JOHNSON
 
Default Filing Bugs in Kubuntu

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@ubuntu.com
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 05:09 PM
Scott Kitterman
 
Default Filing Bugs in Kubuntu

On Saturday 23 January 2010 12:54:31 pm Richard JOHNSON wrote:
...
> > * 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.

This is done and didn't need all apps patched. For example, I recently
reported a Quassel crash based on Dr. Konqi. I think stuff that depends on
kde4libs will just work. So we get this result with fewer patches, not more.

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 05:12 PM
Scott Kitterman
 
Default Filing Bugs in Kubuntu

On Saturday 23 January 2010 12:35:37 pm Richard JOHNSON wrote:
> On Sat, Jan 23, 2010 at 02:43:43PM +0100, Harald Sitter wrote:
> [...]
...
> > So we can continue arguing about how it should be done, but unless we all
> > get a triage rate to compete with Jonathan's, I do not think that we have
> > really any say.
>
> See, I feel we took the easy way out, and I feel it may not be the correct
> way. We never attempted to hold a triage day at all. I am definitely not
> blaming anyone for not attempting this, as I am just as guilty if not more.
> I know I could have taken the initiative to do so, and I wish I would have.
> I have no problems with bugs going upstream at all. I kind of worry about
> the instances where DrKonqi doesn't get enough information and doesn't
> allow one to file a bug report. This happens plenty of times, especially
> when one doesn't have the necessary packages installed. I just made
> KEuroCalc crash, which isn't in KDE. Yet the KDE Crash Handler comes up,
> provides you the "Report a bug" feature. If you go through the wizard, in
> the end it doesn't allow you file a bug report. Of course because KEuroCalc
> isn't in KDE. Now what does the user do? If the user isn't aware of filing
> the bug report in LP instead, then this is a bug that doesn't get reported.
> Kind of like the popups on Windows where you can send a report. People just
> got used to hitting cancel, and I am afraid we could end up being like that
> as well.
>
> So with all of that rambling, I am still not convinced, even with the use
> cases and everything reported in the triage spec.

(K)Ubuntu is a do-acracy. The only one doing any substantial bug triage right
now that I'm aware of is Jonathon Thomas. My vote is he gets to decide.

BTW, Dr. Konqi knows where to send Quassel bug reports upstream. If it didn't
know where KEuroCalc bugs should go, I think that's a KEuroCalc bug.

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 05:59 PM
Dotan Cohen
 
Default Filing Bugs in Kubuntu

If the issue is a KDE issue (will affect all distros that use KDE),
then file it as BKO. If it is a *buntu bug (only affects Kubuntu) then
file it at launchpad.

In other words, don't file upstreams as Launchpad.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-23-2010, 06:08 PM
Richard JOHNSON
 
Default Filing Bugs in Kubuntu

On Sat, Jan 23, 2010 at 08:59:23PM +0200, Dotan Cohen wrote:
> If the issue is a KDE issue (will affect all distros that use KDE),
> then file it as BKO. If it is a *buntu bug (only affects Kubuntu) then
> file it at launchpad.

Who determines this? Rightfully not the user, especially a new user.

> In other words, don't file upstreams as Launchpad.

I agree and disagree, because now in order to track a bug, we need to keep
an eye on b.k.o as well. If it were filed in LP, and linked to an upstream
report, tracking is much easier. Offloading to b.k.o provides an extra,
inefficient, step in tracking.

You can follow the latest bugs in b.k.o, and the top 5 are w/o a doubt
duplicates, though 3 are from Kubuntu, 1 from Gentoo, and 1 from Arch. So
now instead of filling up LP, b.k.o is going to fill up, which will
eventually lead to the same problem that is being worked around now.

--
Name| Richard JOHNSON
Title| Developer
WWW| http://www.ubuntu.com
Email| nixternal@ubuntu.com
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-24-2010, 12:45 PM
Harald Sitter
 
Default Filing Bugs in Kubuntu

Am Samstag, 23. Januar 2010 19:12:46 schrieb Scott Kitterman:
> > So with all of that rambling, I am still not convinced, even with the use
> > cases and everything reported in the triage spec.
>
> (K)Ubuntu is a do-acracy. The only one doing any substantial bug triage
> right now that I'm aware of is Jonathon Thomas. My vote is he gets to
> decide.

+1

--
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 01:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org