|20 Jan 2020|
|00:37:55||bobsummerwill|| So we have:|
0,000,000 = Frontier
1,150,000 = Homestead
2,500,000 = Classic Tangerine Whistle
3,000,000 = Die Hard
5,000,000 = Monetary Policy
5,900,000 = ECIP1041 (needs a name!) "Remove Difficulty Bomb?"
8,772,000 = Atlantis (~= ETH Spurious Dragon + Byzantium)
9,573,000 = Agharta (~= ETH Constantinople)
|03:24:23||DonaldMcIntyre|| sorpaas |
* Use Aztlan Redo specification https://corepaper.org/ethereum/fork/istanbul/#_aztlan_redo for Chicomoztoc, applying it around one or two months after Aztlan, and withdraw ECIP-1061.
Why do you say that what I propose is irregular/unusual/not possible according to process, but then proceed to propose that ECIP-1061 can be "withdrawn" and replaced/redone by "Chicomoztoc" which is exactly what I am proposing?
> Unless you eagerly want more bugs on Ethereum Classic...
...pls discontinue your threats and accusations of others working here to make ETC as robust and best as possible...the only "bug" in the ECIP process I see is your extremely dysfunctional attitude and interactions.
|03:28:02||DonaldMcIntyre||Redacted or Malformed Event|
|03:28:13||DonaldMcIntyre||Redacted or Malformed Event|
|03:28:51||DonaldMcIntyre|| bobsummerwill yaz GregTheGreek soc1c I think this is what I intuitively think would be the best path if there is rough consensus on this path forward to "redo" Aztlan:|
the only "bug" in the ECIP process I see is your extremely dysfunctional attitude and interactions.I find it funny that you state I'm the "bug", while at the same time, using specifications and reviews I wrote, in my free time, voluntarily for ETC.
Why do you say that what I propose is irregular/unusual/not possible according to process, but then proceed to propose that ECIP-1061 can be "withdrawn" and replaced/redone by "Chicomoztoc" which is exactly what I am proposing?You were suggesting moving 1061 from "accepted" to "draft", which would indeed be irregular/unusual/not possible, but anyway, good that we finally agree on something -- move 1061 to withdrawn and replace it with Chicomoztoc.
pls discontinue your threats and accusations of others working here to make ETC as robust and best as possibleDonaldMcIntyre You are accusing the wrong person. The real threats in ETC are those who try to bypass the ECIP process, rush ECIPs without sufficient reviews, or set unrealistic date for hard fork without input from client developers. Those happened in ECIP-1061 and some people are trying to do it again. That's why I said they "eagerly want more bugs on ETC".
|03:51:13||GregTheGreek||After analysis - it seems to me that the changes proposed in "redo" Azltan are infact accurate.|
|03:53:39||GregTheGreek||Both Aztlan Fix and Azltan Redo seem rational to me - we'll be able to make necessary changes in time for Feb Mordor should we need to.|
|03:54:02||GregTheGreek||Redacted or Malformed Event|
|03:54:37||GregTheGreek||That being said - if there are bandwidth from any client teams, we have the bandwidth to make the necessary changes to all the clients.|
|03:59:03||sorpaas|| It's simply not possible to catch Feb Mordor, even if we want. For parity-ethereum, there requires to be around 2 weeks ahead of notice. For multi-geth, all the parts related to 1283/1706 and the new opcode need to be implemented and tested.|
The above is with assumption that you are absolutely sure the new specification has absolutely no issue, which is definitely not the case considering what has happened in ECIP-1061. That means we'd need at least around 6 weeks of review period for it, before even considering to apply it on testnets.
|04:00:24||sorpaas||Redacted or Malformed Event|
So in summary, Feb Mordor either continues as it currently is, or has to be called off.
It's simply not possible to catch Feb Mordor, even if we want. For parity-ethereum, there requires to be around 2 weeks ahead of notice. For multi-geth, all the parts related to 1283/1706 and the new opcode needs to be implemented and tested.
|04:05:10||GregTheGreek||Not taking a side, but im curious why partiy needs 2 weeks?|
|04:07:33||sorpaas|| That's just the usual time it was required for a release to be prepared and to happen. We also asked this during ETH Istanbul.|
Under tight schedules, like the Muir Glacier, we had one week to prepare the release, but TBH that was a rush and I don't think we're going to do that there.
|17:04:51||phyro||Redacted or Malformed Event|
|17:04:55||phyro||Removing a member/owner would only be in the case when we didn't trust that a person wants well for ETC. sorpaas has been trusted for years and he didn't abuse the trust|
|17:52:06||zacmitton||Haven’t really been following but I would trust soc1c with his opinion on the timeframes|
|19:12:48||DonaldMcIntyre|| There is an ECIP candidate to discuss my proposal to remove sorpaas |
|19:17:11||GregTheGreek||Redacted or Malformed Event|
|19:17:12||GregTheGreek||I'm chatting with soc1c re timelines|
|19:30:16||DonaldMcIntyre|| sorpaas |
Thank you for presenting your resignation. I have requested all editors and repo managers to proceed to remove you.
|20:37:14||DonaldMcIntyre|| can editors pls move fast to correct this doxxing pls ASAP?|
|20:45:58||Ronin||Redacted or Malformed Event|
|20:46:06||Ronin||Redacted or Malformed Event|