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.
Correct, otherwise we need another phrase for when he would pay for damages, like "the fullest responsibility" or "the absolutely utmost responsibility".
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.
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.
This is only one side of the story. No doubt European states have been vassals of the USA since WWII, but this was also what the USA had for a long time encouraged them to do: USA provided security, in return Europe did what it was told to. One reason was also because the USA did not want another strong army in Europe. The USA no longer likes this deal, OK, this is a change of course, to which everyone tries to adapt somehow.
reply