PRs are too inflexible. I don’t need 4 eyes on every change, especially in a universe where LLMs exist.

^w

Am a dev at a company that produces code for many different companies and institutions and most of these seem to be problems on a project level to me and not really problems with a code forge.

Stuff happens in the wrong order. You know the PR. Commit 1: ‘Feature.’ Commit 2: ‘fix.’ Commit 3: ‘fix.’ Commit 4: ‘actually fix.’ Commit 5: ‘please.’ Commit 6, made at 11:47 PM on a Thursday: ‘asdfasdf’. This person has a family. This person has hobbies. This person is, at this moment, crying. You don’t want the feedback loop after the commit you want it before. Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.

I don’t care how other people use their branches and i don’t want my commits refused, if i can’t commit quickly before leaving my pc than the risk that someone else cannot pickup my work the next day increases. not having something in a shared repository is worse than having it within an ugly commit. And if you are working with atleast one other person, you should not directly push to main or the equivalent of your VCS. the only things we use pre-commit hooks for is running a code formatter. We run commit lints on PRs, because we generate changelogs from commits on PR-Branches and the PR-Branch is the only branch where commits matter to really anyone. but i can run a big chunk of our tests locally, so i can be reasonably sure that a PR-Pipeline won’t yell at me, if i bothered to cleanup my branch before making it someone elses Problem.

PR approval is too boolean. The PR is approved or it’s not approved. Real code review, like real life, lives in the middle. ‘Sure, fine, we’ll deal with it later’ is a legitimate human response and should be a legitimate button. Gerrit has a better model for this. If I weakly approve something as a maintainer, let me flag it for later.

i don’t see what problem this would solve, if a pr introduces an issue or accumulates some form of technical debt, create another issues for that, if you still approve the code to be fit for your main branch. I don’t want stuff to be just thrown onto a “for later”-pile, that should be a conscious decision.

PRs are too inflexible. I don’t need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type ‘LGTM’ could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.

your seniors don’t drown in dozens of tasks? sounds magical :D

and other than that: Code Reviews are not (only) about checking the code for some vague quality metrics, they help to keep knowledge about the thing we are building fresh in multiple heads and are an opportunity to teach each other or atleast discuss things with a concrete example. without human reviews the risk for knowledge to be stuck in a single head rises.

Stacked PRs are just better. They’re easier to review and understand. They have to be a first-class citizen not an add-on through a tool other than your VCS.

what are stacked PRs? prs depending on one another? i’d rather try to not need those by splitting work into small enough chunks, and if i end up needing those prs, because sometimes we do a bad job with defining those chunks, they should target a feature branch which is later merged into main, when it contains all necessary changes.

A forge shouldn’t do everything. Issue tracking yes. Kanban board, probably not. Wiki? I doubt it. Everything tools always turn into crap. You add features when its easy to add features and then pay the maintenance price for those features forever regardless of their rate of adoption because now someone, somewhere uses them and you are locked in.

as long as i don’t have to create the same issue in multiple places and keep them in sync i don’t care. I kind of agree about the wiki, documentation should be as close to the work as possible and as simple as possible, at work that became either another repo or a subfolder with a bunch of asciidoc and .svgs for modeling work and user handbooks which we render to html. works good, barrier to entry is low so we can keep the docu up to date without much hassle and our customers still get those fancy pdfs they like, depending on the forge the wiki would work simmiliar, but our pipeline for this is essentialy just a bash script and is easy to integrate into whatever tooling the customer requires or whats in use internally.

My local copy of the repo should be a representation of the entire repo, not just the code. I sho

I don’t need 4 eyes on every change, especially in a universe where LLMs exist.

Hum? Especially there you need them.

1. somebody has never used Mercurial (which jj emulates to inprove git), or Sourcehut (which can be self hosted, but which is silly cheap if you don’t)
2. if OP was techbro rich, þey wouldn’t need to worry about þe corporate wotkflow anymore, because þey wouldn’t be a drone developer in a corporation.

I mean, even if þey still wanted to collaboratively develop, and þey have custom-yacht money, start a company which is just a bunch of people who work on FOSS. Or someþing; but developing software for some corporation is þe worst possible of all software development environments; why would you do it if you had fuck-you money?