Comments (8)
@osterman You bring up a great point on the maintainer
field on a chart. It's not about attribution. We should clarify the meaning and use of it somewhere. The maintainer
field is for the point of contact of the maintainers of this instance. If there is an issue, such as a security problem, those are the maintainers to contact. In the case of a fork with changes, it's the forks maintainers.
from hub.
@osterman prior to deleting it, you could mark it as deprecated. This would make it disappear from displays by default but still be discoverable.
from hub.
I created an issue on artifacthub/hub#542 for official versions of artifacts.
from hub.
So we've gone ahead and deprecated the chart and will subsequently remove it.
Also, not sure if part of the concern is related to the maintainer
field. We struggle with this because whilst we became the maintainer of this chart in our repo, we wanted to maintain attribution. We changed very little but wanted to credit the original maintainers so we left that there, even though we were the maintainers of this fork.
That said, to @mattfarina 's point, we don't see anything wrong with having alternate versions of the chart published; that is the open-source way. =) Blocking alternate charts would be very much against the ethos of open-source (and probably the law of open source licenses). More importantly, alternate chart versions provide field tests of alternatives to the "official" chart that the software maintainers can consider in their future plans without requiring them to make an immediate decision. Cloud Posse publishes several charts that we believe are "better" in some substantial way than the "official" charts or else we would not have bothered to create and publish them. Of course, "better" is subjective, and we do not try to persuade anyone to use our charts, but every chart we publish is one we have used successfully at some point in time, so obviously we see value in them as compared to the pre-existing charts.
While we always try to work with chart creators to have them update their charts, the process is often too slow when we are faced with an issue preventing us from using the existing chart right away on our customer engagements. In the case of the cert-manager
chart, we had a philosophical difference of opinion, preferring an approach that Jetstack officially rejected, so that certainly was not going to be "merged upstream".
That said, we fully support efforts to highlight the chart published by the maintainers of the underlying software. We're grateful for the hard work Jetstack puts into the cert-manager
project which we have relied on for years. Certainly, users should be made aware of who is responsible for the chart being published, and efforts made to prevent confusion over which chart has the support of the software developers. We also look forward to seeing improved means of attribution in chart manifests but oppose anything that would limit the openness of charts in the helm ecosystem.
from hub.
We had issues using the upstream chart and reached out several times to negotiate with the upstream maintainer about it. They closed those issues, which left us with requirements that the upstream chart did not support. Now that helm and this chart have matured, the default cert-manager have finally met our requirements and the fork has been removed.
Related to the topic of alternate versions. There are a number of situations where maintainers are not interested in supporting or allowing through configuration to support client use cases. In CertManager's case, we had a requirement that the chart include all dependencies in the chart. I believe this is actually outlined in the original helm charts repo, helm install {chart}
should work with default values. For cert-manager, this was not the case until fairly recently. We created a github repo that applied git patches to the Jetstack repo so helm install {chart}
works. Thanks to changes in the original repo, we noticed that dependencies are now included by default (yay). So we closed our fork.
We had to make this alternate chart to satisfy our use case. The ability to publish that alternative chart so others could take advantage of the work is fundamental to OSS. Ideally, you can negotiate with the original maintainers so forking is not necessary. It is not always possible to do so and maintaining an internal fork costs nearly as much as publishing an open source one, sometimes it costs a lot more to keep the repo private. It's advantageous to all users and future users that forks are available. If you ask most OSS project founders, they started by loving a tool. Yet, that tool had just one small thing that they didn't like, so they forked or made a similar project that does this one small thing.
I have been on the other side trying to sort out which chart is the 'best version'. Grafana and Grafana operator are good examples of this. It can be confusing to sort out which one to use, but I don't expect Helm Hub to answer that question for me. As long as the alternative chart provides a maintainer contact, then a user can reach out for detailed questions about the nature of this alternative chart.
from hub.
@munnerz thanks for bringing this up here.
The first thing I'd like to point out is that multiple charts for the same application are technically ok. For example, someone might provide a chart with a simple install while someone else might provide something far more configurable. Multiple charts from different people are ok.
I'm reminded that there are numerous debian packages for mysql or mariadb out there. Some are not very discoverable but they exist.
That being said, we have long had conversations on highlighting the "official" chart where possible. For the case where the project itself puts out a chart. This is not something we have implemented in the Helm Hub. Might I ask that you file an issue on Artifact Hub about this. I will follow-up on your issue there but that way you can track it. The long term plan for the Helm Hub is up in the air. Ideally, we would like the Artifact Hub to replace it. Either with the software or with the actual site.
The Artifact Hub has the ability for people to star charts. I think that's also a nice way to help indicate which to use. We are looking at other markers and if you have suggestions please file issues.
Quay is listed as being available in China so I would suspect your images are as well. There is a Helm Hub like site for China at https://developer.aliyun.com/hub/. This is done by Alibaba who tries to make sure the charts work in China.
There is no perfect solution to this problem. We can do much better, though. Suggestions are welcome.
from hub.
@munnerz thanks for raising the issue regarding our cert-manager
chart.
We should delete that chart from https://github.com/cloudposse/charts, but will preserve it in our chart repository for people still using it. It ended up not working well, for the reasons Jetstack warned about and that you raised, which is why we do not use it anymore.
from hub.
Now that Helm Hub has moved to Artifact Hub, and we have an issue for this there #402 (comment), let's close this one.
from hub.
Related Issues (20)
- Add CI to check for name length issues HOT 2
- READMEs getting 404 on Helm Hub HOT 6
- Cluster autoscaler version 1.15 and 1.16 stable charts are missing HOT 1
- Provide hub.helm.sh repository information for dependencies
- [CSS] Search results appear underneath upper fold HOT 2
- Redirection mechanism or warning message for deprecated charts HOT 1
- feat: expand hub support to helm plugins HOT 2
- feat: add example filters to homepage HOT 2
- Some pages of Charts in hub.helm.sh don't load their README content HOT 3
- Hub is not loading one of my charts HOT 2
- Charts in stable repo not available due to duplicate stable repo name in repos.yaml HOT 3
- Where is docker registry? HOT 6
- Longhorn Chart README page is loading indifinitely HOT 2
- Migration to Artifact Hub HOT 11
- Install panel "copy" doesn't work with Helm 3 and it picks "beta" chart. HOT 1
- Helm chart description links doesn't work HOT 2
- Helm Hub fails to load due to 503 errors HOT 2
- Redirection issue from hub.helm to artifacthub HOT 2
- Handover of external-secrets HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hub.