To release Samba 4.0 'as is'

[Michael Adam]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111130/add9d97b/attachment.pgp>