Published November 12, 2008
The description for ubuntu-devel-discuss says:
– Sharing of experiences with the current development branch of Ubuntu
– Technical questions about new features in the development branch
– Ideas and suggestions about future development of Ubuntu
– Point of contact for Ubuntu users to reach Ubuntu developers
– Open to all to subscribe, posting moderated for non-subscribers
This is a valuable resource for the community. It’s one of the few places where users and developers routinely interact. This is at risk. I’ve recently heard a number of developers mention that they got tired of the noise and the rudeness on this list and unsubscribed. I did feel strongly enough about it to bring it up on the list in a thread called Do you really want developers to be on this list.
I’m bringing it up here too because I think it’s important.
Ubuntu users (I include all the Ubuntu flavors in that): No developer is required to be on that list. It is up to you to make it one that we want to be on. This may be hard. You may have to sit on your hands instead of sending an emotionally satisfying, but really unpleasant response to a message about a problem you are having and are understandably upset about.
We have a Code of Conduct for a reason. Please be mindful of it.
Here are a few tips:
– Don’t demean or impugn someone’s knowledge or capability. We’re all very busy and just because we don’t drop everything and fix your personal problem right now doesn’t make us idiots.
– Don’t bother threatening to switch to another distribution. All that tells me is that I should ignore you. The only exception is those with support contracts and you should be dealing with your support contact and not whining on the list anyway.
– Don’t claim we don’t care. We do care, but we may have a different sense of priority than you do.
– Don’t be angry. If you are, don’t hit send. Wait until you calm down. Emotional messages tend to get emotional responses and people unsubscribing. They don’t get problems fixed.
– Don’t forget to pay attention. If you have a problem and we ask questions, please give us the courtesy of a prompt reply.
This isn’t meant to say that Ubuntu developers are paragons of virtue, we aren’t, but we’ve got plenty to do without reading ubuntu-devel-discuss and some of you really aren’t helping us to want to invest the time in doing it. This isn’t meant to minimize your problems or your frustrations. I understand they are real, but sometimes you really aren’t helping yourself get your problem solved.
BTW, most of the advice above applies to comments in response to this posting (not that I expect mentioning that to help).
Published November 3, 2008
I got asked about this on IRC today. Here’s what I suggested:
I think in Intrepid we got to a ‘complete’ set of packages by adding clamav and spamassassin and took some first steps in Intregration.
The goal for Jaunty would be to be able to script installation of postfix, amavisd-new, spamasassin, and clamav in an integrated, working configuration with no hand editing of config files needed.
I can see three standard use cases that I suspect are common enough to support:
1. All in one mail server. Serves for sending and receiving mail and stores the user mail boxes. Includes virus and spam filtering.
2. MX Gateway server. Receives mail from the outside world, does spam and virus checks, and then relays to an internal server for final delivery.
3. Mailbox Serer. Internal box that holds user mailboxes. Supports IMAP and POP3.
With the work we did in Intrepid, we’ve got all the hooks to automate postfix setup and integration with amavisd-new and integration of amavisd-new with spamassassin and clamav. I’m not sure about what needs to be provided for integration with dovecot.
Published November 2, 2008
Response in #kubuntu-devel today from a long time Gnome user I suggested give KDE4 a try:
ScottK: wow I’m pleasantly surprised, KDE4 is shockingly usable
and I like the ability to toggle compositing with a hotkey
thanks for encouraging me to try it 🙂
I have nothing to add.
Published November 2, 2008
On Monday before Intrepid’s release I decided to upgrade the kid’s computer to Intrepid and KDE4 (did I mention, I’m now a fan). I had a little time. I’d upgraded one of my machines with no serious issues. How bad can it be I thought…
Two days later it was working. I managed to trip over serious hardware specific problems in both the kernel and X windows. Fortunately not horrible enough to stop the release (you’re welcome to those, thank you very much) but definitely breaking my system. If these had happened a couple of years ago, I’d have been doomed (I know a little more now).
It turns out these bugs were pretty cool experiences. I got mentioned (not by name) in the official release notes. Bryce (the Ubuntu X maintainer) made a new wiki page for troubleshooting my X problem based on my input. I can see in the related bugs: Bug 290153 and Bug 290156 that other people have had similar problems to mine and benefited from the work-arounds I came up with.
So, it was a painful start, but the testing paid off even though the bugs aren’t actually fixed yet. It may seem like last minute testing isn’t going to help much, but it can make life easier for others. This is true post-release too, so if you are having problems, stick to working out a solution and document what you’ve done so others can benefit too.
The flip side is this can get a good dialogue going that can help you too. In Bug 290153 I got a comment today about a BIOS setting change that might help. I’ve got to look into that.