How to move storage OEMs to Samba 4.0 ?

[Jeremy Allison]

On Tue, Jun 12, 2012 at 08:21:06AM +0200, Michael Adam wrote:
> OK, my mail was way too long.
> 
> Let me recap the most important questions/points:
> 
> * What is so new in the 4.0 release step file-server-wise
>   that OEMs will refrain from upgrading even longer than
>   they did/do for other releases?

Large, realtively untested changes in many core components.
Don't get me wrong, I think we're doing the best we can
and our testing is getting better. But there are large
changes here. More change == more new bugs. It really is that
simple.

>   Is 4.0 fileserver-wise really worse / more scary / bigger than
>   earlier releases from the point of view of OEMs?

Yes.

> * The major changes listed to support the dangerousness of 4.0 were
>   changes not authored by you (or Volker, or me..). So might it
>   be that this fact rather creates an increased fear (of the unknown
>   or uncontrolled) on your side?

Nope. I'm happy with  the changes, and I reviewed many of
them. But I'm not perfect.

> * In short, is it really the OEMs' fears your are expressing or
>   rather your own fear projected to the OEMs?

No, it's OEMs.

> Of course I want to help the OEMs (I already do).
> But I am not convinced that that opening up 3.6 for feature
> backports is the right thing.

I'm here to convince you otherwise :-).

> * It would be the wrong sign (to not move to 4.0).
> 
> * Opening up patch policy for the release increases the risk
>   of destabilization, even if (of course) not intended.
> 
> * I would agree to allow backports of isloated new code like vfs
>   modules or command line tools where risk is minimal.
> 
> * What do the OEMs themselves want from us?
>   Do they want a blended OEM-feature release?

They want all new features in no new release of course :-).
Which is impossible :-).

> * We could offer a loose collection of backported feature patches
>   not harnessed into a release, so every interested OEM can pick
>   from that collection.

I don't like that idea. The "loose collection of backported feature patches"
is what everyone has on their own right now. It negates the
advantage of being a "release".

> I would really like to discuss this further since I also want to
> reach the best possible way to help OEMs with current releases
> while encouraging them to move to 4.0.

So again, as everyone seemed to ignore it. I really like Ira's
suggestion.

Anyone can submit a "new feature" patch for 3.6.next, under
the following conditions.

3 engineers must review and buy-off on the changes, not
two. At least 2 of the engineers must be from different
organizations (i.e. No all-Sernet, all-Google, or all-IBM
patches).

Does that help ? I think it strikes the right balance
of opening up the tree a little bit, without having
a new "3.6.next is open for everything" policy.

Jeremy.