RFCs like #3148 have been sitting in the background for about 10 months now, with no clear sign of getting merged even though they have finished their final comment period. Is there a way that we can perhaps clear them? Perhaps by giving RFCbot merge permissions?
Edit:oops, hand-typed the link. Thanks @dlight!
Fixed link RFC: map_or_default in Option and Result by orlp · Pull Request #3148 · rust-lang/rfcs · GitHub
Someone should probably re-submit it as an ACP to get it moving forward.
Agreed, but it's not just that rfc. There's also #3161 and #3641 (the latter even having a comment asking for timeline for merging). I think that this is an issue that should not occur at all.
(I didn't include the mitigation enforcement RFC because it is comparatively recent.)
The main problem I have with this is the finality of FCPs (final comment periods) not being entirely representative. After a final comment period, where the community has the time to raise objections, the RFC should be merged as a decision has already been made and all concerns arealready answered. So after the final comment period, IMO RFCs should be merged as soon as possible (immediately?) but they aren't always.
Yeah this has been a gap in our process since forever -- the process is manual and requires more than just pressing the merge button (one also has to fix up the filename and potentially the "rendered" link and maybe more). And apparently nobody is in charge of doing that. For my own RFCs I just kept pinging members of the team that approved the PR until someone figured out how to merge it...
[RFC2603] Extend `<const>` to include `str` and structural constants. by eddyb · Pull Request #3161 · rust-lang/rfcs · GitHub seems not obvious, I would be hesistant to merge it in its current status. Looks like [RFC2603] Extend `<const>` to include `str` and structural constants. by eddyb · Pull Request #3161 · rust-lang/rfcs · GitHub there are some concerns / unresolved questions.
This, at least, should be better now as the bot will IIRC do the rename when the PR is initially opened now.
Yes, most of the time this is about someone taking the procedural steps to do this, which takes a few minutes, but they are a manual few minutes that don't involve just pushing a merge button.
Occasionally, the problem is also that we FCPed an RFC while saying it needs a couple of changes, and the changes haven't been made yet.
So theoretically after it fixes the file we could give RFCbot merge permissions and have it automatically merge?
Should the FCP start before the changes are made? That doesn't seem right to me. I could be wrong though
If the issue is "please fix the typo" or "please add this one sentence", then it makes sense to run the FCP in parallel with that getting fixed.
Hmm.. understandable.
But it wouldnt be blocking in any way, right? So theoretically we could just have it merged... especially since the RFC is an informalish process.
But another idea I have is to make a tab in RFCbot.rs that details all the rfcs that have finished FCP but aren't merged. This will bring more visibility tothese RFCs.