invidian
commented
2 years ago Sounds reasonable, thanks for reporting. I wonder what @flatcar/flatcar-maintainers think or how is this handled for other forked projects.
Open rhuss opened 2 years ago
invidian
commented
2 years ago Sounds reasonable, thanks for reporting. I wonder what @flatcar/flatcar-maintainers think or how is this handled for other forked projects.
pothos
commented
2 years ago We can add a link in the About info as replacement for the missing fork link, but yes, also in the README.
t-lo
commented
2 years ago Thank you @rhuss for pointing this out, it indeed seems to be a miss on our end. We absolutely love CoreOS and the team behind it; in fact, Flatcar started as a friendly fork back in the day to preserve the original look and feel, while our then-upstream moved on to Fedora CoreoOS. We maintain good relations to CoreOS folks and are generally not shy to point out our roots.
We'll come up with appropriate means to call out our history and will keep this issue updated with our progress. As @invidian rightfully called out there's more than just one former CoreOS project we're continuing, so we'll put some thought into our messaging.
I think it would be fair to at least mention the inheritance from https://github.com/coreos/container-linux-update-operator in the README.md , just to keep the historical context. I was just a bit puzzled while working on the second edition of k8spatterns.io, which references the original project as an example for a controller (without CRD).
Feel free to close that issue if this suggestion is too controversial (sorry, I have no insights at all into the relationship of the former CoreOS, Kinvolk, Flatcar projects, just thought that it would be fair to create a link to the former projects for the historical context (not talking about any potential license issues, ianal ...)