Or better: at least two weeks into the future (as per EIP-1)

Or better: at least two weeks into the future (as per EIP-1)

I don't think we can do that (at least as part of eipw) because someone could open a PR to fix something minor (ex. typo) during the last call period, without having to change the last-call-deadline.

Can EIPW have a check that runs conditional on the specific PR/commit it is running against changing a specific line? If so, we would make it so that if (prChangedStatusLineTo('Last Call')) assert lastCallDeadline > now + 2 weeks

I'd like to keep anything GitHub related out of eipw (mostly because the Rust GitHub bindings didn't seem as good as the JS ones.) Doing it with pure git might be possible, but would probably rely on git blame, which wouldn't be the most accurate.

Any reason we couldn't implement the more accurate checks in EIP-bot?

Any reason we couldn't implement the more accurate checks in EIP-bot?

Our Rust developer is more active than our TypeScript developer. 😬

@SamWilsn I'd like to take on this task

By all means!

so i understand that there is no validation in place to ensure that the "last-call-deadline" is set to a date in the future. I've been looking through eip review bot with the merge.ts, process.ts, action.ts, and the files in the rules and searched "last-call-deadline" and other keywords.

yet still haven't found anything validating the "last-call-dealine".

what do you think about the preMergeChanges function in the merge.ts file? Could that be the place to make changes?

@Pandapip1

I don't maintain eipw. CC @SamWilsn

@apeaircreative I guess you can skip the review bot if you have issues with it. I didn't use it at all. Just focus on last-call-dealine implementation.

@SamWilsn @KatyaRyazantseva solved my first issue check out the pull requesr