Why Samba development is hard
kai at samba.org
Thu Feb 28 17:55:54 GMT 2008
in the past days I have been pretty frustrated with the things I've been
trying to develop for Samba4. In this post, I will try to identify the
reasons for this so we might try, as a project, to make getting into Samba
development easier. This post focuses on Samba4, as this is where I spent
most of my time so far although I'm afraid some of this will apply to Samba3
While I'm certain that being the Samba team member with the least number of
patches in Samba I would hope that this doesn't just boil down to my lack of
experience with programming in general and programming C in particular.
Problem 1: Documentation
Samba4 has some really nifty design ideas and a really cool technology behind
it. However, if you haven't been around while all the pieces were designed
and discussed, it's really hard to find out how to actually _do_ things.
Documentation seems to be in one of following states: outdated, wrong and
nonexistent. I spend lots of time trying to figure out how to do pretty
simple things. Often, catching abartlett, jelmer, simo or metze on IRC is
sufficient to get a pointer in the right direction, but this means one of
them has to be available at the time you bump into your problem or you're
stuck until one of them answers. Which brings me to problem number two.
Problem 2: Feedback
Getting feedback is hard. Sending patches to samba-technical seems to only get
replies if the topic is controversial like my recent idmap patches. Coming
from a project where all patches are sent via a mailing list, sending patches
to samba-technical seemed like a good idea. In Samba this obviously isn't
that useful, judging from the response not only me but also other people get.
Just submitting things seems to get better feedback, but of course that has
obvious downsides for less experienced developers.
Problem 3: Complexity
This is of course related to problem 1, but a different facet. Getting some
parts, e.g. the build system to do what you want can be really complex. Today
I stumbled over make proto also including code between #if 0 .. #endif. While
that's not too surprising if you think about it a bit more, in the beginning
it really puzzles the heck out of you how broken code that's not compiled
could break the build. A lot of things that seem obvious to more seasoned
developers aren't that obvious at all. This is probably hard to document,
it's just something we should be aware of.
Unfortunately I don't have any brilliant idea on how to get the learning curve
to be less steep. Maybe we could give this some thought before the next
Summer of Code starts. If we can get the learning curve low enough for
students to cope with it, that will help all other prospective developers
too. Also, Volker asked me to not only whine at the SerNet bunch. ;)
Just my 0.02 EUR
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
Will code for cotton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.samba.org/archive/samba-technical/attachments/20080228/e5c2c6fc/attachment.bin
More information about the samba-technical