Kubuntu Bug Policy for 10.04 on

I’m a bit late with this post. For some reason I couldn’t find the motivation to blog rather than do other FOSS stuff. ๐Ÿ˜› But communication is important, so I will blog.

Starting with the Kubuntu 10.04 cycle (now), Kubuntu will be changing the way it handles KDE bugs in the Launchpad bug tracker. In the past we have tracked both packaging bugs as well as upstream bugs at Launchpad. Tracking upstream bugs gives the benefit of being able to follow upstream’s resolution of the bug more quickly and, hopefully, be able to provide a Stable Release Update (SRU) for the fix. However, at the present tracking upstream bugs at Launchpad does not make sense for Kubuntu for the following reasons:

We have too few bug triagers to effectively track or send on upstream all the upstream bugs that we receive. Many upstream bugs rot in Launchpad, never seeing the light of day until they are closed when the user stops responding. As a result upstream never sees this bug and never has a chance to fix it unless somebody else reports it to the directly.

At the present, we usually never SRU individual fixes, effectively negating the reason to track upstream bugs in the first place. This is because KDE has an awesome release policy where every month a bugfix point release is made. Perhaps in the future this could be useful for SRUing specific fixes to older releases (e.g. not the most previous stable release than the current) that normally would not receive the new KDE update. But until then we really do not have the developer manpower to do that…

Basically, it all boils down to an issue of scale. Do we have the manpower to track upstream bugs? If not, can we defer the use of Launchpad for upstream bugs until we have both the bug triaging and developer manpower to properly handle it?

The answer is that we are, as of now, going to be redirecting all current upstream bugs to bugs.kde.org. For 10.04 we will most likely disable apport-kde for crash detection for KDE apps (it was fairly buggy anyway) and switch back to using the fabulous Dr. Konqi from KDE. This will leave the Kubuntu bug tracker in a much cleaner state, where Kubuntu developers can see exactly what needs fixing in Kubuntu without wading through an ocean of upstream bugs.

This has been a public service announcement from Project Timelord. Project Timelord would also like to remind that contributing to Timelord is really no different than contributing to Kubuntu, so we invite you to join us!


19 Responses to Kubuntu Bug Policy for 10.04 on

  1. Greg says:

    Hi, although i am not a Kubuntu user, i am very happy for the decision you guys made. My opinionn on the issue follows.
    Linux distributions aren’t the developers of most of the software they distribute. They are packagers. When they start adding patches to the software they take from upstream, they fork it downstream, thus become developers of it.
    Noone benefits from this. Not other distributions, not upstream, not even the users of the particular distribution in many cases cause the product that is delivered to them, is not what the original developer intended to. Bright example of that issues like the OpenSSH one on Debian. ( I guess that will take quite a while to stop being mentioned in such occasions ).
    IMO all the patches that alter the way the applications work should all be discussed upstream. And i am not talking only about KDE here.
    Additionally, the only patches that should be applied besides those fixing stuff like distribution specific paths etc, should come from the upstream development branch. Packagers should work with upstream. Not become themselves the upstream.
    All upstream bugs in launchpad should be accompanied by a link to discussions taking place in the applications bug tracker (or related resources).
    And of course, as yourself say, it will save time to hunt down bugs that actually matter, caused by the applications and the way the distribution works which are the most important ones in order to make sure the way you intend to bind and make all those pieces of software work together works, and works reliably enough.
    I dont know if all these sound obscure, or weird, but i am very confident that this the way things are meant to work.
    Again congrats about your decision, i hope that in the future you will manage to deliver a product matching the users needs much more than before.

  2. Seren says:

    If this is an official policy, should we (Kubuntu users) start to encourage people on forums to report bugs to http://bugs.kde.org rather than Launchpad for the 10.04 development cycle ?

    Does this affect bugs found on Karmic too ?

    Is there particular guidelines to follow ?

    • echidnaman says:

      If it is a bug with KDE itself and not a Kubuntu-specific tool, then yes. Only rather serious/prevalent upstream bugs should now be reported to Launchpad. Non-serious bugs and wishlist items should be reported straight to KDE, otherwise they’ll probably just rot in Launchpad. (Well, not anymore. We’ll just close them now :P)

  3. Aaron Seigo says:

    I believe there is a matching commitment that comes along with this: ensure that KDE bugs in Kubuntu are actually KDE bugs. What I mean by this is that with this new policy there’s an even greater requirement to ensure that patches to Kubuntu’s KDE do not cause problems, as that would end up on our plate and would be a (ab)use of upstream’s time for downstream issues.

    I see no problem with pooling reports for upstreams with upstream (in fact, I think that’s a way to gain efficiencies for _everyone_), it just shouldn’t become a dump for bugs caused by downstream additions.

    In the past, there have been issues with Kubuntu patches (and no, Kubuntu isn’t unique in that respect). So I’m eagerly looking forward to reading about the new patch policy mentioned earlier with an eye to this new bug policy as well.

    Best wishes …

    • echidnaman says:

      Oh yes, definitely there is a responsibility that comes with this. (Though really the only times we have bugs coming towards us are during the development stage for the next release. Before 9.10 people had to manually report bugs to us and by default already went to BKO to report them.)

      Also, another plus about this is that I have more time now to triage upstream reports.

      In regards to the patch review, this has begun. As part of our once-per-cycle merge with the Debian packages we are taking the time to review our current patches. We plan to make this a cyclical thing to happen along with our merges with Debian. Maybe I should blog about that soon. ๐Ÿ™‚

      • Aaron Seigo says:

        “we are taking the time to review our current patches”

        that is indeed good news. please bug us plasma people to review any patch that touches plasma code. it will only take us a few minutes and can save us all a ton of grief later on.

  4. Fazer says:

    Greg: Dude, that’s not how things work…

    I’m glad Kubuntu is striving for a better user experience.

    • Greg says:

      I never said i would describe how things work.
      It was my opinion on how things *should* work.
      The current way things work for you ( & not everyone) is clearly wrong and as far as i can tell Aaron Asiego’s post proves me right. Kubuntu doesnt provide a “better user experience” despite of all the downstream patches.
      In fact its being critised for it from upstream KDE.
      And i dont see how is that different for all other projects.
      Here’s a link for you http://www.modeemi.cs.tut.fi/~tuomov/ion/news/Down_with_the_distros.html
      Do you really want to continue preventing people from developing contributing code to open source projects?
      Cause thats what patching downstream and call it KDE, Ion whatever leads to. Plus possibly broken software and not satisfied clients.

  5. albert says:

    Kubuntu remember me another project pidgin. This project after years is adding the video to their IM but unfortunatly for them this project has been replace in most major distribution by telepathy/empathy. They listen too late to their user. It’s the same for kubuntu. After years of frustration. Bug not treated, actually the one I am looking is the ones with knetworkmanger (a kubuntu specif). It’s impossible to connect on WEP with it. And no it’s not a problem with networkmanager it’s a specific problem with the ubuntu software. In two months I will shift to pardus, chackra or Mandriva but I am tired of this kind of bug.

    • echidnaman says:

      Ehm, KNetworkManager is in no way Kubuntu-specific.

      • lexxonnet says:

        I believe he means knetworkmanager specifically, one that was shipped with Kubuntu Karmic. I’ve seen a few other responses on the forums dealing with exactly the same problem. We’ve got a case of WEP worked in Jaunty but not in Karmic.

      • Aaron Seigo says:

        to be fair, shipping it was a Kubuntu decision. KNetworkManager as shipped by Kubuntu was in KDE’s playground and not deemed fit for user consumption.

        we can discuss what the options were, but the decision to ship unreleased software which the authors believe to be unfit for shipping is the decision Kubuntu ended up with.

        hopefully it was just fallout from moving to KDE 4 in that specific timeframe, but it may be useful to examine what the priorities are when making those kinds of decisions are.

      • echidnaman says:

        Nah, he was saying that KNetworkManager is a Kubuntu-specific program, which it’s not.

        As it stands, the same WEP problems will be in OpenSuse 11.2 unless solved before release.

        We worked extensively with Will Stephenson and had his full approval on shipping KNetworkManager as it was at the time of the release of Kubuntu 9.10.

      • albert says:

        The package is NOT officially in KDE so if kubuntu decide to provide it. It’s a kubuntu software I don’t care that opensuse beta can be touch by it. The only things that I know is that kubuntu 9.10 (not a beta version) is broken. This is a problem for kubuntu but also for KDE project because it seems that KDE is officially providing broken software. In addition to this where I have to fill the bug in the new system? For kubuntu, but you just tell me that it’s not a kubuntu software or in kde bugzilla but it’s not a KDE software also (not yet). Are you seeing the problem? On planet the same problem appeared with kdevelop. Kubuntu if they want people to fill bug report upstrean have to provide ONLY upstream package and not playground.

      • echidnaman says:

        You do not seem to get that its original author has described it as “ready”. Whether it’s in playground or a private git branch right now would make little difference.

        It has a few quirks, yes, but is considered usable by both OpenSuse and Kubuntu. OpenSuse 11.2 is shipping with the current version *tomorrow*, so I doubt that they can fix the WEP bug previously mentioned. So basically a stable OpenSuse release will contain a KNetworkManager with the same bugs the Kubuntu release has. Free software has bugs; deal with it.

        So no, we’re not at fault here at all.

  6. Matt Parry says:

    Hi Jonathan,

    Thanks for your blog about kubuntu.

    I think that your doing a great job.



  7. Albert says:

    So no, weโ€™re not at fault here at all.

    This kind of answer is exactly why I am switching to another distribution. This is what we obtain on launchpad also with the same old bug present for months or years. The things that you don’t understand is that I am not the only one to feel that using launchpad is just a lost of time. You must also understand that people which are taking some time to fill bug report are sometimes responsible for a park of computer. For example in my case after to have the switch myself all my lab will do it. That means 200 computer switching to pardus or mandriva. Good job.

  8. After all, I think I still will report bugs to Launchpad first, using ubuntu-bug, which adds a lot of necessary information – and if I think this might be a upstream/KDE bug I’ll file it a bugs.kde.org, too (just by copy’n’paste and linking back to the launchpad bug), then add the b.k.o bug to Launchpad, too.

    I think that’s how it should work, but I understand that often the submit-to-bko step is not obvious to regular users and maybe that’s just something that might get automated, like bug triager looks at bug and thinks “hum, upstream”, clicks a button, and done.

  9. […] new policy has been set in to place. The result has been a cleaner, more effective bug tracker at Launchpad. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: