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

Amend the template from RFC 1589 #2658

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@pnkfelix
Copy link
Member

pnkfelix commented Mar 8, 2019

Amend the issue template from text of RFC 1589 to match current actual practice of future-compatibility lints.

In particular, while working on rust-lang/rust#58608, I discovered that the current batch of C-future-compatibility tracking issues don't look anything like the template provided in this RFC.

So I took inspiration from one them (rust-lang/#57644 in particular) when composing my own rust-lang/rust#59014, but I wanted to back-propagate the template that seems to have evolved into the original RFC text so that people who use the RFC as the basis for their own issue will start off on the right foot.

Show resolved Hide resolved text/1589-rustc-bug-fix-procedure.md

- [ ] PR ? introduces the `YOUR_LINT_NAME_HERE` lint as warn-by-default
- [ ] PR ? makes the `YOUR_LINT_NAME_HERE` lint deny-by-default
- [ ] PR ? makes the `YOUR_LINT_NAE_HERE` lint a hard error

This comment has been minimized.

@Centril

Centril Mar 8, 2019

Contributor

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.

This comment has been minimized.

@pnkfelix

pnkfelix Mar 11, 2019

Author Member

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.

This comment has been minimized.

@Centril

Centril Mar 11, 2019

Contributor

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.

This comment has been minimized.

@pnkfelix

pnkfelix Mar 11, 2019

Author Member

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.

@Centril Centril requested a review from nikomatsakis Mar 8, 2019

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Mar 8, 2019

The https://forge.rust-lang.org/rustc-bug-fix-procedure.html page also needs updating after this. :)


*Explain here what the developer needs to do to address the warning.*

#### Current status

This comment has been minimized.

@nikomatsakis

nikomatsakis Mar 8, 2019

Contributor

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.

This comment has been minimized.

@Centril

Centril Mar 8, 2019

Contributor

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.

This comment has been minimized.

@pnkfelix

pnkfelix Mar 13, 2019

Author Member

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?

Show resolved Hide resolved text/1589-rustc-bug-fix-procedure.md
Address review feedback by putting back the initial paragraph of temp…
…late.

Since that initial paragraph includes the link to RFC 1589, I removed
the suggestion (that I added) to include the link from the "What is
this lint about" section.

@pnkfelix pnkfelix requested a review from nikomatsakis Mar 13, 2019

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Mar 13, 2019

I think the current state of this PR is good and we should merge this for now. Follow up work is discussed in https://rust-lang.zulipchat.com/#narrow/stream/185694-t-compiler.2Fwg-meta/topic/future-incompat.20planning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.