CPS needs to do development fully in the open if it's going to replace pkg-config

[dcbaker]

CPS has reached the point of maturity that if it's going to displace systems like pkg-config, it needs to move to a community model of changes. Right now there are issues and PRs that have been opened for years with no comments, or that have a token comment, and the response is being ignored. Meanwhile changes are being pushed without review or feedback, some of which make the spec ambiguous. There is only one committer, who works on one build system.

What I would love to see for CPS to become the dependency configuration system of the future (having one thing we can all share and increase interoperability would be great):

• Require that all changes be submitted as PRs and not be merged without review (with some guidelines on how much review different kinds of changes require, as a appropriate)
• Add additional maintainers, specifically who work on other build systems and packaging systems (I would be happy to help, and I am a Meson maintainer)
• Approach additional build and packaging systems about CPS, and solicit real feedback and address that feedback. build2 and the GNU autotools come to mind as two build systems that I haven't seen anyone from make comments here.

[mwoehlke]

Require that all changes be submitted as PRs and not be merged without review (with some guidelines on how much review different kinds of changes require, as a appropriate)

I am trying to handle potentially-contentious changes that way, but your proposal only works if other people are also willing to contribute. Maybe you would care to review or comment on #17?

Similarly, some of those "ignored responses" are my responses, to issues waiting on feedback from the OP. Maybe I should just close issues that don't seem likely to be resolved?

It sounds like you are volunteering to be a co-maintainer?

[leha-bot]

I also would like to participate in this activity☺️ I am a free time CMake, Conan and vcpkg (and had an experience to write C++ proposals)

I was experimenting with these tools for supporting some CPS-inspired manifests, and also I want to remind that vcpkg currently has its own json format for consuming dependencies (it's mostly basically about dependency tree, libraries versions and "features" - some sets of dependencies subtrees which could be toggled via that feature while getting that library via vcpkg)

Thanks in advance for your attention

[dcbaker]

@mwoehlke Yes, I'm volunteering to co-maintain.

Having worked on pkg-config and pkgconf I've come to the conclusion that to make pkg-config a viable path for the future we'd need a pkg-config 2.0, which would end up looking a lot like CPS anyway,.

[bretbrownjr]

My expectation is that this project should have a healthy community model. Everyone feel free to contribute to the project given whatever permissions you currently have, including commenting on issues, reviewing PRs, and so on.

If someone wants to help in more ways but doesn't have the required permissions, reach out to me and @mwoehlke. I'll at least help you stay unblocked on your task, but discussion about sharing more project ownership responsibilities would be on the table.

I personally find that making a "space" to hang out and get to know one another more interactively helps with a healthy project, including raising concerns about responsiveness on issues. We do have #ecosystem_evolution on https://cpplang.slack.com, a mailing list to be accessible to folks that don't do GitHub notifications, and a monthly Zoom call organized on the mailing list. I have notifications turned on for all of the above if anyone wants to find me.

[jonahbeckford]

I can do a bit of reviewing for PRs if you need help. I haven't fully committed to CPS yet, but I suspect I'll end up choosing it.

My own interest is two-fold:

1. I maintain a Windows distribution for the OCaml programming language (https://gitlab.com/dkml/distributions/dkml). Interfacing with C libraries is very difficult on Windows. The pkg-config model is broken in so many ways on Windows, and the only real alternative is to make first-class citizens of one of the C package managers (ie. support vcpkg or conan). CPS seems like a big improvement. In fact, using CPS as an alternative package spec for OCaml may solve some esoteric problems beyond Windows.
2. I also maintain a (commercial) set of CMake extensions for OCaml at https://diskuv.com/cmake/help/latest/. My interest there is just keeping up to date with major changes to CMake.