CPS needs to do development fully in the open if it's going to replace pkg-config
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Domain
- build-system, tooling
Research direction
The issue names no file, test, or entry point. Start by reviewing the existing CPS issues and pull requests, then identify the project’s current contribution and review practices. Done means establishing a community process for reviewed changes, adding maintainers, and soliciting feedback from other build and packaging systems.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Python
- Stars
- 191
- Forks
- 14
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cps-org/cps
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 40/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Similar issues
-
md/asciidoc/csv: an explicit `encoding="utf-8"` keeps a leading BOM, the auto-detect path drops itOpen
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
docling-project/docling#4846 ·
Maintainers usually reply within 1 day
-
area/sessions comp/dashboard comp/desktop comp/gateway comp/tui duplicate P2 sweeper:risk-session-state type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#138914 · 1 comment ·
Maintainers usually reply within 1 day
-
bot-triaged module: activation checkpointing module: inductor oncall: pt2 triaged
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
[oblt-aw][autodoc] Update PR Actions Detective E2E prerequisites and fix dashboard-format table typoOpendocumentation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/oblt-aw#2382 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day