Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Amend the template from RFC 1589 #2658
base: master
Are you sure you want to change the base?
Amend the template from RFC 1589 #2658
Changes from all commits
fe67169
fcf1781
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, this seems like an improvement, but perhaps a bit premature -- I'm not sure if we always take these three steps? Still, I like the idea of showing the process more graphically, and I think we should adopt a "standard" time frame that is tighter than the "open-ended process" suggested by the old template.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably don't always take these steps but I think we often do and it seems like a good procedure :) -- I agree with standardizing the time-frame, or at the very least having a time-frame at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is there actually something for me to do here? I think starting with the provided three steps in the template makes more sense than leaving them out.
Do you want me to add an explicit note saying that people have the option to revise that section on a case-by-case basis?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to include:
Schedule
Describe the estimated schedule in terms of Rust releases for converting the warning to deny and then ultimately to a hard error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has any summary issue for a future-incompatibility lint included such a schedule?
I don't mind preserving parts of the original RFC that were good ideas, nor do I mind codifying existing practice, but in my quick skim earlier, I don't recall any future-incompatibility specifying a schedule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to my knowledge, but I think it would be good to have schedules for the purpose of effective tracking and triage; standardization of such schedules as Niko notes below would also be helpful imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay; I don't dispute the idea that we need to have a more upfront focus on the scheduling. If @nikomatsakis signs off on the text you drafted, then I'll add it to this PR.
But if its something that's going to want a lot of discussion/tweaking/bikeshedding, then I'd rather leave it to a different Pull Request.