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. 
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!
