Re: On cadence and collaboration
[Please Cc: replies back to me, I'm not on debian-project@]
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
Reply to: