Flow for promoting code in a given charm library to the core codebase

[pengale]

This is a long term planning issue. I'm jotting down my thoughts here, and planning to talk about it in the planning sprint next week.

I suspect that we are going to run into a pattern with a lot of requests for enhancement filed here. The pattern goes like this:

1. We agree that the enhancement would be useful.
2. We believe that the enhancement would be best expressed as a charm library.

Ideally, someone then writes the library, and the library gets used. That's fantastic. But we need to have a sensible flow for a final step:

3. The library becomes widely used and battle tested, and we move it into the core framework.

I think what I'm saying is that we need a "popularity contest" style feature for CharmHub, so that we can monitor frequently used libraries, and make smart decisions about which we might want to fold into the core.

There's also another piece missing from this flow: when we agree that a feature would be useful, and that a library should be written, what happens to the GitHub issue? Do we close it, and rely on the person who filed the issue to track the need and the implementation? Do we add a "library" tag and keep the issue open? Do we move the issue to a "library nursery" repository? What do folks think would be most friendly, and most useful?

[pengale]

For now, I've added a "library" tag, for issues that have resulted, or should result, in a library. Feel free to use it liberally, as I'm sure that we'll want to follow up on each of those issues as work to address this issue progresses.

[benhoyt]

This is an interesting idea, but I don't think there's enough of this happening for anything formal or automated. We're pretty careful and curated about what we include in / move to ops itself. See also my thoughts on how we evaluate what to include in ops.