How to categorize this topic?
/area dev-productivity
/kind enhancement
/label teamsize/small
What is the topic about?:
Repository owners should focus on writing go code that gets shipped as production ready images. Any maintenance work that is not around go code is a burden. More precisely that kind of maintenance is based around make targets and hack scripts. This is documented in an issue, but the problem has been discussed long before that.
I currently have a POC, based on a subtree approach with the following story:
Extraction of dependencies into a separate subtree and generalizing usage - this will help with setup of new repositories in the future. The idea came from the effort it took for the pvc-autoscaler to be setup like a Gardener repo for ease-of-use by similarity to others. From what I've noticed, most extension repositories (for example) tend to have ~10 almost identical make targets. This highlights the significant amount of shared logic across repositories.
Re-vendoring Gardener versions that include changes to the hack helper scripts or make targets in gardener/gardener will no longer be as disruptive. Currently, some repositories maintain custom workarounds for certain problems - when a problem occurs, the resolution sometime follows an “every repository for itself” approach, because there isn't much exposure to the problem and fix. Fixes are applied locally, leading to duplicated maintainer effort and inconsistencies among repositories.
By separating the shared scripts and common make targets from gardener/gardener, we can centralize this logic and establish a single place for improvements and fixes. This allows the entire community to benefit from shared maintenance and contributions, instead of requiring each repository maintainer to independently patch the same issue.
Without such centralization and given that the developer sees the need to adapt the change everywhere, even small changes can result in a copy-paste effort across all repositories and potentially ~20 pull requests for a single fix, if the logic is shared.
Actual goal:
Since this is a bigger change that could be adopted by different types of repositories, it would be really helpful to adapt a few different repositories with the POC approach. This way, problems will get caught earlier and more feature requests can be adapted, based on newfound use cases. My current POC adaptations are gardener-extension-shoot-rsyslog-relp and pvc-autoscaler.
How to categorize this topic?
/area dev-productivity
/kind enhancement
/label teamsize/small
What is the topic about?:
Repository owners should focus on writing go code that gets shipped as production ready images. Any maintenance work that is not around go code is a burden. More precisely that kind of maintenance is based around make targets and hack scripts. This is documented in an issue, but the problem has been discussed long before that.
I currently have a POC, based on a subtree approach with the following story:
Extraction of dependencies into a separate subtree and generalizing usage - this will help with setup of new repositories in the future. The idea came from the effort it took for the
pvc-autoscalerto be setup like a Gardener repo for ease-of-use by similarity to others. From what I've noticed, most extension repositories (for example) tend to have ~10 almost identical make targets. This highlights the significant amount of shared logic across repositories.Re-vendoring Gardener versions that include changes to the hack helper scripts or make targets in
gardener/gardenerwill no longer be as disruptive. Currently, some repositories maintain custom workarounds for certain problems - when a problem occurs, the resolution sometime follows an “every repository for itself” approach, because there isn't much exposure to the problem and fix. Fixes are applied locally, leading to duplicated maintainer effort and inconsistencies among repositories.By separating the shared scripts and common make targets from
gardener/gardener, we can centralize this logic and establish a single place for improvements and fixes. This allows the entire community to benefit from shared maintenance and contributions, instead of requiring each repository maintainer to independently patch the same issue.Without such centralization and given that the developer sees the need to adapt the change everywhere, even small changes can result in a copy-paste effort across all repositories and potentially ~20 pull requests for a single fix, if the logic is shared.
Actual goal:
Since this is a bigger change that could be adopted by different types of repositories, it would be really helpful to adapt a few different repositories with the POC approach. This way, problems will get caught earlier and more feature requests can be adapted, based on newfound use cases. My current POC adaptations are
gardener-extension-shoot-rsyslog-relpandpvc-autoscaler.