How to move storage OEMs to Samba 4.0 ?

Jeremy Allison jra at samba.org
Tue Jun 19 10:31:01 MDT 2012


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 :-).

Cheers,

	Jeremy.


More information about the samba-technical mailing list