Why Samba development is hard

[Kai Blin]

Hi folks,

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 
as well.

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
Kai

-- 
Kai Blin
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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.samba.org/archive/samba-technical/attachments/20080228/e5c2c6fc/attachment.bin