To release Samba 4.0 'as is'

[Andrew Bartlett]

On Wed, 2011-11-23 at 18:05 +0100, Michael Adam wrote:

> If we tell the people, hey this is 4.0, you have the new
> AD controller called "samba", but you can also enable
> those legacy features with those legacy commands (smbd, ...),
> then this is at the very least misleading and confusing.

> I am all for releasing a 4.0 soon, as I have mentionend more
> than once in the past (since more than a year now) but IMHO,
> we should fix the integration of the components before the
> 4.0 release. The discussions of how to do this has been going on
> since several years now and has been deferred again and again.

Michael,

Thank-you for putting your views, as it was a misunderstanding of your
views that led me to make this proposal in the first place.

The one point I would like to make is that never in my proposal did I
describe smbd et al as legacy, and I do not regard our production file
server as such.  I want every part of Samba, and every maintainer of
every part of Samba to be a proud part of Samba 4.0, because we have
much to be proud of. 

I also think it is vitally important that we provide our production file
server under the name and with the behaviour that users have expected it
to have for quite some time now.  

However, in integrating all of Samba's components, I have found that the
'simple' task of integrating Samba3 and Samba4 has been anything less
than simple.  As we look into each small element of the task, we have
found a multitude of issues, and slowly and successfully dealt with them
all so far.  I would like to continue to give these issues the attention
they deserve, while also giving our users the release that they are
crying out for.

> > > I also propose that we do not make the major architectural changes
> > > between now and the release to change file server or winbind
> > > implementations for the AD DC.  Instead, we continue to build on the
> > > massive efforts already made here over the next few months, but we will
> > > not change the default behaviour for a 4.0 release.
> 
> To my understanding, this is what release branches are for. :-)

I would be very glad to cut a release branch of Samba 4.0, or to
maintain it in master under our continuous integration process backed by
autobuild, whichever we fell will give us the highest quality release. 

> > > With this plan, and with the quality brought about by our continuous
> > > integration approach, I think we can make a Samba 4.0 release in a
> > > reasonable time-frame, perhaps with a final release in about three
> > > months time.  
> > > 
> > > This will mean we continue to ship smbd, nmbd, winbindd, samba etc as
> > > found in the current alpha releases. 
> 
> This would basically mean that 4.0 will be a AD-only release.
> The s3-fileserver components would just be dropped as a
> snapshot and whoever wants to seriously use those components
> should use the 3.6 release or wait for 4.X? I think this is
> counterproductive and setting the wrong signs for our users.
> 
> For me Samba 4.0 should be not be the result of the
> samba4/source4 development efforts but the superset of
> s3 and s4 development, the outcome of our combined efforts.

I strongly agree.  Perhaps you can help here:  Do you feel that the smbd
file server in master is in a fit state for release?  I certainly do not
wish to simply snapshot something that is not prepared for release, and
I would appreciate your feedback here.

> I repeat, for me the only decisive and strictly necessary step
> for releasing 4.0 at this stage is that the intergration efforts
> are completed. All fileserver or AD featurs that are missing or
> incomplete can be added later on.

I know you disagree, but I actually believe that the required level of
integration has been completed.  Our users consistently report that they
find Samba4 to be incredibly well integrated, and are impressed by how
well they can just provision the domain, and simply start 'samba'.
Additionally, the smbpasswd, net getdomainsid and other passdb commands
now work, and we have a migration script.  My view is that the file
server switch is indeed like other AD features, something that can be
added later on.

Putting aside the file server, are there any other integration tasks
that you or others in this thread have found missing in your day-to-day
use of Samba's AD server?  (It was only real-world use that brought up
the 'net getdomainsid' example). 

I'm trying to support our Samba AD DC users in the best way I can, yet
clearly I have stepped on a number of toes and uncovered some very
deeply held feelings about what the future of Samba looks like. 

Do you think it is possible to find a way to release the code our
production users are using to date?  Do you think we may possibly be
able to explain to our users that we are keen to get them these
features, but list the limitations?  If we released the same thing, but
called it 3.7 while we waited for a more unified 4.0, would that help?

I would appreciate your advice here,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org