You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having this separate requires coordinated knowledge of this existing when updating hypertrace/kafka, and that also implies testing this when the former changes. For example, if you don't, the image layers aren't coherent and the operations could also fail without knowing. In other words, they are quite coupled and coupled things deserve to be in the same repo.
On the other hand, this couples changes to the changes in hypertrace/kafka. However, this repo changes infrequently so far. For example, last non-trivial changes were roughly once in 2 weeks. While there could be some tension versioning hypertrace/kafka due to this, the overall coherence and less things to track seems a higher win. Worst case, as separate tag version could be applied to the helm chart this represents.
Meanwhile, if folding in, the org namespace is also more coherent, and the perceived complexity is limited along with the maintenance advantages.
Since there's a historical tendency to use git submodules, I'll mention explicitly the goal is to remove repositories, not add yet another one. In other words, this repo will be removed or archived/attic'd.
Please vote thumbsup if you agree, or no action if you don't care. If you thumbs down, you must be able to express in objective terms what must be surmounted to progress this topic. eg words like "priority" aren't objective.
The text was updated successfully, but these errors were encountered:
I agree this could be in the same repo as hypertrace/kafka to reduce duplication of code for setup, CI and tests. I also don't see any drawback on moving this to the hypertrace/kafka repo as they might be usually used together (unless I am missing something). Unless the main propuse of this repo is to provide a general way to create topics (which I believe we don't want), it should not be a separated repo.
While this is a separate helm feature vs management of the kafka broker, this is coupled to hypertrace/kafka directly.
For example, creating topics is a simple act, but one that could fail based on changes to https://github.com/hypertrace/kafka
Having this separate requires coordinated knowledge of this existing when updating hypertrace/kafka, and that also implies testing this when the former changes. For example, if you don't, the image layers aren't coherent and the operations could also fail without knowing. In other words, they are quite coupled and coupled things deserve to be in the same repo.
On the other hand, this couples changes to the changes in hypertrace/kafka. However, this repo changes infrequently so far. For example, last non-trivial changes were roughly once in 2 weeks. While there could be some tension versioning hypertrace/kafka due to this, the overall coherence and less things to track seems a higher win. Worst case, as separate tag version could be applied to the helm chart this represents.
Meanwhile, if folding in, the org namespace is also more coherent, and the perceived complexity is limited along with the maintenance advantages.
Since there's a historical tendency to use git submodules, I'll mention explicitly the goal is to remove repositories, not add yet another one. In other words, this repo will be removed or archived/attic'd.
Please vote thumbsup if you agree, or no action if you don't care. If you thumbs down, you must be able to express in objective terms what must be surmounted to progress this topic. eg words like "priority" aren't objective.
The text was updated successfully, but these errors were encountered: