Why Samba development is hard

[Nadezhda Ivanova]

I totally agree! I would really like to participate in Samba 4 development,
but currently it is very hard to get the info necessary to do so. It is not
clear which features are incomplete, for example, and who is working on
what, and what is the general design of a feature, so that new patches do
not contradict with it... It would be very nice to have more info on these
things.

On Thu, Feb 28, 2008 at 7:55 PM, Kai Blin <kai at samba.org> wrote:

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