How to move storage OEMs to Samba 4.0 ?

[Kai Blin]

On 2012-06-06 01:16, Jeremy Allison wrote:

Hi Jeremy,

> So, realistically, most Samba storage vendors are going
> to stick with 3.6.x for the next year or so. The question
> is, how to provide them with functional updates on that
> code until they feel comfortable enough to go with the
> version of 4.0.x that is current ?
> 
> I'm not talking about regular bugfixes here, but bugs like:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=8926
> 
> "Please use vfs_shadow_copy2 from master".
> 
> Currently this is closed out, due to it being a functionality
> addition. I think we need to find a way to handle this
> without expecting all storage vendors to move immediately
> to the 4.0.x fileserver.

Similar to what Andrew already mentioned, my question would be what the
benefit would be. The 4.0 smbd binary is the continuous improvement on
top of the 3.6 smbd. It's not a radically new thing. It also sees a lot
of testing in autobuild. A random combination of backported patches
would not. Sure, you might have some user who tested every patch is fine
on their setup in isolation, but that doesn't mean we can be sure the
patches don't break in new exiting ways when combined.

If we want to guarantee stability of the released version, we can't
reasonably go and add new features. That's why we made this "bug fix
patches only" decision in the first place.

> [...]

> However this leaves a grey area of functionality additions
> that are really useful (e.g. the aio_pthread code which
> I snuck into 3.6.x) but not large rewrites. So I can see two
> options here (there are more, but these are the ones I think
> are workable) :
> 
> 1). Once 4.0.x ships, relax the rules on functionality
> additions to 3.6.x so that we can add *some* limited new
> functionality like bugid 8926, or the pthread aio code,
> or the new VFS module someone wants to submit. *Maybe*
> VFS changes (not sure about that..).
> 
> We will of course commit to doing this only for a year or
> so. Requirements for new SMB3.0 functionality will attract
> OEMs to 4.0 eventually. This is *close* to what we're
> doing now, but it losens up the restrictions we currently
> have on adding new code.
> 
> 2). Once 4.0.x ships, fork off a 3.7.0 tree from the current
> 3.6.x tree and add the limited new functionality there. As
> this is post 4.0.x ship then we still recommend 4.0.x for
> all users, but we have the ability to add *limited* new
> functionality to a "trusted" release that is very close to
> what storage OEMs currently depend on.

You're clearly missing
3) Keep our existing policy of not adding new features to "stable"
release branches. We can pledge to support 3.6 for a longer run than
just until 4.2 is released, for people who really need the stability. We
can also have patches for popular new features, if people have the spare
time to create those. But this clearly points out where the testing of
these patches needs to happen: in-house where people chose to apply the
patches.

Which is what I'd prefer. We don't even seem to have the development
resources to get the next 3.6 bugfix release out in a timely manner. I
think having to not only bug fixes but also new features will make
further 3.6 releases take even longer and divert development effort from
the 4.x series.

Again, I don't see the huge difference between the 4.0 smbd and the 3.6
smbd, at least not when compared to 3.5 vs. 3.6, or whenever we added
SMB2 support. I don't understand why a 4.0 smbd from the same codebase
would be magically less reliable just because the version number starts
with 4.

Cheers,
Kai

-- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120606/e76dda92/attachment.pgp>