Grafonnet-lib repository scope and how to manage third-party ones

[jbfavre]

Disclaimer I'm quite new to grafonnet and don't have the full discussion history about this topic. I'm happy to get more context or other points of view. This issues comes from the discussion around PR #210 was has finally been declined.

How am I ? I'm an SRE in a french IT company, trying to advocate grafonnet to dev teams. I've implemented grafonnet snippet for polystat panel and thought it could be included in grafonnet-lib repository since Polystat is developped and maintained by Grafana. Merge has been declined.

What problem I'm trying to solve ? I want to ease grafonnet adoption. This means, identifying and solving frictions which can slow down grafonnet adoption.

What is the problem ? Currently, the only official grafonnet repository is grafana/grafonnet-lib Choice has been made to restrict the scope to the core plugins, that is plugins which are enabled in Grafana after vanilla install (and not plugins developed and maintain by grafana).

First issue: this put out of the scope some plugins, developed and maintained by Grafana, but not included in default install. Example: polystat panel. Grafonnet owns and maintains it, but doesn't provide grafonnet for it.

Third parties plugins, and "non core" ones, are maintained by the community. They can only be listed in docs/community-plugins.md Development is made on a best-effort basis, often in dedicated personal repositories.

Second issue: To use them, one has to clone each needed repository, check whether plugins works or are up-to-date. For now, we have only 3 plugins listed. But this makes 3 repositories to watch for.

Having multiple third-party plugins repositories spread the maintenance effort on multiple people. At some point, one could want to handover his responsability. Current setup makes it hard to happen.

Third issue: Some mass-changes aren't currently easy to address because code is spread across multiple repositories. Having less but clearly identified repositories would ease those kind of changes to quickly happen.

Proposal

• All plugins developed or maintained by Grafana are eligible for main repository inclusion, whatever their "core" status. Grafana should do its best to maintain them and allow community contributions to keep them up-to-date.
• For third-party plugins, Grafana should setup a dedicated repository, either under Grafana organization or a separate organization clearly identified as being driven by Grafana. All third-party grafonnet plugins are eligible for inclusion in this repository, given they respect the prerequisites (code style, doc, tests, etc…) from Grafana. Some trusted contributors from community could have write access to this repository to allow reasonable review and merge time. This third-party plugin repository is mentionned in grafana/grafonnet-lib documentation so that users can easily find it.
• For both repositories, tests should be automated using continuous integration to ease reviews and merge operations.
• When planning breaking changes in Grafana (schema changes, panel property changes, etc), Grafana should open issues in each repositories for relevant plugins so that community has time to address changes before Grafana release.

[roidelapluie]

What about we, as community, create a "grafonnet-community" repo which can welcome those non-core plugins?

[jbfavre]

I'm fine with this solution as well. But I really think Grafana should step in and back this repository

[roidelapluie]

Well in my personal opinion, we should accept grafana-developed plugins here. I haven't seen that discussion in public.

[malcolmholmes]

@roidelapluie I agree the boundary of 'core Grafana features' is relatively arbitrary. It could equally be 'all Grafana developed plugins'. The thing is, the Grafana developers working on Grafonnet are not the same as those working on Grafana plugins, meaning we don't know much about specific Grafana plugins, so aren't in a position to judge the correctness of a Grafonnet extension.

@jbfavre what do you mean when you say 'Grafana should step in and back this repository'? What have you got in mind?

[trotttrotttrott]

I like the Grafonnet scope/eligibility adjustment idea. We could say, Grafonnet supports all plugins listed here: https://grafana.com/orgs/grafana/plugins. As opposed to "core features and plugins".

I also like the idea of a "grafonnet-community" org. This reminds me of how Terraform providers are managed: https://github.com/terraform-providers.

[jbfavre]

@malcolmholmes I think Grafana devs are in better position to judge the correctness of a Grafonnet extension than community members :-) That one of the reason I'd like the "community" repository, let's call it that way, endorse and supported by Grafana. It's not a matter of dedicating developers' bandwith to it, though it could be helpful, more a matter of supporting it "publicly" and maybe providing some insights about changes to come so that the community have more time to update existing plugins.

I understand I'm not the best to judge that point, mainly because I'm not precisely involved in Grafana community. So, maybe what I'm dreaming of already exists. Having separate teams working on grafonnet on one hand and grafana plugins on the other hand isn't an issue to me. But, having no or poor communication between them is. I'm confident this communication exists inside Grafana. I'm just looking to a way to extend this communication to grafonnet community members to keep existing plugins up-to-date and provide new ones in the most efficient way and timeline.

[jbfavre]

@trotttrotttrott I like your parallel with Terraform-providers which fulfill almost completely my second point: terraform-provider org is clearly identified to be ruled by HashiCorp (mail, website URL) and because it's an organisation, it get more visibility than a repository among others inside HashiCorp org. Might be easier for contributors to setp in.