> But it seems to me that we should support enabled=false without removing all
> the other parameters so that users can disable the compression for testing or
> problem resolution without losing an of the other parameter settings.
Yes, I agree with this. Mere "enabled: false" should be just enou
Hello Claude,
I have seen two options and the option you mentioned is probably the
third from ways of disabling a feature :-)
So, we have
1.
public class TransparentDataEncryptionOptions
{
public boolean enabled = false;
public ParameterizedClass key_provider;
}
2.
public boolean cdc_en
Let me try to break this down another way:
I see a few competing concerns, each with QA related time requirements
(asserting 8 weeks minimum, 16 weeks maximum we should plan for to stabilize a
GA):
1. A freeze to a branch to stabilize for release (8-16 weeks of QA required
after we branch)
2.
Currently the compression parameters has an option called enable. When
enable=false all the other options have to be removed. But it seems to me
that we should support enabled=false without removing all the other
parameters so that users can disable the compression for testing or problem
resoluti
I'm going to repeat the point from my own thread: rather than thinking of
this as some kind of concession to two exceptional CEPs, could we rather
take the point of view that they get their own space and time precisely
because they are large and invasive and both the merge and testing of them
will
