Code is Law

> So, what can you do?

A new service manager for Linux distributions. The last piece of a full alternative to systemd. https://skarnet.com/projects/service-manager.html. This is a proof of concept, it does not yet have its final form.

That should be no problem: he posted exactly *because* he meant to take full responsibility for his actions.

Correct, otherwise we need another phrase for when he would pay for damages, like "the fullest responsibility" or "the absolutely utmost responsibility".

"Real full" or "actual full responsibility", which then points to the original as "not full".

I must congratulate you.

An innovative approach. And by submitting a PR on Friday afternoon, you might get a free hand to do anything you like!

or 30k lines of slop every 5 minutes, nights and weekends included

> Much of the time the person I’m waiting on doesn’t report to my manager anyway

But there exists a manager who is the nearest common ancestor of your and their manager.

Sometimes that’s the CEO, but sure.

This doesn’t change much though. If there is a general problem, it’s likely appropriate to pull in management to figure out the issue. But it’s probably not a management problem that my specific PR needs a review.

It's literally the most management problem imaginable.

Management decides the process, management decides who to hire, management assigns the roles and management decides how urgent the work is.

If the constellation is so that reviews are required, but the reviewer is not under the control by the manager and reviews do not happen, then some manager somewhere made a mistake.

Why? Because PRs are expected to be reviewed. Any process in which that does not work automatically is dysfunctional and needs to be fixed until PRs are being reviewed properly again.

If everything is working as intended, but it's the manager who created a false sense of urgency and pushed all of the responsibility onto the person who cannot do anything about that, then the only person who can fix the problem is the manager and the thing he has to do is something very easy: be more patient.

Edit: It might not be obvious, but all the things you claim that strengthen your position are already table stakes and assumed to happen regardless. The question is, who is responsible for making the invisible and automatic happen? And you're saying the manager can shirk his responsibility onto the blocked employee, which is hilarious because it means your entire operational strategy for fixing a broken process relies purely on being lucky.

Another thing that might not be obvious but if you write a bad pull request and the reviewer tells you it is bad and can't be merged that's on you as well, no shit Sherlock.

> Management decides the process, management decides who to hire, management assigns the roles and management decides how urgent the work is.

Also, management decides whom to blame. :)

what is "build call"?

Fair question. It might be internal jargon. Refers to making a go/no-go “call” on the quality/readiness of a new build.

e.g. A new release candidate is built and tested from a commit. Some tests fail and each test failure is blocking unless the product area owner (or test owner) attests that the issue is not a blocker (test flakiness, test environment specific issue, extremely low priority bug, etc). The build can release only when all test blockers are closed out.

Most build call processes I’ve seen burn more time investigating flaky tests than real issues and the person running build call (often the “release driver”) typically wastes significant time flogging people to close out the same flaky bugs from the last build. I strongly recommend not building one if you can avoid it.

I notice that you have answered in considerably less time than the duration of the video.

I almost always watch things on 2x.

But it would be hard to keep up with a country which has grown its GDP by 50 times since 1990, like China did.