Can we modify the document to make this really explicit then? Right now, the
language suggests the process is mandated, rather than encouraged and
beneficial.
It would be nice to frame it as a positive and incentivised undertaking by
authors, and to list the intended advantages, as well as the
1.During ApacheCon, Laxmikant approached me to discuss CASSANDRA-14227. It
was also raised on the list back in January.
Taking a closer look, it probably is not very difficult for us to fix this –
either by treating the int as unsigned, or by widening it to a long value.
Since this can
We will have to deal with fixing this TTL issue eventually as more users
start to deal with the boundaries of currently allowed TTL (which keeps
declining). It will be neat if we can get this into 4.0 before it is
released - be it in beta or future 4.0 alpha(s) - the sooner the better, as
everyone
I personally think we should move this forward for the reasons mentioned
beforehand. Widening to a long value seems to be the most pragmatic
approach if we want to get this in for 4.0. Alternatively, we can let
operators choose the precision int vs long in case TTLs are not used.
I'd be happy to a
Another thing which it should solve is someone proposing an alternate very
late into development which could be provided sooner. If someone has a good
feedback which could not have been given at the time of CEP then that is
good. We don't want situations where contributors have done the CEP and
the
We have to be very careful here in my opinion. While the process may provide
some moral authority, particularly on matters of taste or opinion, we cannot
mandate participation, else accept the decisions that arise. People are
legitimately busy, and have to steal their spare time to participate
All too often, a work-invalidating insight hits late in a cycle while
people are talking about something and significant work has been done on
the invalidated proposal. A CEP up front with engagement from a bunch of
parties may very well help surface those design implications sooner, but we
also ha
