Isn't that an overreaction? This will just cause pain to users who installed it from our repos. Presumably the telemetry was there for some time, so why not give them grace period (say, one month?) to resolve it in a way that works for everyone? Us, them, users.
-
-
Replying to @fuzzycz @magnushagander
Well, the package should not have gone to repo at all. Removing does break anything. I am also in touch with TimescaleDB folks to solve this issue. Spec file, etc. are still there. It takes a short time to re-add it back to the repo.
1 reply 0 retweets 0 likes -
Replying to @DevrimGunduz @magnushagander
So, what happens if they fix (for example) a security vulnerability? How do the users get it? I know it's a hypothetical question. BTW which rule does telemetry break? I honestly don't know.
1 reply 0 retweets 0 likes -
Replying to @fuzzycz @magnushagander
Wait for my next tweet about your first question. Regarding other one, people already said that this is a "spirit of rules".
2 replies 0 retweets 0 likes -
Replying to @DevrimGunduz @magnushagander
FWIW I'm not arguing in favor of telemetry, I think it should be off by default in all packages in our repos. But if we decided to introduce a new rule or clarify existing ones, it seems too harsh to remove the packages immediately. That's why I argued in favor of a grace period.
3 replies 0 retweets 3 likes -
This isn't actually a new rule, or any kind of clarification of an existing rule, this was a discovery that was made and was unexpected from upstream. For as much as Devrim is able to do, reviewing every version of every package that goes up on pgdg isn't possible.
1 reply 0 retweets 1 like -
I don't think anyone expects Devrim to review code for any/all packages. It seems more like we didn't expect people to add/enable telemetry, timescale assumed it's not an issue, and here we are. If we now say "no it's not allowed" how is that not a new rule or a clarification?
2 replies 0 retweets 2 likes -
We expect OSS upstreams to not have default-on telemetry, that's not a new thing. Simply because some folks assumed it was fine doesn't actually make it so.
1 reply 0 retweets 0 likes -
Sure, but it's really hard to meet assumptions you're not aware of. Say, if you're outside the community and the assumption is not codified anywhere.
1 reply 0 retweets 0 likes -
I actually just simply don't agree with this. I don't think there's really any question about if this kind of thing is acceptable in an OSS upstream which is packaged in a project repo, even from an open-core company. The "they didn't know better" argument doesn't fly with me.
1 reply 0 retweets 3 likes
Unacceptable doesn't imply "no grace period" though?
-
-
Replying to @AndresFreundTec @net_snow and
Devrim Gündüz Retweeted Devrim Gündüz
Devrim Gündüz added,
Devrim Gündüz @DevrimGunduz
Per online and offline discussion, I will put these packages back, because we are expecting an update from TimescaleDB shortly that will fix this. This is a "grace period", as suggested during discussions. https://twitter.com/DevrimGunduz/status/1135502597375365120 …Show this thread1 reply 0 retweets 1 like -
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.