-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Update AutoPull - Temporary fix for #1806 #1809
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about deleting the DateOfContractSignature
field instead of assigning a constant value to it?
e.g. on L146, change to in-lining the "Contracted" constant:
Line 146 in f95b832
e.DateOfContractSignature, |
Then we can delete L121 and L103, L104.
As written the "Contracted" constant will be normalized to "contracted" and the field has no variability in possible values.
(If it's easier I can open a PR implementing my suggested feedback in a couple hours) |
There's actually more work to do... It looks like the Go tool unit tests aren't being run as part of pull request status checks anymore, just the cronjob that runs the code in The Go tests used to be run explicitly via Travis for all pull requests: Line 6 in f95b832
The new GitHub actions replacement for Travis that was added in #1750 only runs the list/.github/workflows/test.yml Lines 18 to 19 in f95b832
|
PTAL at #1812 I think it will achieve the same goals as this branch in a tidier way. |
Closing in favor of #1812 |
I have just been notified by ICANN's Technical Services that they will preserve the contract date of original signing. So now the question will be, "do we re-introduce the date?" Rather than reintroducing it, I think instead introducing some human-readable datestamp in the .dat header would solve the problem that the contract date was helping address - troubleshooting time-lag where folks were not updating their file as TLDs were being added to the zone file. |
How meaningful was that entry? Personally, I don't recall if we ever had it for a particular purpose. I don't feel any pressure to reintroduce it. |
It was really only for the troubleshooting specifics of lag time when TLDs
would get added to the root but not function in some of the browsers or
other applications or systems.
I'd say it is ok to not re-introduce
…On Tue, Aug 8, 2023 at 6:10 AM Simone Carletti ***@***.***> wrote:
So now the question will be, "do we re-introduce the date?"
How meaningful was that entry? Personally, I don't recall if we ever had
it for a particular purpose. I don't feel any pressure to reintroduce it.
—
Reply to this email directly, view it on GitHub
<#1809 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACQTJIDW2L4HDATHV4OGX3XUI3FXANCNFSM6AAAAAA2Y5HCMM>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
This updates newtlds.go to replace the with "Contracted" in the header per 2012 round nTLD as a tempfix to #1806
Short version of #1806 is that now we're 10 years ++ hence from the 2012 round TLD launches, the contracts are hitting their 10 year horizon and are being renewed. ICANN is updating the contract date field in the gtlds.json file, and this would result in a large quantity of auto-pull to merge with the new dates as this happens.
There are discussions with ICANN's technical team to see about them leaving the contract dates intact in contractdate vs re-using the contractdate field to store the contract renewal date.
It is anticipated that this pull request being merged will cause one large pull request that alters the entire nTLD section's contracted dates in the comment per nTLD, but will then reduce the subsequent noise level when ICANN renews contracts with the various Registries.