[teknopaul]

As soon as your test suite grows to the point that users aren't likely to run ALL tests before pushing new changes, you can't.

Why?

I have run trunk for years, naturally you don't tag and deploy to prod if tests fail. But the world keeps turning if trunk has a test fail. Or a build breakage. Or a code style breakage. You just fix it. On trunk, everyone can see it and anyone can fix it.

Big fan on commit early.

[alkonaut]

> the world keeps turning if trunk has a test fail. Or a build breakage.

The world stops for the other developers that were unfortunate enough to pull/rebase their work when there was a build breakage. Having people shout “don’t pull, master is broken” is more overhead than is lost on PRs.

A test fail isn’t as serious as no one is completely blocked, but a CI build that has 5 test failures can easily get another 5 before 3 of the first 5 are fixed. Before the end of day 1 you have a dozen failing tests of 3-4 different ages, some of which aren’t attributed to those who broke them. Finding who should stop what they are doing and fix the test is a job that needs to be done.

[teknopaul]

Not saying there is no cost but...

You can happily pull master with a test fail.

Everyone has immediate visibility.

_Anyone_ can fix it: you don't have to find _who_ fixes it.

That does presume you are OK with collective responsibility for the codebase, but I have never worked without that. If you live in that world, I feel bad for you son ;)

Given collective responsibility : If the same issue is on a branch its still there, its hidden and lives longer.

In my experience the _faster_ you find issues the cheaper they are to fix.

If the commiter is not there, and the issue is on a branch, its the same concern when someone _else_ has to merge the branch to develop. Its just been sat there longer. It likely did not show up in CI tools so fast. You came across it out of context.

If you insist one dev per branch and that dev merges, thats playing blame games. I don't find that helps team interactions. I find it better to write your code and your bugs together and fix them in plain sight.

We all know breakage is inconvenient so we all try not to do it on branches or trunk.

[maccard]

> You can happily pull master with a test fail.

No, you can sometimes pull master with a test fail and knowing which tests are ok to fail is a skill in itself.

> That does presume you are OK with collective responsibility for the codebase

That only works on small projects and on "simpler" projects. On my last project with 100+ developers it was likely that a bunch of the failures could only be fixed by 1-2 people. Asking a tools programmer to fix a failing networking test, or a gameplay/network programmer to fix a material bug is a stupid waste lf time.

> If you insist one dev per branch and that dev merges, thats playing blame games

That's a strawman. Nobody is talking about one dev branch per person except you. There are other branching models (git flow, task branches or even feature branches) with well defined criteria for merging back to main available that allow for multiple team members and stability in main.

> We all know breakage is inconvenient so we all try not to do it on branches or trunk.

This is a very naive view and is the equivalent of "just make sure it works before you submit", and doesn't scale into even tens of developers working on a project in my experience.

[alkonaut]

> _Anyone_ can fix it: you don't have to find _who_ fixes it.

You can always "fix" the broken test by reverting the offending commit. But again, if someone has already committed on it, your history will be a mess. Actually fixing something takes developer B longer than it will take the dev who knows the context. So switching that responsibility - unless it's a typo - would be a massive waste of time. A nice "collective responsibility" perhaps, but a huge waste of time.

> That does presume you are OK with collective responsibility for the codebase, but I have never worked without that. If you live in that world, I feel bad for you son ;)

I do like having collective responsibility. But one of the most important responsibilities is having a clean history, a buildable branch to start from etc. "Fixing other people's typos" is a nice team excercise but it's pretty far down on my list of collective responsibilities.

> If the same issue is on a branch its still there, its hidden and lives longer.

Test failures when we did commit-to-master lived for days or weeks. Working with PR's doesn't slow me down at all. It's not like feature branches have to live for days. They can live 20 minutes. Of course, if you have a 1.5h CI and then wait for a code review, then it's going to be a few hours, but I wouldn't want to go back to churning on master with 30 others. I did that for 15 years before. With all kinds of teams.

> If you insist one dev per branch and that dev merges, thats playing blame games.

I don't care who merges. And whether the dev merges their own code or whether code review is required is a tangential question. The more important point is that the branch lets build+test be done while the dev does something else, and that the target branch is green in the meeantime. Again, if you can build+test in minutes, then perhaps doing master dev is fine because you can all just agree that "Team, let's try to compile and run all tests before committing to master ok thanks". But if you have a lenghty CI then what? Do you hope every dev runs the 3 hour test suite before committing? That also sounds like a massive waste of time where the developer could be working on the next thing already.