To release Samba 4.0 'as is'

[Volker Lendecke]

On Wed, Nov 30, 2011 at 05:55:48PM +1100, Andrew Tridgell wrote:
> Hi Volker,
> 
> > If we keep the S4 fileserver in and easily activateable or
> > even the default for the simple AD DC, then this is just not
> > true. From my point of view the S4 fileserver does not have
> > all the capabilities that the S3 fileserver has. Same goes
> > for winbind. Those are programs with a different set of
> > capabilities, thus a different project with that deserves
> > its own release schedule.
> 
> The 'thus' part in your logic doesn't follow at all.
> 
> At the time we added clustering support to smbd we lost some existing
> features (such as printing) when clustering was enabled. This was not
> unique - its quite common when adding a major new feature to have a
> situation where an existing feature doesn't work if you enable that new
> feature. That doesn't make it a new project, it just means we have a new
> feature that doesn't fit with an existing feature.
> 
> The new bin/samba daemon adds a huge new feature. If you don't use
> bin/samba and instead use your existing startup scripts that run
> bin/smbd and bin/nmbd then you don't get the new fetaure, but you also
> don't lose any old features. So the new release would indeed be a
> superset of the old release.
> 
> It would be nice to be able to enable all features of Samba at once, and
> in particular to be able to use the s3 file server with the AD DC
> feature. That is what the patches in my s3fs-wip branch is working
> towards, and it is an important goal.
> 
> It is however incorrect and frankly rather silly to conclude that until
> we have reached that goal that we need to split the Samba project.
> 
> > We MUST split up again. If the S4 fileserver and winbind
> > need to prevail for the reasons you stated, it will be
> > released on a separate schedule. The existing team
> > supporting the S3 components does not have enough resources
> > to support a separate fileserver implementation.
> 
> I'm not asking you or anyone else to start work on supporting the ntvfs
> file server. I've supported it fine for years and I expect to continue
> to do so. If you want to say that you won't work on a bug report if the
> user is using that feature than that's up to you.
> 
> Using this as a reason to ask for the project to split doesn't make any
> sense.

So you are saying that for sharing SYSVOL and NETLOGON in
4.0 the supported configuration will be the ntvfs file
server and for all other file shares the user should be
using the s3 based file server? If that is your goal, we do
have two separate projects that happen to be in the same
tarfile. The s3 fileserver is not supported for the AD DC,
the ntvfs file server is not recommended at least for
general file server load.

What is the reason for you to make a single release for
these completely separate projects?

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de