EIPs

EIPs copied to clipboard

This is included in the text and this PR adds it to the metadata.

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

---

(fail) eip-173.md

classification
updateEIP

• eip-173.md requires approval from one of (@mudgen, @danfinlay)

The commit 6feab2802cacc1aab167706433fb31339f99abe1 (as a parent of b4e3b495370fbd7fff89ffd300be112b135587cf) contains errors. Please inspect the Run Summary for details.

Personally, I wouldn't approve it because the standard would have to be brought up to current EIP formatting (and that involves non-normal changes). Alternatively, this could be manually merged. @MicahZoltu @lightclient thoughts?

I went ahead and fixed other non-normative issues (section order, and metadata order) complained from the bot.

I have not changed any text or normative things.

I have not changed any text or normative things.

I think you have normative vs non-normative flipped around:

Normative: the meaning is unchanged. Non-normative: the meaning is changed.

The concern was that updating the standard to current guidelines might have to result in normative changes, which we try to avoid in Final EIPs (for example, changing the discussions-to link is not possible here).

The commit 721ac76da153a86608b560fbc0c624a39c15d4f4 (as a parent of dd74519a10f6366e78ffc8d724031b107b97bf86) contains errors. Please inspect the Run Summary for details.

I have not changed normative things. My changes are non-normative.

---

And in plain English: I didn't change any specs.

Sorry, let me be a bit more specific:

Some of the changes required by eipw here require non-normative changes to the spec.

Got it.

I try to get all non-normative changes in one PR so that gets merged with less oversight required.

And then other stuff I try to separate out, because that might get held up.

@fulldecent if you can update the type field to be above category, I will approve.

@lightclient Got it, fixed at e0e0c1871072e0a93c89b0ded5c46acf9997f890

The commit e0e0c1871072e0a93c89b0ded5c46acf9997f890 (as a parent of a7e71ea664a915a94f8c0e4b8de30a7560b7723e) contains errors. Please inspect the Run Summary for details.

173 is FINAL, I lean towards follow IETF RFC approach to create a new EIP that "updates" EIP-165

ERC also needs to be replaced with EIP.

173 is FINAL, I lean towards follow IETF RFC approach to create a new EIP that "updates" EIP-165

This doesn't introduce any backward incompatibilities and is therefore fine.

This PR does not touch any mention of "ERC" or "EIP".

I am requesting that this here PR be reviewed and accepted as an incremental improvement and that any discussion of "ERC"/"EIP" be considered in a separate, isolated PR.

This PR does not touch any mention of "ERC" or "EIP".

eipw still requires that you fix the instances.

This PR does not touch any mention of "ERC" or "EIP".

eipw still requires that you fix the instances.

I suggest EIPW to be updated so that it only check modified lines rather than full file.

I suggest EIPW to be updated so that it only check modified lines rather than full file.

If the effort to bring an EIP up to date is not worth the change introduced in a PR, then the PR shouldn't be opened. eipw is specifically to ensure that all EIPs, regardless of age, are still of the correct format when they are changed. The errors must be fixed.

@fulldecent , You are correct. I take that back: the 173 already mandates 165. It's reasonable to add 165 as requires.

I am in favor of this commit to be merged without fixing all new requirement.

I suggest EIPW to be updated so that it only check modified lines rather than full file.

If the effort to bring an EIP up to date is not worth the change introduced in a PR, then the PR shouldn't be opened. eipw is specifically to ensure that all EIPs, regardless of age, are still of the correct format when they are changed. The errors must be fixed.

While I can see the good heart behind the requirement, I think requiring this may unnecessarily turn away contributors who just have time to make small improvements. Let me file a issue and we can discuss it in our next EIPIP meeting

While I can see the good heart behind the requirement, I think requiring this may unnecessarily turn away contributors who just have time to make small improvements. Let me file a issue and we can discuss it in our next EIPIP meeting

That's the point. We want to discourage small contributions as they take up precious editor time.

Rather than telling editors what they can't merge, in an effort to save their time... let's instead tell editors what they can merge, while minimizing the amount of synchronous back-and-forth required for them to do so.

Basically all my PRs get merged in this repo, that's why I keep making them.

I'm fine with @SamWilsn merging this then.

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

CC (@mudgen, @danfinlay) for approval

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.