Default DNS server for Samba 4.0

Andrew Bartlett abartlet at
Fri Sep 7 16:17:17 MDT 2012

On Fri, 2012-09-07 at 09:04 -0700, Jeremy Allison wrote:
> On Fri, Sep 07, 2012 at 11:54:45AM +1000, Andrew Bartlett wrote:
> > On Thu, 2012-09-06 at 09:48 -0700, Jeremy Allison wrote:
> > > On Thu, Sep 06, 2012 at 02:03:18PM +0200, Kai Blin wrote:
> > > > 
> > > > As I mentioned before, I didn't see that much difference between the
> > > > alpha and beta releases. We had two beta releases that were more broken
> > > > than many of our alphas were. I fail to see how that is stabilization.
> > > > RC1 is the first point were we draw a line on the ground and say "from
> > > > here on, we focus on making it work reliably".
> > > 
> > > +1 on this, a *massive* +1 on this.
> > > 
> > > While the tree is open for checkins from anything that
> > > passes "make test" this is not stabilization. Stabilization
> > > will come when we have to have 2+ engineer review and an
> > > open bug to make any changes, with Karolin gatekeeping.
> > > 
> > > This has worked *AMAZINGLY* well for the 3.5.x and 3.6.x
> > > releases, and I think we'll find the same for 4.0.0.
> > 
> > Jeremy,
> > 
> > You may not have noticed, but in the AD server, the stabilisation phase
> > started started a number of months ago.  Essentially it started with
> > beta2, when we turned on s3fs.  Since then I've focused myself almost
> > entirely on fixing bugs and writing tests, mostly related to the
> > ACL/idmap interactions to support GPOs on smbd.  
> Sure I've noticed that, and I commend you on your restraint.
> But it isn't the same as the stabilization we get on a released
> branch.


It certainly isn't the same as the stabilization we get on a released
branch, or how we have released software before.  The philosophy is much
more of 'continuously, proven reliable' than a black and white
'development' and 'stability' phase.  For users, the big difference is
that we actively encourage users to try Samba 4.0 beta in production!

It is this track record that then encourages me to know we are entering
the release candidate stage ready for the final release.

Understanding where I'm coming from might help you understand why I
reacted so negatively to a proposal:
 - to change the default on the *same day* that the code, particularly
the security-critical GSS-TSIG component was first thought to be
 - and while the relevant tests of that component are yet to be

Where I have clearly failed is in making it clear to Kai from the outset
that just as his earlier code has tests, that the GSS-TSIG server also
needed that (and honestly, a higher) level of scrutiny. 


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list