I think in a team with good ownership, enforcing formal reviews slows down a lot. But of course in a larger code base where no single engineer can understand all the effects a change might have, having a bit of knowledge sharing and 4 eyes enforced is often the better approach than yolo-ing it.

Then again I did build an SQL review tool for database access because I felt like "yolo-ing" production access was also not the way it should be. It's an interesting slider between full autonomy and strict review processes where each team needs to find their sweet spot: https://github.com/kviklet/kviklet/

Do you take their tagged release, fix it there, and then send them that branch release with the fix, or do you send them a fix on current main - you know, the main that is now a million releases ahead with multiple breaking changes? And what about all the intermediate release tags? Do you fix each one there too if they have the problem, or do you only update when customers on those releases start having that issue too?

And if you fix to their old tagged release which is incompatible from main, does this mean you have to do this fix twice i.e on their tagged release and also fix it for main? But what if this fix affects other people who are all on different branches too? Now… times this by 20 different customers all running different hardware and different branches with different problems :(

Maybe my comments are off topic, and don’t get me wrong - I prefer “trunk is releasable” motto, but I think maybe as an industry we should all come up with an Acid Test (like the only CSS Acid Tests) so we can through all these branching strategies into the ring

But probably the worst part was that when I started it was a loose organization where anyone could sneakily merge something into trunk. That changed quickly.

All work was done against a develop branch, and every two weeks, the admin would DELETE THE TRUNK and recreate it from a COPY of develop.

Every two weeks, we lost all history and context for changes in any given release. This was an effort to stop bugs coming back in merge regressions.

Can you guess how well this worked out for them?

Seriously wish the stacked PR workflow would gain more traction outside of FAANG. Apart from the (somewhat pricey) Graphite offering, there's no standard UI for managing stacked PRs in the wild.

It allows you to get feedback from customers very fast.

It allows you to improve the software very fast.

It allows you to react to the feedback you just got very fast.

Yes, its tricky! You need fast builds, that give you actionable feedback on whether you did a whoopsie.

Yes, it works for all sorts of things: regulated industries, incl finance, embedded systems, apps, websites, ...

Yes, you do need to rethink how changes happen, to look for ways to make that big change into multiple or even many smaller changes, this often has lots of unanticipated benefits.

Yes, it scales to very large deployments and quite large teams.

Prescribed workflows apply solutions from the wrong direction.

Determine what's impeding your organization, devise a solution.

The last guy I encountered who evangelized something like this had smart frames and a Lovecraft anthology prominently perched in the background of his Zoom shot.

especially combined with monorepo

amount of time people spend updating dependencies between internal services and libraries in a pursuit of semver for now reason is just absurd