Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Small updates to CEPs? #97

Open
jaimergp opened this issue Nov 6, 2024 · 2 comments
Open

RFC: Small updates to CEPs? #97

jaimergp opened this issue Nov 6, 2024 · 2 comments

Comments

@jaimergp
Copy link
Contributor

jaimergp commented Nov 6, 2024

What's the process to provide technical updates and corrections to already approved CEPs? For example, we have found the need to add a couple fields to the menuinst v2 schema (CEP 11), and I think the new recipe.yaml schema has also seen a couple updates since its approval.

Would a regular PR cycle (+ approval) here suffice or do we need a new CEP to amend the existing ones, with the corresponding vote overhead?

cc @conda/steering-council @conda/ceps

@beckermr
Copy link

beckermr commented Nov 6, 2024

I think we allow prs w/ review required, but at any time a steering-council can request a vote on a pr, even after it is merged.

@jezdez
Copy link
Member

jezdez commented Nov 6, 2024

To quote the voting item about CEPs:

Enhancement Proposal Approval

When ready, the proposer may call for a vote on an existing conda enhancement proposal (CEP). This requires a super-majority (60%) to pass so that the decision to accept the CEP is unequivocal and we have ensured that consensus has been reached.

The proposal system exists to reach consensus, primarily. Acceptance and approval of new proposals are collected by a supermajority to give that appropriate level of certainty. As long as bug fixes and tweaks to the proposal are not challenging the consensus recorded by the vote, but merely update it with details discovered during implementation, I don't believe we need a vote. The regular PR review process suffices.

That said, I think there is a risk of too many changes after approval, making proposals harder to implement for our diverse ecosystem. In those cases, it would be better to propose a new CEP in reference to the earlier CEP, so implementations can have a graceful rollout.

Finally, in doubt, a vote for confirmation of consensus can always be called again, like @beckermr said.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants