How to move storage OEMs to Samba 4.0 ?

[simo]

On Tue, 2012-06-19 at 09:31 -0700, Jeremy Allison wrote: 
> On Tue, Jun 19, 2012 at 12:59:26PM +0200, Michael Adam wrote:
> > 
> > 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.)

This should not happen in a z release IMHO.

> >     - 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

I would say also that the actual vfs ABI should not change, that doesn't
mean the rest of samba internal are untouchable, but why penalize people
that use exclusively the VFS interface as published ?

> >     - 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).
> 
> No, actually this *completely* captures what I had
> in mind, and is a very articulate description of
> what I'd like to be able to do for future 3.6.x
> releases.
> 
> Thanks a lot Michael, really great post !
> 
> +1 on this as a clarification of our policy, it
> really does cover the cases I'd like to support.
> 
> If we can agree on this, I'm done with this
> discussion :-).

I generally agree with all, although I would prefer if we made an effort
not to change the VFS ABI in a minor release. I am not to ask to be
strict about that, the vfs is large enough that we may not hold to the
promise, but I would like to avoid seeing deliberate ABI change without
a good reason .. "because we can"

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>