Mark Rogers mark@quarella.co.uk wrote:
I recently decided to do precisely this (not with Qemu, but with a GPL licenced home accounts package), and I quickly realised just how much stuff I don't know (and need to know) just to get started. [...]
Well, I did also mention "have it adapted"... but is that just a hope stated by people who understand some software package(s) that isn't properly documented or easily understood? ;-)
Anyway, I still have the same problem sometimes, when meeting new ways of working or new components. Often they aren't documented and sometimes my need to get the work done means that I don't map my path in as well as I should. I'm getting better, using git (the kernel version control system, which seems to be able to work independently even if upstream uses CVS or SVN or whatever) and trying to keep my own Changelog, README and NEWS. I'm probably still not publishing them as often as I should, though, and my contributions of in-code documentation (POD, autogsdoc, mole and whatever the php one is called) are still not as frequent as they ought to be.
Version control command lines suck. If possible, either put the common commands into a Makefile (I've usually got "make download" to update to the latest version and "make check" to run git status, cvs status or whatever) or use a plugin for your editor (Emacs VC-mode seems pretty good to me).
Do you need to use version control at first? Often I start development of my extensions on the last stable release, rather than the developers' version control. I know lots of people tell you not to do that, but I find it works for me, most of the time: I don't have to worry so much about other bugs in the core between releases, but sometimes it does mean you hit a known bug and have to port your changes forwards sooner than expected. Also, if a package has got neither a working stable release or a good developer's introducts, you should be very cautious about getting involved.
When contributing a feature originally developed on a stable release, I unpack the latest development source, the stable source I started from and my modified source and use a 3-way merge tool (Emacs emerge with ancestor most often IIRC) to port my changes forward into the latest development source. Then a version control diff gives me a patch to submit.
Not sure if this is just a rant, or whether I'm asking for help somewhere. If there is a good "getting started in FOSS development" book I'd like to know about it. [...]
They're no dummies books, not free-software-specific but http://www.robson.org/gary/writing/becomeahacker.html and http://www.catb.org/~esr/faqs/hacker-howto.html may help. Beyond that, I guess questions here, IRC or the various message systems are as good as anywhere.
Beware bad advice, though. I ranted about this recently in http://mjr.towers.org.uk/blog/2006/software#bewarewebadvice and if I had a fiver for every time I saw a web app install guide that instructs users to chmod 777 (a+rwx) a directory (a bad idea 9 times out of 10), I'd be buying all the beer at ALUGs.
Learning programming well is a good idea. I think it helps if you have at least understood a bit more than 'Hello world' with at least one from each of these lists: 1. Mostly imperative: C, Perl, PHP, BASIC, ... 2. Mostly object-orientated: objC, C++, Smalltalk, Ruby, ... 3. Mostly functional: Scheme, CLisp, Elisp, Haskell, ... 4. Mostly unusual: Forth, PostScript, SQL, Tcl, ... (Note I wrote *mostly* - these days, it's almost all languages can do all styles, which is why knowing at least one of each is helpful.) http://www.levenez.com/lang/ for links.
I think the biggest problem I have as I get older is remembering that nearly all software problems are either: a. easy; or b. easy after redesigning the software; but it's not always easy to tell which is which if the documentation isn't understandable to you, and redesigning is often more work than it's worth, especially if you face flamey opposition from the present designers!
Hope that helps,