To release Samba 4.0 'as is'

[Matthieu Patou]

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).
Agreed.
>
> 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 
vice versa
     * 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
> installation.
>
> What do others think?

I made the bug 8622 to follow all our blocking bugs for a 4.0 release: 
https://bugzilla.samba.org/show_bug.cgi?id=8622.

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.

Matthieu

-- 
Matthieu Patou
Samba Team
http://samba.org