> Once there is, we are free to change the default output however we want. One thing I always try to keep in mind on discussions like this. A thought experiment (with very hand-wavy numbers; try not to get hung up on them):
* Let's say there are 5,000 discrete "users" of C* out there (different groups of people using the DB) * And assume 5% have written some kind of scripting / automation to parse our tooling output (250) * And let's assume it'd take 18 developer hours (a few days at 6 hours/day) to retool to the new output, validate and test correctness, and then roll it out to qa, test, validate, and then to prod, test, validate You're looking at 250 * 18 hours, 4,500 hours, 112.5 40 hour work weeks (2+ years for some poor sod without vacations) worth of work from what seems to be a simple change. Now, that estimate could be off by an order of magnitude either way, but the motion of the exercise is valuable, I think. There's a real magnified downstream cost to our community when we make changes to APIs and we need to weigh that against the cost to the project in terms of maintaining those interfaces. The above mental exercise *really strongly* applies to the periodic discussions where we talk about deprecating JMX support. Not saying we should or shouldn't change things here for the record, just want to call this out for anyone that might not have been thinking about things this way. On Fri, Jul 7, 2023, at 3:23 PM, Brandon Williams wrote: > On Fri, Jul 7, 2023 at 2:20 PM Miklosovic, Stefan > <stefan.mikloso...@netapp.com> wrote: > > > > Great thanks. That might work. > > > > So we do not change the default output unless there is json / yaml > > equivalent. > > > > Once there is, we are free to change the default output however we want. > > Yes, exactly. Then we have the best of both worlds: programmatic > access that isn't flimsy, and a pretty display however we want it. >
