How to move storage OEMs to Samba 4.0 ?

[Michael Adam]

Kai Blin wrote:
> On 2012-06-18 19:49, Jeremy Allison wrote:
> > On Mon, Jun 18, 2012 at 05:55:47PM +0200, Andreas Schneider wrote:
> >>
> >> I don't see the difference between building 4.0 with
> >>
> >>     ./configure --without-ad-dc --with-system-mitkrb5
> >>
> >> and creating a 3.7 branch and building it with source3/configure. With
> >> the latest changes this is essentially the the same. Maybe Jeremy needs
> >> some private lessons with the 4.0 build system :)
> > 
> > The whole point is that it really isn't the same (code-wise).
> > 
> > If you don't understand that you don't understand the requirements
> > here.
> 
> Ok, I guess I don't understand the requirements.
> 
> Some mails ago you said you were going to convince us that piling a
> bunch of possibly unrelated patches potentially interesting to different
> OEMs in a stable branch would make OEMs happy. Unless I missed the email
> where you did that convincing, all I saw so far was  a "proof by claim"
> approach.
> 
> To bring up the points against opening up the 3.6 branch for new
> features again:
> 
> - We promised that stable branches are bug fix only to our users. By
> adding in new features, we break that promise.
> 
> - We're having a hard enough time getting bug fix releases for 3.6 out
> of the door, new features add even more of a strain on our developer
> resources.
> 
> - It sends the wrong message to our users, giving the impression that
> smbd from 4.0 isn't working as it should.
> 
> - We're breaking the business model of many companies that employ Samba
> developers to take care of their custom development needs.
> 
> - OEMs like stable releases, new features potentially destabilize things.
> 
> The pro side seems to be:
> 
> - OEMs like new features, if they're safe and make Samba work faster/better.
> 
> - 4.0 is scary because of the number, because it's new, and perhaps
> because of the magnitude of code that changed. (There's still a lot of
> arguing over the last part of the statement)

One point here might be that while purely file-server-wise, 4.0 will not
be an especially huge release (maybe except for the smb2&3 stuff
that is currently landing in master, which might turn out big),
and while it should and will be possibe to use 4.0 purely as the
smbd/winbindd/nmbd suite, the perception probably is, that 4.0
comes inseparably with that whole bunch of new components that
comprise the AD server. This might explain a greater fear of 4.0
from the fileserver users. That being said, I personally have only
heard that increased fear predicted from samba folks, not from
OEMs / users themselves. I think it is a matter of communication
and PR to clearly point out samba 4.0's fileserver-only mode.

The typical OEM and distributor uses an official release and
maintains a list of patches with backported fixes or features
on top of that. This list is usually different for each OEM
or distributor. There are probably patches that would be
considered part of a common denominator.

One corner case is that there are OEMs out there that don't
have their own list of patches at all but only permit to use
vanilla upstream releases. One could argue that these
have solved the dilemma of stability vs. features quite
consequently for themselves.

We can't provide with 3.6.X the release to use as is for all
of our OEMs and distributors, since some of them may have
patches that are not made for the public and they need to
keep their list of patches however hard we try. All we might
reach is to diminish the list of patches that each or most
of the OEMs needs to maintain. And remove some pain from the
OEMs that are not allowed to maintain patches of their own.


What I really don't get is why we need to talk about changing
our current rule for that:

We already have a fuzziness in our rule:

The rule we have sounds simple: Only bugfixes via bugzilla with
review (of >= 2 samba team members).

But what is a "bug" and a "bugfix"? A bug can well be the lack
of a feature. And to fix a bug that does not even sound like
a new feature request, it might be necessary to do changes to
the code that are not acceptable for a bugfix release, e.g.
api or abi incompatible changes to some subsystems/libraries,
rewrites of large chunks of interna code, etc.

So I think the rule we have is already sufficiently open
and subject to judgement and trust to some extent. It is just
not very precise!


So rather than seeking to loosen the current fuzzy rule by adding
another fuzzy rule, I think we should rather add precision to our
existing rule. We should elaborate kinds of changes that are allowed
in principle or are not allowed to go into a bugfix release.

Examples (as a starting list to try and define our policy of what
can go into a bugfix release):

(1) we could allow:

    - adding new commands
    - adding new subcommands to existing commands
    - adding new vfs modules
    - changes to the VFS that are not ABI but API compatible,
      i.e. the users need to (and can!) recompile their vfs
      modules against the new code. If the change is not ABI
      compatible, we should change the VFS version.
      (This will be subject to discussion.)
    - addition of new configuration parameters in order
      to allow to change the server behaviour.
    ...

(2) we should not allow:

    - changes to the VFS that are not API compatible, i.e.
      user's can not recompile their vfs module without
      code changes
    - patches that change the default behaviour.
      (use new options instead to add a new non-default behaviour)
    - large architectural changes
      (this is of course very fuzzy again...)
    ...

(3) guarantees we could/should give:

    - existing commands stay
    - default behaviour remains unchanged
      (unless this itself is a bug, in which case it could be reviewed)
    - API compatibility for the VFS interface
    ...

This could elaborate into some kind of guideline, but of course
each bug(fix) is subject to judgement and review individually.

I think also that with this, at least a subset of what Jeremy
might have in mind for backporting would not be banned from
3.6 bufix releases (given careful review as always).

Cheers - Michael


> There's contention if we can guarantee the "if they're safe" part, and
> if the "4.0 is scary"-feeling is justification enough to break our
> "patches only for stable release branches" policy.
> 
> Did I miss anything? Especially anything that backs up the claims from
> the "pro" side that are more than just "because I said so"?
> 
> 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: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120619/6c0da07c/attachment.pgp>