AI-First Merge Strategy

[matthewkeil]

Why this discussion exists

In the age of AI development there will be a lot more build the full thing style development that will serve to rough-out large features. But all of this code still needs to undergo human refactor and review to get it a finalized state that can actually get merged to unstable. This has created a few problems:

1. What is the diff for remaining code that needs to be refactored
2. What branch does a contributor target when building the next feature
3. How do we test the chunks that get refactored and merged to unstable

Existing Process using epbs-devnet-0 as an example to explain the issues.

"Hey lodekeeper, please use the existing chunks that we have and build the rest of the epbs devnet-0 branch to get us live". Now we have a "long-running branch" that has served us well as a roadmap for what chunks need to be built out to get things stabilized. We build bits and pieces into PR's and are working to get them all merged. But this has created an issue. When building one of the chunks, the range sync PR, there is no way to test this code. The functionality was extracted, semi-copy and paste, and then refactored manually to get it ready for actual merge to unstable. There is no existing way to test this code until all features from devnet-0 branch are rebased on top of that PR. And furthermore all of the other PR's that are currently under review are not in the unstable that the range sync PR was based on.

unstable <--------- epbs-devnet-0 branch <----- devent-0 fixes to "make it work"
         |--- epbs-feature-1
         |--- epbs-feature-2
         |--- epbs-feature-3

The "hacked together" branch 0 is what is currently being run by ethpandaops. This is also the branch that hotfixes are getting merged into so that we can keep up with bugs and spec updates. "Proper" PR's intoepbs-devnet-0 branch is unrealistic at the pace of devnet development and also unnecessary. Just hack it together and get it to run.

This is where the issue lies. We have moving targets when it comes to coordination across the team.

1. what is the next piece to get refactored and how can a team-member easily isolate what bits have already been incorporated in other PR's that are already under review.
2. how can i build functionality on the HEAD of devnet-0 branch when its moving.

The solution of "just read the open PR's" is an inadequate coordination mechanism.

Those are all moving targets and a small amount of automation fixes this situation.

How to potentially solve this situation

unstable <--------- epbs-devnet-0 branch <----- devent-0 fixes to "make it work"
         |--- epbs-feature-1
         |--- epbs-feature-2
         |--- epbs-feature-3
         |--- epbs-post-merge-state <---------- epbs-devnet-0-remainder branch

Can make a cron job that on a daily basis takes each epbs-feature-* branch and squashes it into a single commit on epbs-post-merge-state. So on a daily basis the epbs-post-merge-state will reflect the current unstable and a set of commits the PRs currently under review. epbs-post-merge-state becomes the "canonical" unstable that epbs (or whatever fork we are working on). Then the same cron job will refactor epbs-devnet-0-remainder branch so it matches the functionality of epbs-devnet-0. epbs-devnet-0-remainder will be the branch that we can run on our local infrastructure to sanity check that all the code we are merging is actually good.

This resolves two issues.

1. merging untested code into unstable
2. being able to test code before putting a PR up to unstable

Contribution Process

I would like to build out "range sync" to get it ready for PR. That functionality is currently part of the devnet-0 amalgamated branch. The process I would follow is something like this:

• check out a new branch based on top of epbs-post-merge-state
• get my LLM (claude/codex) to use epbs-devnet-0-remainder as a basis to extract the functionality I want to work on
• get my LLM to refactor my local copy of epbs-devnet-0-remainder and save it as epbs-devnet-0-remainder-range-sync-removed
• work on my epbs-range-sync branch to get it to a point where I'm ready to put it on a feature group to test things out
• optionally get any devnet-0 fixes incorporated into epbs-devnet-0-remainder-range-sync-removed
• tell my LLM to rebase epbs-devnet-0-remainder-range-sync-removed on my epbs-range-sync branch and fix conflicts
• deploy epbs-devnet-0-remainder-range-sync-removed to a no-group server to sanity check that my branch actually works