To recap what the goal was when we started the conversation, we were thinking of a way to move the 3.5 branch from alpha to stable faster. One suggested option was to make it possible to disable reconfiguration due to the security concerns, which is one key reason for having the 3.5 branch in alpha. We need to ask ourselves whether having a switch in any form would help us achieve our goal. If not, then having it is a moot point.
Assuming we have something to gain from such a switch, it does feel like a better option to separate concerns and not couple enabling reconfig to acls. -Flavio > On 01 Apr 2016, at 20:07, Shawn Heisey <[email protected]> wrote: > > On 4/1/2016 12:32 PM, Alexander Shraer wrote: >> I think we have some flexibility here since reconfig is a new feature so we >> could >> choose to be concervative and release it first only to people that do use >> ACLs, but >> I don't feel strongly about it, either way. > > I have no standing in this project, but if I did, I'd fight that > proposal. I might lose, but that wouldn't stop me from trying. ACLs > are a nice option, but I think they need to *remain* an option. > > If I'm using feature Y, and feature X is not intimately related in a way > that cannot be separated, X should *not* be required to use Y, or > vice-versa. I can't think of any good reason to require ACL enforcement > before allowing dynamic ensemble membership. > > Is there some aspect of this that I'm missing? That could be the case. > I'm not deeply familiar with ZK, and even less with 3.5. > > Thanks, > Shawn >
