What's next for Samba ?

[Stefan Metzmacher]

Simo Sorce wrote:

>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.
>  
>
I fully agree in all points!!

-- 

metze

-------------------------------------------
Stefan (metze) Metzmacher <metze at metzemix.de>