Official addons

[gbenhaim]

1. Document the reasons why Konflux chose to support the Add-on approach.
2. Create a separation between official/unofficial addons.

If this change will be accepted I will update https://github.com/konflux-ci/community/blob/main/ADRs.md as well.

Assisted-By: Cursor

[ralphbean]

This is great. Thank you!

[ralphbean]

Were you prompted to clarify this after seeing #282 in the review queue?

[ifireball]

Nice! +1

[dirgim]

+1

[gbenhaim]

Were you prompted to clarify this after seeing #282 in the review queue?

Actually now. I saw it after I've opened this pr. I'm glad that #282 was opened and I suggest to repeat the process for all add-ons.

[arewm]

Is there any guidance for what should be documented in this architecture repository? Which should be enabled for configuration in konfux-ci/konflux-ci?

[arewm]

After thinking about this more and discussing with the @konflux-ci/kgc , I am removing my approval.

I am not necessarily opposed to this as a representation of what we currently have, but I feel like it is not a sufficient qualification of what addons mean. What is the value/benefit that we have by hosting an add-on in the org? We have some add-ons which are certainly being baked in (like KubeArchive in the UI) which will not be within the org as it is a separate project.

Additionally, all content that is within the org does not have the same level of support.

If we want to claim this type of addon structure, I feel like it should go through ADR first so that we can be clear about what we mean. Feel free to bring this up on the community call noting that 2/3 of the KGC will not be in the call on November 27th.

[gbenhaim]

After thinking about this more and discussing with the @konflux-ci/kgc , I am removing my approval.

I am not necessarily opposed to this as a representation of what we currently have, but I feel like it is not a sufficient qualification of what addons mean. What is the value/benefit that we have by hosting an add-on in the org?

I've described what is the value it brings as part of the change to the documentation this pr makes. Do you think that anything is missing?

We have some add-ons which are certainly being baked in (like KubeArchive in the UI) which will not be within the org as it is a separate project.

This is perfectly fine like I described in this pr. Those addons are not under the governence and guidelines of our community. For example they can decide they change their api and we don't have anything to do with it. We can't provide any guarantees to our users when it comes to those addons.

Additionally, all content that is within the org does not have the same level of support.

Do you have any examples?

If we want to claim this type of addon structure, I feel like it should go through ADR first so that we can be clear about what we mean. Feel free to bring this up on the community call noting that 2/3 of the KGC will not be in the call on November 27th.

What would be the benefit of opening an adr that will contain the same information that this pr adds? If any clarifications needed I can provide them on this pr, and by that avoid repeating the process twice (adr and then changing the architecture docs).