To release Samba 4.0 'as is'
mat at samba.org
Tue Nov 22 11:53:06 MST 2011
On 22/11/2011 07:13, Andrew Bartlett wrote:
> 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.
Agreed but see below
> 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.
I don't share this point of view for a couple of reasons:
1) we talked a lot about a 4.0 release with the same fileserver (almost)
as in 3.6 branch, by not doing so we do not honor our promises
2) we will have a different fileserver code if someone use it as a
standalone or as domain controller, as the standalone will have the
usual 3.X code and the DC will have the source4 smb server code, it means:
* we will have to fix bugs in the source4 smb part for something
that is not seen as our top priority, and this will last for a long
period and on part of the code that we might throw away after
* smb/smb2 support on the DC will not be the same as on the
fileserver, it will be quite puzzeling for the users
* bugs impacting the DC won't impact the standalone file server and
* bugs fixed in the standalone fileserver won't be fixed in the
DC's fileserver and vice versa
3) people expect the pam module to work as expected
> This will mean we continue to ship smbd, nmbd, winbindd, samba etc as
> found in the current alpha releases.
> 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.
> 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
> What do others think?
I made the bug 8622 to follow all our blocking bugs for a 4.0 release:
I think that the missing part must be added as blocking bugs and then we
will have to fix it.
I might mean that people working on Samba4 should start to focus firstly
on this bug and then only on new feature if we want to release something
in a timely manner.
More information about the samba-technical