ocket8888 commented on issue #7456: URL: https://github.com/apache/trafficcontrol/issues/7456#issuecomment-1931196660
> We provide only features. We don't get to decide how users use those features. In [your words](https://github.com/golang/go/issues/44550#issuecomment-978217250): > > > These are project-level decisions. Sometimes adding new features, addressing newly discovered concerns, or meeting new constraints _absolutely_ **requires** _breaking changes_. It's great for the Go project itself that the decision was made to never make breaking changes at the source level, but this is not the reality of the entire world of software development. In my honest opinion, a language so restrictive that beyond a certain point in working with it on a project no further changes of a certain nature can be made _**is fundamentally broken**_. I'm not sure what you're saying. This is a new feature is it not? I'm not objecting on the grounds that it's a breaking change; that would be silly. I've authored many a breaking change. > You have already voiced your opinion about how you think things things shoul be organized in your Global Configuration blueprint (https://github.com/apache/trafficcontrol/pull/7015), and blocking other people's incremental PRs because you think a different high-effort idea is better hurts the project. That's not at all what's happening here. I'm against this idea because I think it would have a negative impact on its own terms. Not because I have some superior idea. If I'd never given Global Configuration a moment's thought, I would still think that comments in Parameters would be a bad idea - which is also kind of a moot point, because I'm not actually sure how those two ideas are related. Global Configuration would remove some dedicated Parameters, they would do nothing to the notion of Parameters overall. Just isn't really related. > The author of https://github.com/apache/trafficcontrol/pull/7845 clearly wants this feature, as do several other ATC users who I have talked to. It sounds like you're against implementing https://github.com/apache/trafficcontrol/issues/7456 because of the edge case of a user potentially trying to derive structure out of the comments, but that's not a good enough to block accepting implementation itself. I had guessed that the author of that PR opened it only because this issue exists. They've said nothing to indicate any personal attachment to the idea. I also can't speak to the desires of others you've talked to, because they haven't taken part in the discussion. Which is what this is, ultimately. I'd be more than happy to take this to the mailing list. But this is kind of totally standard procedure. Somebody proposed a change, I have concerns that it would ultimately be a net negative impact, and I voiced them. Then nobody else addressed - or even acknowledged - those concerns. So to somehow accuse me of standing in the way of something everyone wants is pretty strange to me. Requiring consensus on changes to the project isn't my dastardly plan to impede some specific PR, it's a founding principle of the ASF and older by far than this project. I'm just taking part, is all. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
