[Please Cc: replies back to me, I'm not on debian-proj...@] Mark,
I think you have a biassed view in your role as Ubuntu maintainer. This isn't bad in itself, but it needs to be written so that positions are clear. My position is: I'm currently using openSUSE for my development, with occasional portability tests on Solaris, NetBSD, FreeBSD, Ubuntu. I'm looking after my Mom's Ubuntu installation. More importantly, I'm also an upstream maintainer of fetchmail and leafnode, and I'm also co-maintainer of bogofilter. I would not consider any of these projects large. This is not Mozilla, Adobe. Still, my upstream maintenance considers needs of users and distributors, i. e. I will usually accept bug reports for outdated versions if I know that area of the code hasn't changed. The whole longish message of yours is about telling that others need to move and how good it all could be if everbody did, and you're pulling an argument that this was in the interest of end users. This is but a pretext, Ubuntu apparently doesn't catch enough karma among developers through deeds and achievements, and your begging for compromises isn't bound to improve on that, but quite the contrary. There are some key points of criticism I'd like to mention: 1. General communication with upstream maintainers, and consequences I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for packages I (co-)maintain upstream. Upstream here is "at the origin", not Debian packaging or something, list as above. Some were relevant and still current, and Ubuntu failed to either do something about the bugs (as in debug, write a patch) or at least tell people who were in a position to do something about the problem, concretely, forward the bug upstream. This is the very least you must do. Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829 This had sufficient information to debug, and lay around for half a year. Nobody in Ubuntu bothered to look at the report, or to forward it to the upstreams. Another observation is that Ubuntu bugs and bug changes are frequently forwarded to dozens of people, yet nobody cares to look. All you get is "me too" or dramatic narrations of how the bug ate somebody's dog. From maintainers, such as ubuntu core maintainers, for core packages: deafening silence. I'm happy to help distributions (without picking any particular, I don't care about your name, but about how you act), but I'm definitely not going to ferret up the downstream maintainers or "their" bugs. This was a one-time event. Some proposals for Ubuntu's part in this: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. iii. if you take my work (i. e. upstream tarball), and you're a downstream packager, it's your moral duty to approach me and tell me who you are and what you do. We appear to share the intention of improving user experience, but as written earlier, I'm not going to ferret up all possible downstreams. And there is prior evidence that my expectations work out: I have occasional contact with the downstream maintainers of other distributions, such as FreeBSD, NetBSD/pkgsrc, Debian, Fedora/Red Hat, OpenBSD, openSUSE. Often, new-coming packagers will approach the upstreams and introduce themselves, and perhaps share questions, bug reports or patches. I've never seen this happen for Ubuntu. Bottom line: Ubuntu has to work about something, or to contact whoever they feel fit, if they want something to change. 2. Getting innovations right, and going them all the way Ubuntu has some interesting approaches, such as Upstart. However, these are incomplete, underdocumented, and in consequence half-baked. If you care about the end user experience, you've got to bite the bullet and not only lick it. Discussing about superimposing schedules and conferences doesn't help at all. Providing half-baked solutions is a real nuisance for the end user and the upstreams: it creates the very inconsistencies that you'd like to avoid, and it adds one more item to the half-baked items list. Users get deprived of the old way of doing things (or it's a whole heap more work to do it the old way), the new way doesn't work yet, and upstreams sometimes see the fallout of such downstream changes. Across all Linux distributions, the most prominent innovations I recall are, in random order: X, X-autoconfig, Intel driver for X, dbus/HAL, NetworkManager, Pulseaudio, Upstart, KDE4 (and particularly the lack of established and crucial features therein, such as X.509 certificate management). You can't expect other distributions to collaborate if you don't muster the manpower to fully implement the proposal you make. You could set an example here - and then you'd probably have to beg much less for recognition; people will see if things are competently implemented. GRUB 2 is going to be another opportunity where Ubuntu can prove either useful or detrimental to your stated goals: invest time to polish it and contribute back to the upstream; or use it raw as it is and leave the user with the shards if it breaks. The upstream abandoned GRUB 1, GRUB 2 isn't ready. Bottom line: if you start innovations, make sure you complete them. Be very sure to fix regressions quickly. Back out the innovation if you must (NetworkManager, Pulseaudio, Intel driver for X, KDE4 are examples where this would have applied.) 3. Relationship with Debian. I'm an outsider here; I consider myself neither part of Debian nor of Ubuntu, so I'm not fundamentally biassed. Now, Ubuntu uses Debian packaging resources. Some people claim Ubuntu has drawn manpower from Debian (I can't judge on that). Fine. Now you are also asking that Debian approaches Ubuntu to collaborate. May I suggest a reality check here? You just presume Debian shares all of your goals and your ways there -- and you complain and ask that Debian moves to fit your goals better. Now this is bold. Not a bit, but really bold. There would be mutual benefit, sure, but you simply cannot buy sympathy or collaboration, and you can't just ask that for free. No wonder that people in the Debian community get unhappy about Ubuntu. Bottom line: take the free lunch, but don't complain if you don't like it -- you'll have to join the cook if you want it in a different way. 4. Cadence I as upstream maintainer couldn't care less about your downstream schedule. Use whatever newest "stable" or "maint" or "official" version there is, and stay away from development versions unless you're ready to upgrade a released distro versions to new upstream package versions. If you use release candidates, be prepared to upgrade to the final version. I as upstream see them as test releases, and I definitely do not care about reports for random intermediate versions. Debian and Ubuntu ship fetchmail 6.3.9-rc2. That version ceased to exist when 6.3.9 appeared. It was the best available version at the time of freeze, yet it was clear it would have disappeared when the distros hit the pipes and DVDs of the end users. Bottom line: don't get in the way between end users and original software authors. 5. Dividends, Ecosystem, ... I as upstream maintainer, who looks after software in spare time, have ZERO(!) motivation to sacrifice my spare time and my material for the profits of others. If you want to donate so I can keep domains running, replace aging hardware, for the benefit of all, you're welcome. Otherwise, don't even dare talk in economical terms about anything related to my software, unless you want me to charge you for bug fixes, support, and change requests. What I find most disturbing is that you're pulling economical terms to describe community and open-source efforts. Together with a total lack of communication with me both as bug reporter and as upstream maintainer for some packages, this is an offense. Bottom line: I'm not changing any of my procedures before Ubuntu moves. I wouldn't expect Debian to do that either. Executive summary: don't advertise for collaboration, just do it. Saves you much writing and pleading and begging, and people will collaborate automatically. -- Matthias Andree -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org