How to move storage OEMs to Samba 4.0 ?

[Michael Adam]

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.)
> >     - 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).
> 
> 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 am glad that we seem to move towards a consensus!

In the end it sometimes helps to have these long discussions. :-)

Cheers - Michael

-------------- 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/2f9f13f0/attachment.pgp>