More frequent, smaller hardforks vs. less frequent, larger ones

ethereum-roadmap
hardfork

#21

On the all core devs call just now @holiman proposed an “EIP-centric” upgrade process rather than a hard-fork centric model like we have now. @AlexeyAkhunov also expressed concern about a deadline, like the May 17 Istanbul deadline, meaning that folks would have to rush their EIPs in before the deadline lest they “miss the boat” and have to wait 9 or 12 months until the next hard fork. I’m also concerned about people submitting half-baked “placeholder” EIPs before the deadline.

I like Martin’s idea a lot, especially in combination with smaller, more frequent hard forks. @shemnon’s proposal at https://github.com/shemnon/EIPs/blob/4e3069b4f9a30a639b142151dc6295f634712786/EIPS/eip-network_upgrade_windows.md looks reasonable to me.


#22

Advantages to fast enough upgrade schedule:

  • If a feature isn’t ready on time it’s not a huge slip to wait for the next upgrade.
  • Upgrades happen too fast for the mob to get mobilized.
  • Discussion of EIPs gets pushed further back into the process where it belongs.
  • Upgrades may become as uneventful as Apple point releases.

Disadvantages:

  • Developers are testing more than developing.
  • The mob never stops screaming that they weren’t consulted.
  • More work and coordination for miners.

#23

Testing is a thankless task for developers. It’s a job that real testers like to do.


#24

From AllCoreDevs:

Nick Sawinyh @sneg55 09:06

More work and coordination for miners.

It’s not a big deal actually for most of mining pools.

Peter Salanki @salanki 13:00
+1 on Nicks comment. Updating node software for mining pools is very painless. Takes 5 minutes for me

Greg Colvin @gcolvin 14:34
Then we are down to the mob, which I don’t care about, and the lack of testing resources.


#25

+1 Lack of testing resources.


#26

Top developers and engineers know to own their code. They know that the engineering includes testability, including all the code for testing, keeping tests reliable, efficient, maintainable, extensible, etc.
Yes, other eyes and engineers are required for producing robust code, but the culture needs to be more on ownership rather than on other people/testers to find the bugs or security issues.
There are engineers that come from such cultures but usually they are very comfortable in their big company jobs.

I’m not writing this to argue but to clarify your points further. +1 to a lack of engineers on fronts like testing, security, performance…


#27

Over the years I’ve seen many patterns on the relationship of development and testing. But when I have worked with professional test engineers I’ve found that they are simply much better at it than I am, as you would expect.

When I have been sole owner and tester of my code I can do fine. I spent three years writing one system that manifested only one bug in the next seven years in production. But I’m more productive when I can concentrate my efforts where I am most skillful, and let test engineers concentrate their efforts where they are most skillful.

This is independent of big vs. small company. The best test engineer I ever worked with was at a tiny startup. But it’s true that no big company I worked at failed to have professional test engineers on staff. Lots of them.

What’s been hardest here is maintaining ownership in an open-source environment that lets anybody on earth make PRs.