This is probably several issues/ideas and a description of a use case.
IPFS
Upgrade proposals could specify an IPFS content address with the new binaries.
Reproducible Builds
New binaries could be signed by validators and built using the reproducible build system. This allows for a basic kind of quality assurance, despite the rapid upgrades.
CI
To increase the overall level of automation, and reduce the coordination workload, each validator could have a gitlab repository that builds and signs binaries using CI.
Upgrade Proposals
The only thing that is needed in addition to this is the upgrade proposal vote.
upgrade proposals are basically the only piece of this process that are not fully automatic.
Trouble with testnets
Testnets don't get enough eyeballs to effectively find bugs, and this is doubly or triply true for feature requests. No one cares until there is value (mainnet), and by the time there is value, it is too late.
So don't do testnets, or don't do much testnetting.
Instead of doing testnets, launch simple chains to production and even connect them to other chains using IBC.
Strap features onto them as you go.
Be very clear about the fact that the whole thing could explode.
Baby blockchains
The goal with this set of ideas is to allow a baby blockchain to be upgraded as often as several times a day while in production.
A baby blockchain announces itself as a baby launching. It sets the expectation that it is undergoing rapid iteration, and that things may break.
Validators on baby block chains use the auto download feature to automatically deploy new signed binaries that are distributed using IPFS.
Maturity
Babies grow up!
Most likely, over time, this rapid iteration method would no longer be suitable or appropriate for use.
The methods described here place a lot of trust in the people writing the chain code, because changes would basically flow from the master branch of the developer's repository, into the CI systems of every validator, to an upgrade proposal vote, and then almost immediately thereafter, into production.
I'm also not certain that I have described the technical process accurately yet. But I'm going to play around and see what I come up with.
Purpose:
- rapid iteration
- ease of use
- reduction of coordination effort
- High engagement
It is also designed to allow the community to have a more active role in the design of the blockchain software by ensuring their involvement at an earlier stage.
A baby chain could be as little as a simple coin that can be pinged between addresses, and it can evolve from there to something much more.
This process ensures high engagement, because it basically mandates frequent upgrade proposals. A baby blockchain without a highly engaged community, will find that it does not get to do upgrades.
Problems
There may be lots of issues with what I have described here. Please point them out :)