diff --git a/crates/q_cli/src/cli/user.rs b/crates/q_cli/src/cli/user.rs index 4b17058a4f..90c408c4ff 100644 --- a/crates/q_cli/src/cli/user.rs +++ b/crates/q_cli/src/cli/user.rs @@ -1,6 +1,9 @@ use std::fmt; use std::fmt::Display; -use std::process::ExitCode; +use std::process::{ + ExitCode, + exit, +}; use std::time::Duration; use anstream::println; @@ -144,6 +147,8 @@ pub enum UserSubcommand { impl UserSubcommand { pub async fn execute(self) -> Result { + ctrlc::set_handler(|| exit(1))?; + match self { Self::Root(cmd) => cmd.execute().await, } diff --git a/rfcs/0000-template.md b/rfcs/0000-template.md new file mode 100644 index 0000000000..c2d51ec23f --- /dev/null +++ b/rfcs/0000-template.md @@ -0,0 +1,80 @@ +- Feature Name: (fill me in with a unique ident, `my_awesome_feature`) +- Start Date: (fill me in with today's date, YYYY-MM-DD) + +# Summary + +[summary]: #summary + +One paragraph explanation of the feature. + +# Motivation + +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Guide-level explanation + +[guide-level-explanation]: #guide-level-explanation + +Explain the proposal as if it was already included in the project and you were teaching it to another maintainer. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Discuss how this impacts the ability to read, understand, and maintain the codebase. Code is read and modified far more often than written; will the proposed feature make code easier to maintain? + +# Reference-level explanation + +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +# Drawbacks + +[drawbacks]: #drawbacks + +Why should we _not_ do this? + +# Rationale and alternatives + +[rationale-and-alternatives]: #rationale-and-alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +# Unresolved questions + +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +# Future possibilities + +[future-possibilities]: #future-possibilities + +Think about what the natural extension and evolution of your proposal would +be and how it would affect the language and project as a whole in a holistic +way. Try to use this section as a tool to more fully consider all possible +interactions with the project and language in your proposal. +Also consider how this all fits into the roadmap for the project +and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the +RFC you are writing but otherwise related. + +If you have tried and cannot think of any future possibilities, +you may simply state that you cannot think of anything. + +Note that having something written down in the future-possibilities section +is not a reason to accept the current or a future RFC; such notes should be +in the section on motivation or rationale in this or subsequent RFCs. +The section merely provides additional information. diff --git a/rfcs/0001-rfc-process.md b/rfcs/0001-rfc-process.md new file mode 100644 index 0000000000..55d4c76a10 --- /dev/null +++ b/rfcs/0001-rfc-process.md @@ -0,0 +1,98 @@ +- Name: RFC Process +- Start Date: 2025-03-19 + +# Summary + +The "RFC" (request for comments) process is intended to provide a +consistent and controlled path for new features to enter the language +and standard libraries, so that all stakeholders can be confident about +the direction the language is evolving in. + +# Motivation + +This is a proposal for a more principled RFC process to make it +a more integral part of the overall development process, and one that is +followed consistently to introduce features to QCLI. + +# Detailed design + +Many changes, including bug fixes and documentation improvements can be +implemented and reviewed via the normal GitHub pull request workflow. + +Some changes though are "substantial", and we ask that these be put +through a bit of a design process and produce a consensus among the +community and the maintainers. + +## When you need to follow this process + +You need to follow this process if you intend to make "substantial" +changes to QCLI. What constitutes a "substantial" +change is evolving based on community norms, but may include the following. + +- Adding or removing features, including those that are feature-gated. +- Adding new crates or dependencies + +Some changes do not require an RFC: + +- Rephrasing, reorganizing, refactoring, or otherwise "changing shape + does not change meaning". +- Additions that strictly improve objective, numerical quality + criteria (warning removal, speedup, better platform coverage, more + parallelism, trap more errors, etc.) +- Additions that are invisible to users of QCLI. + +If you submit a pull request to implement a new feature without going +through the RFC process, it may be closed with a polite request to +submit an RFC first. + +## What the process is + +In short, to get a major feature added to QCLI, one must first get the +RFC merged into the RFC repo as a markdown file. At that point the RFC +is 'active' and may be implemented with the goal of eventual inclusion +into QCLI. + +- Fork this repo. +- Copy `rfcs/0000-template.md` to `rfcs/0000-my-feature.md` (where + 'my-feature' is descriptive. don't assign an RFC number yet). +- Fill in the RFC +- Submit a pull request. The pull request is the time to get review of + the design from the larger community. +- Build consensus and integrate feedback. RFCs that have broad support + are much more likely to make progress than those that don't receive any + comments. + +Eventually, a maintainer will either accept the RFC by +merging the pull request, at which point the RFC is 'active', or +reject it by closing the pull request. + +Whomever merges the RFC should do the following: + +- Assign an id, using the PR number of the RFC pull request. (If the RFC + has multiple pull requests associated with it, choose one PR number, + preferably the minimal one.) +- Create a corresponding issue in this repo. +- Commit everything. + +Once an RFC becomes active then authors may implement it and submit the +feature as a pull request to the repo. An active RFC is not a rubber +stamp, and in particular still does not mean the feature will ultimately +be merged; it does mean that in principle all the major stakeholders +have agreed to the feature and are amenable to merging it. + +Modifications to active RFC's can be done in followup PR's. An RFC that +makes it through the entire process to implementation is considered +'complete'; an RFC that fails +after becoming active is 'inactive' and moves to the 'inactive' folder. + +# Alternatives + +Retain the current informal RFC process. The newly proposed RFC process is +designed to improve over the informal process in the following ways: + +- Discourage unactionable or vague RFCs +- Ensure that all serious RFCs are considered equally +- Give confidence to those with a stake in Rust's development that they + understand why new features are being merged + +As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Python's [PEP] process for inspiration.