Pulp3 has a plugin for Chef at https://github.com/pulp/pulp_cookbook/ . Its only activity in the last 18 months has been an effort to get it to build with our current CI. The main Pulp team doesn’t have any Chef expertise, and isn’t in a position to do much with this plugin. And the Pulp analytics site shows zero current use.
Given all of the above, we’re considering archiving this plugin. It’s better to clearly mark a thing as “unsupported”, than to implicitly let it wither.
Anyone have a strong opinion on this? Let us know here?
Just one thought. There are no uses of it in analytics, because it never had an official release. But even the reported uses for 0.1.dev basically dried out since June.
So are we archiving for adoption by some other team?
I’m proposing we archive it because “we” (the main Pulp team) don’t have the bandwidth (and honestly, don’t have the expertise) to maintain it. If someone wants to pick it up, that would be wonderful!
Put another way, any contributors want to step up and maintain this plugin? If you are using it or thinking of using it, this would be a good time to step up!
An archived repo cannot accept new PRs nor issues [0].
I’d vote to not archive it but rather update README.md that would clearly state this repo is in unmaintained mode.
I am not excluding future cookbook requests from community, that will land into pulpcore repo, simply because of [0]. Next what we’d do - close the submitted request against pulpcore repo per reasons you’ve outlined plus because it landed in the wrong repo. Having a separate unmaintained repo collecting all the feature requests and PRs is a better choice in this case.
So my thought was that we would archive specifically in order to not take new issues/PRs, because we don’t have enough Chef expertise and/or bandwidth to respond to them. It feels misleading to let ppl open requests that we have no capability/intention to respond to.
A repo can always be un-archived if we change our minds, or if someone wants to step up to the plate and “own” the repo.
I hear you on this, my thinking was to keep the history of community activity/requests. Sometimes priorities get shifted and motivation might be found if one sees how much something is needed by someone.
Depends how you look at it,
here are at least few tickets we don’t have bandwidth, intention nor knowledge to address them. What should we do about them?
And tbh when we got the cookbook repo ownership transferred from gmbnobis already at that moment we did not have neither bandwidth nor expertise.
Btw, I don’t have concerns archiving the repo just wanted to trow in another idea/perspective.
