What's next for Samba ?

Simo Sorce simo.sorce at xsec.it
Thu Nov 13 10:11:19 GMT 2003


On Wed, 2003-11-12 at 22:03, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Heads up,
> 
> I'm opening the floor for discussion about the feature
> set for the next major Samba release.  Will it be Samba4?
> Will there be a 3.1?  Who knows?
> 
> For a little bit of history, we have historically lived
> on a release for anywhere from 2 - 3 years (2.0 was 2 yrs.
> & 2.2. was 3 yes.l..i would have to check on 1.9).  What
> I would like to see is to shoot for release on a 12 month
> timeframe.  This means that we would need to be in beta
> release by somtime in June to release by Sept/Oct.
> 
> So what do people want to get done in the next 7 - 8
> months.   Let the games begin.....


Jerry, Team, 
I've been thinking about that a bit lately.

My conclusions are:

1. you are proposing a tight time frame, but that's ok.

2. samba4 is still in early stages of development and I think that to
make it a good candidate for upgrade from samba 3, we will need more
time, I think we cannot have it ready (with all the features we
currently have in samba 3) to be shipped in Sept/Oct

3. samba 3 has still room to grow, and we all have some patch or entire
areas of code we would like to put into to make a good 3.1/3.2 release
and address some missing features we still have.

4. I do not think backporting from samba 4 is a wise thing. It has the
potential to destabilize the code.
Unfortunately our code is very interdependent in all parts and changing
a single function often have a cascade effect on code you never imagined
you had to change, I've stepped in such problems so many time in the
past that backport from samba 4 sounds to me like a "hell of troubles".
Samba 4 has many core differences from samba 3 code base that will make
it hareder to backport then just swith over to samba 4.

So given these premises, I think we should keep the branches separate,
use samba4 test suite to correct problems in samba 3 if necessary, and
set out the features we want to implement what I would call samba 3.2,
by making an 3.1 development branch (HEAD).
I wouldn't accept great code revolutions in the HEAD branch except for
key areas that really _need_ to be enhanced.

Every other effort should go in the samba 4 code. That way we can think
of concentrating in some key features for samba 3.2 that can be done and
tested in a 1 year time-frame, and instead make all others go to develop
samba 4 so that in 2 years we can get out with it fully featured.

My ideas for samba 3.2 are of course to finally center the goal of being
able to correctly interoperate with windows DCs, that means PDC<->BDC
replication, privileges, WINS replication, more active directory
support.
Adopt all the possible advices in the samba 4 progranmmers guide, so
that code made for samba 3 can be easily ported to samba 4.

While for samba 4 I would like to see the "librarization" of our code.
Split the code in smaller chunks that can be reused easily, lowering
interdependence and thus elevating the ability to make changes in our
code withouth having to refactorize everything for every minimal change.
Enhance our modules support by getting out with development headers and
libraries so that modules can be compiled even without the samba source
code.



Simo.

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l. - http://www.xsec.it
via Durando 10 Ed. G - 20158 - Milano
mobile: +39 329 328 7702
tel. +39 02 2399 7130 - fax: +39 02 700 442 399



More information about the samba-technical mailing list