To release Samba 4.0 'as is'

[simo]

On Wed, 2011-11-23 at 13:35 -0800, Jeremy Allison wrote: 
> On Wed, Nov 23, 2011 at 04:23:23PM -0500, simo wrote:
> > On Tue, 2011-11-22 at 17:13 +1100, Andrew Bartlett wrote:
> > > 
> > > What do others think?
> > 
> > I think this plan makes no sense.
> > 
> > Dropping an alpha release on the floor and slapping the "stable" sticker
> > on it is not what our users expect.
> > 
> > I no way the waf build is currently usable in production for the file
> > server part.
> > 
> > Many have chimed here so I will not repeat all the very sane points made
> > by a great number of people, please listen to them and do not just
> > dismiss their concern. They may be related to specific issues that may
> > look minor to you. But I assure you they are definitely not.
> > 
> > We are the people that will have to *support* whatever is dropped out
> > there. And we want to be comfortable we *can* do that job. We currently
> > can't without still great pains.
> > 
> > Any regressions in the build system or in the file server functionality
> > is not acceptable. Half assed daemons like samba4's winbindd are not
> > acceptable in my book.
> > 
> > Please work (as you promised and we all agreed since 2 years now) on
> > eliminating by integrating all duplicated functionality in the trees.
> > Once that is done we will be close to something we can call a *stable*
> > release.
> 
> Personally I think following Matthieu's plans for getting to a release
> make great sense.

I am not sure what are the details of Matthieu's plan, but if smbd
integration is part of that plan this is probably going to be the right
way.

> Log specific bugs for all known issues, triage to see which are
> blockers - add them to the "4.0 release" bug, then when we're down
> to a reasonable set get Karolin to spin off the release tree and
> follow standard proceedures to get to final ship.
> 
> That's the only way we can do this IMHO.

There are other aspects that need finishing that I want to add to the
pile. For example right now we have a nice working End Point Mapper in
s3 that we use to have a lsa and a spoolss daemons. This also should be
integrated with the current samba4 counterpart that has it's own EPM
daemon which doe snot integrate with external spoolss and lsa daemons.
The external lsa daemon in particular is needed in order to let a DC not
based on the samba4/AD layer respond over TCP/IP which is a
functionality we developed in order to use samba as part of FreeIPA to
support cross realm trust relationships with AD/Samba4-DCs.

Not sure how that would be filed as a bug.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>