Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upHuman friendly incantations + Auto Closing/Postponing RFCs + More labels #197
Conversation
Centril
added some commits
Apr 20, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 20, 2018
Collaborator
Hmm... The error arises from failing to compile diesel_cli v1.2.0.
|
Hmm... The error arises from failing to compile |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 20, 2018
Collaborator
Update: I updated the lockfile & bumped the nightly version to 2018-04-19; this seems to have fixed things.
|
Update: I updated the lockfile & bumped the nightly version to 2018-04-19; this seems to have fixed things. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
aturon
Apr 20, 2018
Collaborator
These changes look fantastic to me!
I only have one concern: right now, once an RFC is in FCP, adding a concern doesn't take it back out of FCP. That'd be nice to improve in general, and it becomes even more important if the bot is going to automatically close RFCs.
|
These changes look fantastic to me! I only have one concern: right now, once an RFC is in FCP, adding a concern doesn't take it back out of FCP. That'd be nice to improve in general, and it becomes even more important if the bot is going to automatically close RFCs. |
anp
reviewed
Apr 20, 2018
| .first::<GitHubUser>(conn) { | ||
| Ok(i) => i, | ||
| Err(why) => { | ||
| error!("Unable to retrieve proposal initiator for proposal id {}: {:?}", |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anp
Apr 20, 2018
Owner
I need to double check the schema, but I'm pretty sure the database ensures this never happens and so this can probably be safely written as an expect.
anp
Apr 20, 2018
Owner
I need to double check the schema, but I'm pretty sure the database ensures this never happens and so this can probably be safely written as an expect.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 21, 2018
Collaborator
For now, to be on the safe side I'll keep the match. I'll change later if you are sure. :)
Centril
Apr 21, 2018
Collaborator
For now, to be on the safe side I'll keep the match. I'll change later if you are sure. :)
| }, | ||
| } | ||
| fn is_rfc_repo(issue: &Issue) -> bool { |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anp
Apr 20, 2018
Owner
Can you make this a part of teams.toml (maybe rename to rfcbot.toml and move current fields under a top-level teams key)? It would be very nice to not regress progress towards #92.
anp
Apr 20, 2018
Owner
Can you make this a part of teams.toml (maybe rename to rfcbot.toml and move current fields under a top-level teams key)? It would be very nice to not regress progress towards #92.
| match disposition { | ||
| FcpDisposition::Merge => {} | ||
| FcpDisposition::Close => { | ||
| msg.push_str("\n\nBy the power vested in me by Rust, I hereby close this RFC."); |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anp
Apr 20, 2018
Owner
Note that this won't be an accurate comment to post until rfcbot is given more permissions on the rust-lang org. Can we make this conditional on whether actually closing the issue succeeded? That might require a slight change to order of operations.
anp
Apr 20, 2018
Owner
Note that this won't be an accurate comment to post until rfcbot is given more permissions on the rust-lang org. Can we make this conditional on whether actually closing the issue succeeded? That might require a slight change to order of operations.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 21, 2018
Collaborator
Then you have to close the issue first which looks a bit weird imo. The current ordering feels natural as how a human would do it :) We should just give the bot these permissions imo.
Centril
Apr 21, 2018
Collaborator
Then you have to close the issue first which looks a bit weird imo. The current ordering feels natural as how a human would do it :) We should just give the bot these permissions imo.
Centril
added some commits
Apr 20, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
| if proposal.fcp_start.is_some() { | ||
| // Update DB: FCP is not started anymore. | ||
| proposal.fcp_start = None; | ||
| match diesel::update(fcp_proposal.find(proposal.id)) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anp
Apr 21, 2018
Owner
Do you think the bot should comment when it's doing this? Could be confusing to do this without any visible status update?
cc @aturon
anp
Apr 21, 2018
Owner
Do you think the bot should comment when it's doing this? Could be confusing to do this without any visible status update?
cc @aturon
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 22, 2018
Collaborator
My thinking is that:
let _ = issue.add_label(Label::PFCP);
issue.remove_label(Label::FCP);serves as visible status update that the bot reacted to the concern :)
Centril
Apr 22, 2018
Collaborator
My thinking is that:
let _ = issue.add_label(Label::PFCP);
issue.remove_label(Label::FCP);serves as visible status update that the bot reacted to the concern :)
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
aturon
Apr 28, 2018
Collaborator
Yeah I think that suffices, given that the concern registration is already a comment.
aturon
Apr 28, 2018
Collaborator
Yeah I think that suffices, given that the concern registration is already a comment.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
anp
Apr 30, 2018
Owner
Hi @Centril! If I'm reading correctly, the only thing remaining is to configure the RFCs repo string via a configuration file. If that's the case, let's get this in and create a follow-up issue or add a comment on the issue I linked before?
|
Hi @Centril! If I'm reading correctly, the only thing remaining is to configure the RFCs repo string via a configuration file. If that's the case, let's get this in and create a follow-up issue or add a comment on the issue I linked before? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Centril
Apr 30, 2018
Collaborator
@anp that works for me :) Sorry about not following up on this sooner.
One thing I'm a bit unsure about as to making this work for all repos is whether there is one instance of the rfcbot program running for rust-lang/rust and rust-lang/rfcs or if there are separate instances for each.
If there is just one instance, then you need to be able to configure close / postpone behavior separately for each repo.
For now I propose:
[fcp_behaviour."rust-lang/rfcs"]
close = true
postpone = true
[teams]
# other stuff....|
@anp that works for me :) Sorry about not following up on this sooner. One thing I'm a bit unsure about as to making this work for all repos is whether there is one instance of the rfcbot program running for rust-lang/rust and rust-lang/rfcs or if there are separate instances for each. If there is just one instance, then you need to be able to configure close / postpone behavior separately for each repo. For now I propose: [fcp_behaviour."rust-lang/rfcs"]
close = true
postpone = true
[teams]
# other stuff.... |
Centril
referenced this pull request
Apr 30, 2018
Closed
Controllable auto-close/postpone behavior #201
anp
merged commit 9f52efd
into
anp:master
Apr 30, 2018
1 check passed
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Thank you so much! |

Centril commentedApr 20, 2018
This PR aims to fix:
finished-final-comment-period+ labels for disposition)In addition, the PR improves the FCP-completed comment and also auto-closes FCP-completed RFCs with a disposition to
close/postponedand applies those labels when doing so.I haven't had time to test this on any repository, so please double check this logic =)
I also haven't added the new labels to the rfcs or rust repos. I'll do that before / if we merge this PR.
In total, these labels are added:
The
postponedlabel already exists for the rfcs repo.