Debian describes itself as the Universal Operating System, and basically tries to run in the same way everywhere, from an NSLU2 to an s390.
I find it funny to see the number of Ubuntu variants. I can understand that for marketing reasons (Debian doesn’t really know about marketing), it is good to advertise Kubuntu, Xubuntu, etc. Even if it’s the same distro and the same packages. But seriously. An Xubuntu EEE now.
I’m the happy owner of an Asus EEE PC, running Debian. Installing Debian on it is quite straightforward, and only requires you to install the module for the ethernet NIC (available as Debian package), to compile the madwifi driver (non-free, patched version needed) for Wifi, and hack a few scripts in /etc/acpi if you want to get the hotkeys (volume, etc) working. Nothing impossible, really. And for those not familiar with the command line, some detailed documentation could be written, or a Debian package or a script that does all the tuning could be provided. (I think all of this has been done already anyway)
But an new Ubuntu derivative! Just for that! Are we going to see a new Ubuntu derivative for each new laptop that is not perfectly supported yet? Hey, my desktop PC’s keyboard has some hotkeys that don’t work properly without hacking .xmodmaprc. Can I get my Ubuntu derivative? :) Also, GNOME works perfectly on the EEE, and I assume KDE does as well. What about Ubuntu EEE, and Kubuntu EEE?
Now, let’s watch the flow of blog posts from Ubuntu fans acclaiming the release of the Xubuntu EEE.
Comments closed, trackbacks open.
Andreas Schuldei writes about my blog post about making it easier to contribute to Debian:
It is much more gratifying for a contributor if his effords have
So what can people who want to help Debian do to achive more imminent gratification? Pick projects that let you help directly with direct svn/git/whatnot access (Security team, Debian Edu, Debian-Installer…)
While I agree that Instant Gratification is very important, I don’t think that the proposed solutions solve anything. It’s easy to have things sleep in an SVN repository instead of the BTS (lots of teams do that, sometimes for good reasons, like the lack of sponsors – hint: Games team). It doesn’t make things any better. What we need is tasks whose results will be available without too much wait in Debian unstable, for everybody.
Also, I must admit that I know very little about the inner workings of the Security Team. But I have the idea that it involves quite a lot of procedures (helping with bugs tagged security probably doesn’t, but going further than that probably does). Contributing to Debian already involves A LOT of procedures. A new contributor, even very good technically, can easily get lost in all the different ways to package stuff and solve common problems. So we should identify tasks that don’t have huge requirements. Ubuntu has the concept of bite-size bugs.
I started working on a page explaining the different ways someone can contribute to Debian. The goal is to provide a good entry point (not something that replaces existing documentation) and keep it at a manageable size. Its focus is mainly to replace the emails we write to people asking “I’d like to contribute, but I don’t know what I can do or where I should start!”. The page is available on wiki.d.o/HelpDebian/Start. Don’t hesitate to improve it (see also wiki.d.o/HelpDebian for a TODO list). When it will be good enough, I plan to move it out of the wiki (the content shouldn’t change much anyway) to eg http://help.debian.net/, so we can improve the design (I really like the idea of adding pictures of past Debconfs like Christian Perrier did in his FOSS.in talk).
Debian could use more manpower, but is it actually easy for new contributors who would like to help to do useful things, and get the impression that they actually improved Debian?
There are several problems here:
- Find bugs that are not too hard to fix. I don’t know about your packages, but in mine, there are some bugs that are easy to fix, and it’s just a matter of finding the time. If someone provided a patch, I would be very happy and apply it or provide feedback as fast as possible.
- Find packages with active maintainers. It is no secret that if you choose the wrong package, your patch could very well sleep on the BTS for years.
- Find bugs that actually matter. It’s not strictly a requirement. But fixing bugs in packages that should probably be removed from Debian instead is not really rewarding.
I think that other projects are better than us at providing directions to newcomers. Gnome has the whole Gnome Love thing, for example.
I’m thinking about building lists of “interesting” bugs. That would include RC bugs without patches, of course, but could also include a list of bugs based on an usertag that would mean “This bug is suitable for new contributors (it’s not too hard, and you could learn things fixing it). If you want to work on this bug, I’ll provide help and feedback and integrate your patch ASAP.”
(This is very different from the “help” tag, which usually means “I couldn’t fix this, it’s too hard, I need help.“. It’s a bad idea to direct newcomers to bugs that are too hard for the package’s maintainer!)
Additionally, a nice feature would be to be able to filter the list of bugs with the packages that the user has installed.
- What do you think?
- As someone willing to contribute to Debian, do you often find it hard to find stuff you could do?
- As a maintainer, do you have a lot of bugs that could use such a tag? Would you use it?
Comments are open, please us them ;)
I didn’t know about that movie. Funny. Will try to remember to use the poster in a databases course ;-)