Michal, I think that your complaint is caused by a misunderstanding of how package maintenance happens in Ubuntu. I’ll try to clarify it, based on what I understand (if you know better than me, don’t hesitate to comment).
The part of Canonical maintaining the distribution is organized into teams (full list here), like Kernel, Foundations, Desktop, Mobile, Server, etc. Most of those teams have mirror-teams in the community, like the Ubuntu Desktop team. Those teams take care of subsets of packages in Ubuntu, of relevance to the respective teams. (This is orthogonal to package upload rights, which are managed with the Ubuntu Core Development Team, and the Ubuntu Development Team ; there’s a proposal to change that so that package upload rights are based on the first set of teams).
However, there are some packages (probably more than 70% of the packages in Ubuntu, including main+universe) that are of no interest to any particular team. Those packages are maintained on a best-effort basis by all the Ubuntu developers (inside the loosely defined MOTU team), and focus is usually on not diverging from Debian, to make their work as easy as possible. It’s very similar to what we do in Debian with orphaned packages: sometimes, important bugs get fixed, because someone complained loudly enough or a developer ran into the bug and did a QA upload ; but usually, we don’t really do any bug triaging. Of course, there are some packages in Ubuntu that are not maintained by any “core” team, but still have someone that cares about them. They are more the exception than the rule.
So, yes, obviously, you will run into packages with lots of untriaged bugs, sometimes even with patches. And those bugs and patches are rarely being forwarded manually to Debian, simply because nobody cares about those packages in Ubuntu. In an ideal world, with infinite resources, this would not happen, of course. But realistically, this is not going to change anytime soon.
There’s a link on the PTS to the bugs of your packages in Ubuntu. The idea is to allow an easy access to the bugs reported in Ubuntu, which are likely to be also relevant to the Debian package. You should probably feel welcomed to triage the bugs against your package in ubuntu, if it makes it easier for you to monitor them.
There’s some noise in the Ubuntu bugs, of course, but more and more often, by looking at the Ubuntu bugs, I find important bugs in my Debian packages that are not even reported in Debian yet.
Yes, I know I can look and triage the bugs. However what if next distribution will spin off from Debian in similar way? And another? Nobody wants to follow so much bug trackers. The problem I see here is that even packages well maintained in Debian might have problems in Ubuntu (there are few differences), but because nobody is interested in that (Debian maintainer does not use Ubuntu so he does not care and there is nobody on Ubuntu side), these bugs fall in the black hole called Launchpad.
I think the biggest problem is that by letting you report bugs in the first place Ubuntu sets the expectation that some amount of care will happen to the reports. Maybe reports should be discouraged for these “no interest” packages or a redirect/strong suggestion to Debian’s bug tracker instead.
(My own experience has been several bugs with one line fixes and in one case just a recompile. The fixes were present in other bug trackers such as Fedora. The buggy programs crashed so applying the fix couldn’t make things worse. It took 4 Ubuntu releases for two of them to get fixed.)
When Ubuntu is bigger than your own distro, it might be worth a look at what other users of your packages are saying in it.
Perhaps the MOTU model doesn’t place enough accountability into the packaging process. It may be worthwhile to contrast the Ubuntu MOTU approach to the Fedora maintainership approach.
In Fedora, packages must have at least one primary active maintainer. If the package is not actively maintained the package is considered orphaned. There is even a process by which a maintainer can be listed as unresponsive and puts a package into an orphaned status in the case something like a submitted patch sits idle without package maintainer comment or review.
Orphaned packages are culled as part of the release cycle after there is an opportunity for packaging contributors to take over primary maintainership. This allows the Fedora repository to grow and shrink based on available contributor manpower and interest. It doesn’t shrink noticeably in practise because usually another maintainer steps up to take primary ownership of a package. But without something like that orphaning process its difficult to know what packages are in need of a new primary care giver.
-jef
What annoys me about the PTS link is: I see a bug for a package of mine and I’m pretty sure it is not in my package but a library my package depends upon (or not even there anymore, as I can’t test this particular case). Now I’d like to write an e-mail to the reporter. But guess what: I need an account with Launchpad. Something I don’t consider. So it is up to Ubuntu to clean up that mess. If they want me to take care of it, they’ll (reporter/Ubuntu team/anybody with an account on Launchpad) need to file the bug against my package in Debian. Then I’ll reassign it to the library I suspect (after asking for any data that might help to ensure it’s not my package, though I’m pretty sure). And it will finally go away.
To make a long story short: I expect Ubuntu to have an e-mail interface which is at least available for all Debian Maintainers, where I can provide further information, ask for data, whatever. Or any other way, that doesn’t force me to create an account on Launchpad.
@Vadim P.: No. Ubuntu is something independent. If they use Debian as a basis, that is their decision. But then it is also their responsibility to pass the information to upstream developers.
Kind regards,
Kai
Ubuntu actually has a separate team just for bug triage which currently has about 130 people in it. The problem is that there are now over 80k open bugs in Ubuntu. The problem isn’t a lack of desire to upstream the patches and/or reports, but rather having enough people to go through all the bugs. If you find a package is being neglected, please bring it to our attention in #ubuntu-bugs on freenode. We have events throughout the year to work through backlogs and perhaps we can have a day dedicated to neglected packages.
Micah: The Ubuntu bug triage “process” is worse than useless – closing bugs for points rather than actually caring about them. Sure, they’re short on time, but simply asking the reporter to reproduce then closing rather than trying to reproduce themselves is actively worse than doing nothing at all.
Dear Lucas. While tracking bugs for ones packages in Ubuntu might be a valid reason the sentiments that Michal is carrying is even more valid. It didn’t happen only once (or even only once in a while) to me that people did contact me about problems they have in Ubuntu with packages I maintain in Debian, and seeing bugs like https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/203158 lying around for ages doesn’t help, and this is a core bug in a package that is in main, not under the MOTU agenda.
And following the bugs on launchpad isn’t real fun.
See https://bugs.launchpad.net/malone/+bug/204980 for one reason why people actively are stopped tracking bugs in their packages in ubuntu. It almost sounds like the later comments in that one that the launchpad team simply stopped caring for it after it became open source and turn into “if it bugs you send patches” approaches. I rather follow the other people on “if it bugs you stop tracking bugs in launchpad”, it’s the much less painful approach with a much bigger time-gain for other sensible stuff to do.
Yes, things are getting better, but actually you even confirmed Michal’s sentiments that there isn’t anyone actually caring for a not that low amount of packages in Ubuntu. You tried to explain why it is so but actually, that doesn’t make it any better, it just gives the impression that things in that area are as bad as some of the packages in FreeBSD ports section, probably even worse.
It’s time for a bug-tracker-agregator.
Some website that would collect bugs reported to the trackers run by the distributions and various upstream trackers and present them all through a common interface.
Ofcouse there are some issues as not all distributions split and name sources in the same way, but in general it should not be to hard to. A simple RSS-tracker would give most of the required functionality.
Casper: Hilariously, that’s what Launchpad is supposed to do.
@Vadim: Ever read the sentence “do not pinch more packages than you can maintain”? But then you couldn’t brag you have more packages than any other distro, even Debian.
I think Roger hit the nail on the money, don’t accept bug reports on packages without a maintainer. Probably Debian should do the same thing for orphaned packages.
If Michal’s blog supported comments, I would have left him a comment linking to http://mdzlog.alcor.net/2008/10/29/ubuntu-quality/
Ahah, a mathematical explanation for why Ubuntu’s bug policies suck because they don’t make benefit of contributing > benefit of not contributing + cost of contributing.
Even more annoying now are “private” bugs. They make sense when it is an auto-reported crash (eg a crash of Thunderbird will have your email in the core dump). But what really ticks me off is when there is a package update in Update Manager that references a bug and that bug is private! I then have no way of actually seeing what problem the update fixes.
There are many fixes to this such as delete the private attachments, make a forked public bug etc. But is is ridiculous to have happened in the first place.
@Casper: a bug agregator? Look at the fetchbugs4.me project:
http://www.slideshare.net/olberger/bugtracking-on-the-web-25
http://blog.fetchbugs4.me/
http://code.google.com/p/support/issues/detail?id=3198
This post was very nicely written, and in addition it contains many useful facts. I enjoyed your distinguished way with words this post. Thanks, you have made it very easy for me to understand.