To release Samba 4.0 'as is'

[Michael Adam]

Hi folks,

Andrew Bartlett wrote:
> On Thu, 2011-12-01 at 14:51 +0100, Lars Müller wrote:
> > On Thu, Dec 01, 2011 at 09:46:13PM +1100, Andrew Bartlett wrote:
> > [ 8< ]
> > > The problem is that the only smbd that works with Samba4 AD is the smbd
> > > in master (to get the pdb_samba4 and auth_samba4 hooks, and the correct
> > > version of the named pipe auth protocol).
> > 
> > How hard and risky would it be to make this work with 3.6.2?
> > 
> > If that's impossible I'd prefer to negotiate on a timeline for a 3.7
> > release.  Let us reserve the initial 4.0 release for the release when we
> > consider the merge as finished.
> 
> The changes made between when 3.6 was branched and now are not massive,
> but they are not of the kind that can be put into 3.6.  pdb_samba4 and
> auth_samba4 are built as part of the top level waf build, and operate in
> that integrated build.
> 
> I don't mind what our next release is called - be it 3.7 or 4.0 or 4.0
> AD, as long as it contains the AD server so our users can deploy it.

I do mind in fact: I think it is very important to call the first
release that contains the AD server 4.0.

Let me state the main issues that I think we need to solve/agree on
before we can move forward to releasing the samba AD server:

1. What version should contain which components?

  As I stated in a previous mail, this is my view:

  * As soon as a reasonable feature set of the AD server is
    releasable in a fashion sufficiently integrated with the
    s3 smbd file server, we should do the 4.0 release.

  * Until that stage is reached, we should continue doing
    3.X fileserver releases if new features in s3 are worth
    releasing.

  Is that something we can agree on?
  This is imho the first and most basic thing we need to agree
  (or disagree) on.


2. Next thing to decide is what components to use together.
in the AD-server mode.

* I think I am not misinterpreting our previous discussions
  when I state that we have agreed to have the s3 smbd file
  server as the default file server. We can keep the s4
  file server around and provide an option for enabling it
  for testing/debugging and existing production setups for
  some time at least.

* The nmbd needs discussion. The s3 one lacks wins replication,
  and the s4 one lacks browsing support.

* It seems winbindd also needs discussion.


3. Next is the question of "integration", i.e. how should the
   main samba daeomon and the chosen s3 components (especially
   smbd) interoperate? As separate daemons (e.g. smbd spawned
   by "samba") via the rpc channels and so on (basically the
   franky approach) and via the pdb_samba4 or pdb_ads modules,
   or via direct function calls, the smbd part loaded as shared
   object (basically the libs3compat approach).

   My impression here is that the franky style approach will
   probably be the way to a releasable state (it is in fact
   already used in the univention setup), but this might as well
   be due to lack of knowledge about the stage of the s3compat
   efforts.

There are many more techical details and questions about which
feature should belong to the supported feature set and so on,
but I think these 3 topics are the fundamental ones to decide
before we can move forward to releasing a 4.0.

As for the release itself, when these things are settled and
the implementation is far enough, we should for v4-0-test
and v4-0-stable release branches and continue stabilizing
the code base with betas, prereleases and release candidates
just as we have done for the past 3.X releases.

Opinions?

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/20111207/b6f0b4df/attachment.pgp>