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