To release Samba 4.0 'as is'

[Kai Blin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2011-11-30 09:05, Volker Lendecke wrote:

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

Actually, combined with a couple of other ideas in other branches of
this thread, here's an idea...

I'm not sure if this is the best solution, but it might be a workable
compromise that addresses the following issues I've seen brought up.

So, the basic idea is "Release Samba 4.0 as is, as soon as possible".
But, as people already mentioned, there's still a lot of work to do
there, and we can't even agree on the best way to proceed that'll
still allow us to release Samba 4.0 soon.

As other people have mentioned already, part of this actually is just
a branding issue.

For the AD DC part, we know there's enough good stuff in there that
people are already running the alphas, and we wish to put a stake in
the ground at some point and call it a release.

Now, the file server folks are currently all over the place working on
getting more of the SMB2 features implemented, and don't feel like
they have time to deal with a release right now (I don't think anyone
would feel like releasing a 3.7 any time soon).

Can we reasonably release Samba AD Server 4.0 soon, that is just an AD
DC server, and knows a little bit of file serving so it can server
SYSVOL and NETLOGON? We clearly state by name and documentation that
it's designed to be and AD DC, and if you're trying to do anything
else it might as well eat all the food in your fridge and put all the
wrong DVDs in your DVD cases.

Then, as soon as the SMB2.1/SMB2.2 stuff is far enough along that we
can call that a release, we release Samba File Server 4.0?

I would suggest that we spend some time to get the releases into sync
afterwards, so 4.1 AD Server and File Server release at the same time,
but I don't see why we can't split up 4.0. We could even fiddle with
the smbd/winbindd/nmbd code for the 4.0 AD Server release so they
refuse to start up, telling people to keep running 3.6 if they want a
file server until 4.0 File Server is done.

We'd then have to keep the 4.0 AD Server part stable until 4.0 File
Server is done, or that'll lead to support issues, but that's what a
release branch is for, right?

So basically my proposal is the following:

1. Pretty soon now, release Samba 4.0 AD Server
 - For this release, make sure smbd/winbindd/nmbd only run #ifdef
DEVELOPER or somesuch
 - When releasing 4.0 AD Server, we branch of the 4.0 release branch,
bug fixes only, unless it's features for the file server.
2. Once the file server is ready to release, unbreak smbd/winbindd/nmbd
 - 4,0 release branch is now bug fixes only for all components
3. We get our act together and work on releasing 4.1 AD Server and
File Server as a single release.

That way we won't create the impression that we consider Samba 4.0 AD
Server a full superset of the 3.6 features, and still get the AD
components released soon.

What do you think?
Kai

- -- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7WGZEACgkQEKXX/bF2FpR2YwCfZsdfZ3Nq8oHqap310fKt5juI
XEUAniyJ8SLawzWlq6YkAfs5js7ZT1Du
=KnSj
-----END PGP SIGNATURE-----