No matter who you are, what you do, or what level of programming
ability you have, there are ways that you can help out with UML.
If you don't program at all, there are a number of things that you can
do. The main one is to just use UML. Report any bugs, problems, or
rough spots that you encounter. If you find workarounds, tell us
about them, too. There are a large number of different kinds of
environments out there, and there may be assumptions accidentally
built in to UML that cause it not to work, or not to work well, in
some of them. The more people we have using UML, and the wider the
variety of situations it's used in, the more robust it will become.
You can check the documentation - you probably will do so in the
course of learning what you can use UML for. The main thing that you
can do is report any problems you find.
If you want to help in a more systematic way, you can
Documentation fixes will be accepted in any usable form, including a
general description of something that needs doing, suggested text as
just text, or fix to the XML source for the documentation.
proofread it - I try to be grammatical and spell things correctly, but
sometimes mistakes slip through.
fact-check it - in particular, make sure that the step-by-step
procedures actually work. They occasionaly get out-of-date,
describing methods of doing things that no longer work because new
ways have been introduced and the old ways removed. They may not work
in all environments. They are mostly written up after I've got them
working on my laptop. Your machines may differ, and they may differ
enough that my procedures don't work for you. Also, I may have found a
overly-complicated way of doing something. If you know a simpler way,
you should let us know about it.
style-check it - it may be that a way of doing something is correct,
but poorly worded or confusing. If you get lost trying to do
something, you should complain about it. If you persevere and figure
out how to make it work, it would be very useful for you to go back
over the documentation and see where you got lost. Then, figure out
what it could have said that would have prevented you getting lost,
and send that in.
If you want to get more involved in the documentation, it is described
If you want to contribute code to UML, but you aren't a kernel hacker,
there are a number of areas that need work. There are a number of
tools that come with UML that aren't strictly part of it, but which
make using it easier in some way (such as the uml_net networking
helper) or which provide access to UML functionality (such as the
mconsole client). There are a variety of enhancements that can be
made to these.
Various applications of UML are going to require tools which don't
currently exist. For example, for UML to be most useful for virtual
hosting, there need to be tools which can configure and run a virtual
machine for a new customer. People who are doing networking of
clustering experimentation with UML need something similar, except
that it needs to be able to construct a specific network of UML
The UML packaging is somewhat ad-hoc at the moment. I've learned
enough about both RPM and Debian packaging to be able to put together
defensible UML packages in both formats. However, I'm sure that
they would not be considered 100% kosher by either camp. So, there is
a need for packaging experts to have a look at the UML packaging
procedures, find the mistakes, and fix them.
Contributing code to UML itself is not completely out of the question
if you're not a kernel hacker. Since UML is a port of the Linux
kernel to Linux, the lowest levels of the code, which in other ports,
are hard-core hardware-specific code, are generally fairly
straightforward userspace code. That code does stuff like read files,
talk to pseudo-terminals, communicate over the net, etc. It's
perfectly possibly for people who don't know about kernel programming
to contribute useful stuff here.
If you're a kernel hacker, you can find and fix bugs in UML. I've
listed the bugs (and some features) that I want to fix before UML V1.0
There are also a number of longer-term projects described
here. These are the
post-V1 things I want to do, but I certainly have no objection to people
starting work on them now. They include things like adding SMP
support, implementing clusters of various types (first DSM-based
clusters, moving to more standard RPC-based clusters), making Linux a
better host for UML, ports of UML to more architectures and to other
operating systems, and a variety of other things.
There are some things that you can do to help out UML, no matter who
New applications - I have a number of applications of UML listed
here. I am but one
person and my imagination is limited. If you find UML useful for
something and it's not listed there, let me know.
Propaganda ... err, spreading the word - If you find UML useful for
something, chances are you know other people who are doing the same
thing who don't know about UML. Tell them about it. Recommend most
strongly that they start using it. If you know of web sites or
publications that would be interested in UML, suggest that they write
Donations - Other sorts of things will be cheerfully accepted
Hardware - A good rule is that anything that gives me faster kernel
builds is good. SMP kit is also good, since UML has displayed races
on SMP machines that aren't seen on UP machines. Non-x86 hardware is
good, particularly if it comes with an interesting vendor OS (i.e. VMS
or OS/400). This will help out the UML porting situation.
Money - It can be exchanged for the aforementioned toys, so it's good
Anything else - Get in
touch and we can discuss it.