Ubuntu Main and Debian Developers.
One of my packages, the Linux kernel's userland support tools for the Network Block Device was chosen by Ubuntu developers to be part of their 'main'. For those not very comfortable with Ubuntu: the "main" part is their idea of "this is what we support". Everything in main is free software and supported; things that are still free software but are not supported yet, are moved to their "universe" instead. Most Debian packages live in Ubuntu's "universe"; only the desktop environments that they support and their dependencies are part of Ubuntu's "main" section. Occasionally, I was told that the nbd source packages were moved to main because ltsp declares a Depends: relationship on them, and it was decided that the ltsp packages should be part of main.
Personally, I don't use Ubuntu (though I've installed it a few times in the past, being the curious software geek that I am). As such, I don't really follow their development very closely, being more focused on Debian unstable instead. This would normally not be a problem, except that I do care that my packages are in a good state when they are released by someone, whether that someone is Debian, Ubuntu, or anyone else.
What triggers this post is the fact that Ubuntu has shipped Dapper with nbd 1:2.8.3-1, with a context of this changelog entry:
nbd (1:2.8.3-2) unstable; urgency=low
* Steal patch from CVS for nbd-server.c to make children exit when they
finish serving, rather than having them loop over "Help, I can't accept()
anymore!". Closes: #350357.
-- Wouter Verhelst <wouter@debian.org> Tue, 31 Jan 2006 11:17:25 +0100
#350357 is a bug of severity important, and rightly so. From the bug report:
Jan 28 14:42:58 caradoc last message repeated 1190456 times Jan 28 14:43:59 caradoc last message repeated 2478818 times
An infinite loop producing an error message, a bug which triggers when a client disconnects. Have two clients connect, then disconnect, and you have a syslog being filled up with spurious error messages, filling your entire disk in a few hours or days.
It may be too late to update dapper now; however, had I been asked after #350357 was filed whether it would be a good idea to ship with this specific version of nbd, I would have said "no", and this horribly buggy version of nbd wouldn't be in a released version of Ubuntu. And since #350357 was filed a few days before the above log entry, in January, I cannot believe that it would've been too late.
Of course, if anyone from Ubuntu is reading this and can tell me that
yes, it is still possible to update nbd in Dapper, then by all means,
please do so. Oh, and don't forget to update edgy while you're at it
That being said, I'm hoping something can be done to avoid this kind of SNAFUs from occurring again. Ubuntu could talk to me for those packages they care about, which (according to their policy and the status of nbd in their distribution) includes nbd. As it is, Ubuntu is just a large institution that happens to redistribute parts of Debian. I'm getting more feedback from the guy doin the 'nbd-server' port in FreeBSD than I'm getting from Ubuntu—and that FreeBSD guy only once or twice sent me an email...
First, I wonder why you care so much about anyone releasing buggy packages, even if they're yours. You released that buggy package yourself in unstable, and let it reach Etch, in which it stayed for about 40 days. So what's the problem if it stays in Ubuntu "stable" for presumably 6 months? That's only 6 times longer. Even Sarge, which got in terms of time about 4 times more care than Dapper, released with a good number of already known RC bugs. We're not talking about important bugs here.
As for asking you about your upstream packages, do you realize that there are probably thousands of source packages in Ubuntu's main, and that they release twice a year? That would mean, if they have say 2000 source packages in main, about 4000 such requests to Debian each year. Just for Ubuntu. Would all Debian maintainers appreciate that? I personally would hand a "Check The Friendly BTS" to such requests. Even Debian doesn't methodically check with its upstreams before release AFAIK. And Debian has a BTS, so if the bug is so bad that the buggy package shouldn't be part of a release, why not making sure the bug's severity is appropriate and ease the jobs of your downstreams? And wouldn't a higher urgency of the upload fixing it reflect better the severity? DDs can whine about Ubuntu and its bugs, but people will still use it if DDs don't care more about testing.
This is the old 1:1 against many:1 mapping problem. Probably the FreeBSD person who is interested in NBD has chosen to do so, and he likes doing it (same for you and maintaining NBD in Debian), whereas Ubuntu got nbd dragged in as a dependency, and all of their main developers are responsible for it. Given that number_of_main_packages/number_of_main_developers ratio is much higher than the average package count of a Debian Developer (even worse is the universe/MOTU ratio), it is unreasonable to expect them to check Debian BTS for important bugs in all their packages. They will likely not notice the bug unless one of their users reports it as well or you point them towards (if you are interested in this, as you appear to). Some of the high profile applications like GNOME/KDE, OpenOffice, Firefox, etc. get special attention but most of the other needs bugreports in their Launchpad, I'm afraid.
That said, if you file a bug now (or maybe somebody did already after reading your blog), it might quite possibly get fixed in dapper-updates (after all, their stable updating policy is a bit more relaxed than Debian's concerning the severity of applicable bugfixes, AFAIK)
Michael
I care about my Debian packages much in the same way that I care about NBD in other distributions. Besides Debian, nbd is packaged for SuSE, Gentoo, FreeBSD, and Ubuntu. Currently, I don't use any of those (although I have used some of them at various times); but when CVE-2005-3534 got out, I took personal care of informing all those that hadn't brought out a security update yet of this issue, and that they should update. At least in the case of SuSE, they replied that they had been unaware of the issue and that they were grateful they were informed.
Even though I used the phrasing "had I been asked", it doesn't necessarily have to be "asked". If I have some contact inside Ubuntu who I could send such information to, I would just send this person an email and have him or her take care of it.
As it is, I have to jump through a number of nonpersonal hoops (create an account, use a webinterface) that I'm not necessarily willing to take just to be able to inform people that, hey, there's an issue here.
I want to inform Ubuntu when there's an issue with one of my packages. I want them to know that. However, I don't feel that I have an easy and personal way to do that. I would very much like to have such a way.
As for the whining and not caring about etch, I don't and I do. This wasn't meant as whining; it's just that I don't have a better way to communicate with Ubuntu. And I do care about etch; When it was discovered, the bug was fixed within a few days. The urgency was not raised, since the bug was not an RC bug and I didn't feel it had to be. I did also not do any other upload until the package had migrated to testing. Since Etch was not releasing at that point, there was no reason to do otherwise -- after all, unnecessarily inflating bug severities is not good practice, either; otherwise RC bugs that pop up in the new package will have less of a chance to be discovered before reaching testing.
If the intention of your post wasn't to whine, but to request improvements from Ubuntu regarding communication with Debian, it would have been more effective to strip the "beginning", go to the point, and to choose a representative title. If you think the nbd example is an interesting example of the problem, it would have been better to talk about it after explaining the point of your post.
Your elaboration on the effectiveness on finding a contact in Ubuntu is interesting. Looking at packages.ubuntu.com I think I got what you mean...no sign of who's responsible for the package. If I'm not missing something, I think that you have a point here. Unfortunately, I'm afraid your first post failed to make this point.
About caring about Etch, the urgency has to be discussed after the bug's severity. If the severity was rightfully important, then a low urgency upload may have been appropriate. But I doubt that an Ubuntu bug that warrants a post on planet.debian.org is just important. You are absolutely better qualified than me to judge the bug's severity, but you wrote yourself "had I been asked after #350357 was filed whether it would be a good idea to ship with this specific version of nbd, I would have said "no", and this horribly buggy version of nbd wouldn't be in a released version of Ubuntu." If you don't think that describes a serious bug, you can forget the 3 last sentences of my reply. Anyway, I don't understand why you write that "otherwise RC bugs that pop up in the new package will have less of a chance to be discovered before reaching testing."
Yeah, perhaps I could've reworded my post; but it's now too late for that. Anyway.
I agree that in hindsight, the urgency and/or severity of the bug could have been better, and had I put it at 'grave' severity and/or used a higher urgency, then the issue wouldn't have occurred right now. But that's all easy to say afterwards, and inflating severities or urgencies is just as not putting them high enough.
About upgrading to 'grave', my perception from what you said was that the bug should have been serious. After all, as the maintainer, it's your privilege to upgrade important bugs to serious if important is not representative.
Anyway, we're indeed pretty much "afterwards" now.