To release Samba 4.0 'as is'

[Lars Müller]

Hi,

a sorry from my side too for the late reply on this quite important
topic.  Unfortunately I was ill the last week and then had been thinking
about how to handle this issue best.

a) A Samba 4 release which is incomplete will cause bad press.

b) To release Samba 4 including 3 as it is at that time might not
provide a result our users and vendors are happy with.  The common
release has to be driven by our release manager as we did very well in
the last years.  This includes the usual alpha, beta, rc cycle as we did
in the past.  Metze stressed this point too.

c) It's possible we'll see enough s3 development that one, two, or even
three releases might be there before a Samba 4 as described before is
ready.  I would appreciate to see our Samba developers focussed more on
Samba 4 right now, to participate in this process to get enabled to
release Samba 4 in the same well structured way as we did it for Samba 3
in the last years.

d) For the first Samba 4 release we have to negotiate with all
involved people how we'll target the Samba 3/4 merge for a first common
release.  Without a smooth upgrade path we risk to lose operating system
vendors.  The majority shipped Samba 3 for many, many years.  And they
have customers which expect a simple and working upgrade.

On Tue, Nov 29, 2011 at 01:44:57PM +0100, Stefan Metzmacher wrote:
> 
> Am 22.11.2011 07:13, schrieb Andrew Bartlett:
> > I would like to propose that we proceed to making a pre-release of Samba
> > 4.0 in the next month (ie, before Christmas), and that we propose to
> > release Samba 4.0 'as is' regarding major features.
> > 
> > To be clear, I propose that the DNS server work continue, and we seek a
> > resolution of the best approach here over the time between now and a
> > release, but we do not block a release on this point.  (I am confident
> > however that those involved will have a good solution, and even the
> > current flat file is clearly good enough for our many users). 
> > 
> > I also propose that we do not make the major architectural changes
> > between now and the release to change file server or winbind
> > implementations for the AD DC.  Instead, we continue to build on the
> > massive efforts already made here over the next few months, but we will
> > not change the default behaviour for a 4.0 release.
> > 
> > This will give the vendors (Univention and Resara) and our numerous
> > users who are building on top of Samba 4.0 alpha releases a stable
> > release to move to, based on the current architecture, before we make
> > the change to a common file server for Samba 4.1.  
> 
> At least Univention uses 'smbd' and 'nmbd' (with cldap proxy mode, to
> get browsing support)
> by default.
> 
> I think we have to support such setups for a final 4.0 release.
> 
> Currently they need to use some hacks to rewrite idmap.ldb to avoid
> IDMAP_TYPE_BOTH, as the smbd file server can't handle them yet.
> 
> Like all the work to get to a common code base again, this is not
> a black or white thing. We can't just take one or the other
> components, we have to actively do some work to get all pieces together.
> This often means that we have to provide two solutions, until one can
> take over all features from the other.
> 
> I'm fine with using the source4/smb_server for simple AD domain controllers,
> which just expose NETLOGON and SYSVOL, for a 4.0 release and then
> change the default in 4.x.
> 
> But both alternatives have to work and use the same persistent storage
> for acls and other NT style stuff.
> 
> Currently one server uses 'user.DOSATTRIB' while the other one uses
> 'user.DosAttrib' to store dos attributes.
> 
> I recently fixed smbd to read all formats of security.NTACL.
> 
> We have to go through all this little details to make sure
> an admin can use one or the other file server, without
> destroying persistent information like ACL.
> 
> I hope to get some time to file bug reports for all things
> I know, which would block a release.
> 
> > This will mean we continue to ship smbd, nmbd, winbindd, samba etc as
> > found in the current alpha releases. 
> 
> For a release we also have to make sure that everything from source3
> is in a good state (I think they currently are, but we need to recheck
> before the release). In the same way as if it were a 3.7.0 release.

ack.

> > With this plan, and with the quality brought about by our continuous
> > integration approach, I think we can make a Samba 4.0 release in a
> > reasonable time-frame, perhaps with a final release in about three
> > months time.  
> 
> My hope was to have a least 20 alpha releases, then 3-5 beta releases
> followed by a few pre releases and then a few rc releases.
> This would be very similar to what we've done for 3.0.0 years ago.
> (I'd guess something like 6 month from now).
> 
> But all this depends on the blocker features/bugs, we'll define for the
> release
> and the time that's required to fix them.

Bug(zilla) driven release management sounds good.

> We also think we need to make 100% sure that an admin can't write invalid
> data via LDAP. We should treat our sam.ldb like a file system!
> And for production file systems everybody would expect that
> it's not possible to corrupt from any user space application!
> 
> I'll try to file some bugs for this.
> 
> > I do wish to be clear that I'm certainly not abandoning the idea of a
> > single file server, and I know many others on the team have also
> > invested great amounts of their own time in this effort.  It is
> > important not only for NAS vendors who wish to add AD to the NAS (an
> > idea I raise with every NAS vendor I get the chance to speak to), but
> > also our users who still regularly ask for a combined release with the
> > AD server, file server and print server all present in the same runtime
> > installation.
> 
> Yes, it's very important to get everything together again
> and goal for the long term future needs to be that we have just one
> component
> for each thing.
> 
> I hope to finish the smb1/2 client library work this week,
> which means we'll use the same low level library for all parts of
> master. This is the ground work to write a common the low level dcerpc
> layer.
> 
> During the work on SMB2.x features, I'll try to combine messaging layers
> of source3 and source4, so that all components can talk to each other.
> As we plan to use something like IRPC in the SMB2 server.
> 
> I think a common messaging layer would be really good for a final 4.0
> release.
> 
> BTW: we'll have to make sure, we list all thing we want to support
>      and also the things we'll not support!

Do we need a dedicated wiki page for this purpose?

Lars
-- 
Lars Müller [ˈlaː(r)z ˈmʏlɐ]
Samba Team
SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111130/8f65864d/attachment.pgp>