--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/391e0852-f0ec-4c1a-ad97-86ab1f9db28a%40googlegroups.com.
I don't buy the "slippery slope"
line of argument to justify a blanket ban of any of those
changes. Such strict rules are easy to follow but don't gain us much
while they can be very destructive for the ecosystem as a whole.
> This is not theoretical, we've already had such things get into the TSDB codebase with no non-obvious-semantics, no unitests, that are in the way of development, but it'd be a bit impolite to just remove it.That is unfortunate tbh. Could you list the feature? If it doesn't have enough tests and is actually hindering dev, I am all for improving or removing it. And please call them out as you see them.
> a) we're only going to break it later, as we don't use it and it's in the way of some new feature/optimizationIf it really hinders a new optimisation/feature, I'm all for breaking it. I'd rather break Cortex/Thanos than stand in the way of your sweet optimisations :) If it's an inconvenience for optimisations, I can guarantee that the Thanos/Cortex maintainers can step in remove those inconveniences. You could always remove it, do the optimisation and suggest a way to implement the feature along side the new optimisation, and I am sure the maintainers would be glad to do the extra work of reimplementing it. I know the removal might be considered extra work, but I think its a justified price to pay in the light of the community benefit.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLph2CJUDMkjk3yBimtu%2BiBYFhQwKxALH83B1%3D7NpvNp9A%40mail.gmail.com.
Krasi Georgiev Senior Software EngineerMonitoring Team |
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZ_zruj4jp9TwsSMbSo18XE6SFiPjRXibHJVZ7FwdZHQw%40mail.gmail.com.
We effectively had two discussions in one here:
First, about the concrete request for the limit feature. And second,
if we should or should not have a strict rule to accept features that
are needed by 3rd parties but not directly by Prometheus itself.
I got from the discussion that we already had precedents, some worked
out well, some didn't. The latter can inform us how to set the bar so
that future features will not bite us in the same way.
The draft criteria I listed (none of which will be black/white in
practice but they will be scales along which we can judge a proposal)
are perhaps a good first step.
But first we need to assess consensus that we will not strictly rule
out features that are needed by 3rd parties but not directly by
Prometheus itself. Many seem to agree, but Brian's mail could be read
that he doesn't.