To release Samba 4.0 'as is'

[Volker Lendecke]

Hi!

Maybe having two file servers (and winbind implementations)
in one release is a good thing. I seem to be the only one
having problems with it, so we should just do it the way
that was proposed.

Thanks for the clarification.

Volker

On Wed, Nov 30, 2011 at 10:51:16AM +0100, Michael Adam wrote:
> Moin Volker,
> 
> Volker Lendecke wrote:
> > On Wed, Nov 30, 2011 at 12:43:59AM +0100, Michael Adam wrote:
> > > We have agreed in the past that the samba3 smbd file server
> > > should eventually be the file server in the 4.0 release.
> > 
> > This agreement has been recalled within this thread by very
> > clear words.
> 
> What do you mean? You mean that this has been revoked?
> Citing Tridge from another mail:
> 
> >>> In past discussions I tried to make it clear that I didn't want
> >>> the ntvfs/ code to be deleted, only that the default should be
> >>> the s3 smbd one.
> 
> I.e. the s3 smbd will be the default file server in the 4.0 release.
> 
> This means in particular that before we can release 4.0, we need to
> get the plumbed design into autobuild. And this means that we
> need to finally agree on the plumbing method, a discussion that
> started with the "Franky" idea several years ago.
> 
> And we can not release 4.0 as is, since we first must
> fix the issue with the samba<->smbd plumbing, and give
> it enough cycles to run in autobuild.
> 
> > > (If this is the default, then I think it should not be a problem
> > > to also keep the s4 fileserver part (at least for a while) so that
> > > it can be enabled if desired.)
> > 
> > What does that mean in practice? If that code is available
> > in the build, people will enable it. What happens if bugs
> > pop up then? Will we tell people this is an unsupported
> > component, or will we put the same energy into fixing those
> > bugs in the S4 file server component that we put into the S3
> > file server? The first option ruins our reputation, the
> > second one just overloads us. I don't thing any of those two
> > alternatives is acceptable for us.
> 
> Not everyone of us fixes bugs in each component of Samba.
> Not even now. Why do you imply that it is _you_ who will
> have to fix the bugs in the ntvfs file server of the AD-DC?
> 
> Do you likewise imply that it is you who will have to fix
> the bugs in the AD sam ldb-database? Or in gensec? Or that
> Tridge or Andrew will have to fix the bugs in the smbd file
> server?
> 
> It will be good if a combined release leads to people touching
> more components of the samba code base but it does by no
> means imply that all developers have to be experts and
> bugfixers in all components right away. And you know that.
> 
> With this argument, we could never really release anything
> that is a combination of s3 and s4 components, not even
> samba3 itself.
> 
> Also, coming back to the two file servers, I don't think
> that it will be a problem to simply have the s4 file server
> part still around. The smbd file server part should be the
> default and we should make it very clear that the smbd file server
> is the default and supported one. It should be necessary to switch
> on the s4 file server explicitly. We could easily document
> the limited cases in which using it can be useful.
> 
> At least my understanding is that it is not the intention to
> deprecrate the samba3 smbd file server in the long run by
> forcing the s3 file server in through the back door, which
> is what you seem to imply. The opposite is the case.
> 
> Tridge has made a very valid point of keeping the s4 file
> server (for now) for a couple of reasons:
> 
> * Supporting existing s4 installations keeping the
>   currently used components for a while.
> 
> * Enhance his debugging in reproducing bugs locally.
> 
> * Have the code around with its design. This has some
>   nice ideas which we can stem on when working on the smbd
>   file server.
> 
> What is so bad about it? I expect the cases in which we have
> the ntfvs file server around in production to be not so
> many, and decreasing. Eventually, I hope to reach the point
> where we only have one file server.
> 
> Cheers - Michael
> 



-- 
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