Bureaucracy and code quality

The Xen developers have a quite bureaucratic approach about getting patches in - say, they simply refuse to even read a mail that doesn't have PATCH in the subject line, and they asbolutely refuse to consider making a change you only _describe_ to them - but that doesn't mean only high quality code gets in.

I had the funny experience, that a bugfix hint from me about a bug in the xendomains script, which only required one line to be changed, and me therefore not bothering about creating a patch with diff, simply didn't make it in.
I even created a bug report in bugzilla(which is generally not taken care of anyway, and my attempt to make that better was welcomed warmly, but not supported in any way at all), _and_ wrote a mail to the devel list.

Checking it again some half a year later it looked like the problem had been solved - but not with my patch. They took another one - one that was, instead of 1 line, 15 lines... The problem with my patch was - read it, reall: I DIDN' T SEND A DIFF - for ONE line of change - I think that is how crappy Shell script code like Xen's network scripts come sto live.

That way, you get hackish stuff of hundreds lines of shell code, that is really hard to grasp. surely, you're better off writing your own - as somebody I share my firstname with, also realized...

That blog was the actual cause of me writing this - I saw this post, thought about the script's quality, and my experiences with trying to help improve Xen.

There was another similar thing, quite recently: the Xen build dependencies are still not documented nicely in the source's README file. As I saw another guy writing about this on xen-users, I thought I'd let the developers know, and ask them why they don't change it. My mail, being ignored at the first attempt, requiring me to write a second NAG mail, again got only the reply that it _must_ be a diff-created patch - even if the committer must check it anyway, and even if it is a simple list of strings, and an obvious, single place where to put it...

The only thing I can conclude is: Here, we see a development organization, where clearly, bureaucracy is more important than code and documentation quality.

I guess it's not hard to understand that I'm not exactly motivated to send hints for improvement for Xen anymore.