To release Samba 4.0 'as is'

[Jeremy Allison]

On Wed, Nov 30, 2011 at 08:29:14AM +1100, Andrew Tridgell wrote:
> Hi Jeremy,
> 
> > I'm not saying delete the ntvfs/ code, just that we should
> > never ship a 4.0 with that code enabled. This is too big
> > a job for our small team.
> 
> I have maintained that code for the last several years. I don't expect
> that to change. 
> 
> I don't expect us to enable it by default for the release, but I also
> don't want to do anything that deliberately breaks it. So I expect to
> keep verifying that it works in autobuild.
> 
> This is the file server that all of our current Samba4 AD users have
> been using. I think it is reasonable to keep that file server at least
> as an option for those sites.
> 
> If you or anyone else doesn't want to help with maintainence on that
> code then that's fine, but I do want to keep it working, so I'm happy to
> continue maintaining it as needed. It is not a big job to maintain as it
> has been stable and working well for years. It has been the primary file
> server I use at home for at least 4 years. The only patches it has
> needed recently are trivial function renames to cope with some of the
> merge work that has gone on elsewhere in Samba.
> 
> Apart from all the other reasons I've cited in my last email, it also
> makes debugging complex AD environments much easier. I know you are used
> to the problems of using gdb with multiple processes in Samba3, but for
> me at least being able to have all of Samba in one gdb session and being
> able to set arbitrary breakpoints anywhere in the stack is a huge
> advantage when tracking down complex problems. So I expect that in some
> situations I'll enable the ntvfs server on my development box when
> trying to debug complex problems.
> 
> The modular nature of the bin/samba daemon means that maintaining two
> instances of any one module is very easy. The ntvfs file server is a
> module that only gets activated if you ask for it. The default would be
> to load the s3fs module, which loads the smbd file server.

None of this I have problems with, except we need to change
the default over before official 4.0.0 release. I understand
the current setups have been using the nfvfs one, but for new 4.0.0
installations we need to ensure everything works with the
same fileserver that high-performance and clustered implementations
use.

Now how we do that - whether it's one big binary or separate
communicating processes - is what we finally need to agree
on. I'm not a fan of one big binary, as you know.

Jeremy.