Linus Torvalds to kernel devs: Grow up and stop pulling all-nighters just before deadline Linux kernel boss Linus Torvalds has released the first release candidate for version 6.1 of the project and added an appeal for developers to make his life easier by adding code earlier in the development cycle. Work on each new cut of the kernel commences with a two week "merge window" during which developers are encouraged …
30+ years in development, and I've never had a failure after pulling a 1-nighter the evening before release.....
</sarcasm>
In dev, we've all done it at least once, or we've put in a simple non-destructive tweak overnight - without telling someone - and then paid the price the following day/week.
If we've done it more than once it's because of the following options
1. we're never involved in cleaning up the mess it leaves behind.
2. we're brain-dead and never learn.
3. we like like self-flagellation
4. the day job is usually boring, so let's disrupt the system, for shits and giggles/entertainment/something interesting to do.
At one place I worked at, the team rule was that Friday afternoon fixes were never rolled out until the following Monday.
I got to hone some of my Linux skills by making a "simple" change to my personal Linux systems before going to bed. Two hours later, I'd still be unpicking the fallout from the "simple" change.
Good policy! I think every single time on my recent projects when I was like "Oh, it's a 1-line change, and simple, I'll just put it in" and skip doing any testing, I've manage to have a typo in the single line of code -- and when I didn't, Python decided I was mixing tabs and spaces!!! (Idle has that thing to fix this, either switch to all tabs or all spaces. I'm not sure why this comes up since I *always* use tabs, i.e. what is deciding to spontaneously turn some tabs back into spaces. But OK...)
That is a good rule - one my current supervisor implemented, too. Actually, changes are discouraged on Mondays, too, because he figured people are not always on their best on a Monday. (No, not the worse for alcohol, most of us are beyond the age of drinking through the weekend ...).
This post has been deleted by its author
You have a merge window, and because you're a kernel dev you know when it's gonna start. You can submit your merge requests on (merge window start +1) or you submit your merge requests on (merge window close -1)
Which of these is going to get you the best experience out of your interaction with Mr T; he who has been known to pity the fool.
I don't think that what happens after the merge window closes is relevant to the point that Linus is making; "punctuality is the courtesy of kings" and all that.
This post has been deleted by its author
Sounds like you're reading into it as though Mr T is (already) having an apoplectic fit. That's not how I'm reading it, so we can agree to disagree about that.
He's given us fairly clear direction as to his expectations about the merge window; do it early so he has time to review code and understand the wider ramifications of it (if any). If we choose to still give him our merge requests in the way he finds disappointing (merge-window-close - 1) then we won't the best experience and shouldn't be surprised if things don't go our way.
Anyone vaguely related to a release process will have seen the pain of seeing someone commit a change on the release branch late in the day before go-live. It generally doesn't end well.
This post has been deleted by its author
"The merge window shouldn't end the day before release."
Why not? Final code is final code. Merging is the final step, all things should be taken care of prior to this "stable" merge, this is not a "testing" release.
What's ironic is that apparently if you merge on the last day then, Linus himself has to perform an all nightier. In a very real way, he's complaining about doing his job :-/. All of this might be 1 reason nobody wants his job.
It's a window, not a deadline. Which does raise a question as to what is happening during the merge window:
How the development process works
From this we see that it isn't just about submission but a timeboxed activity in which changes are assessed and merged, resulting in the production of a release candidate. Because this activity involves humans, there is a limit on the number of changes that can be merged in a single day ...
So I am inclined to agree with Linus, you have advance warning of when the merge window is going to happen, plan accordingly because it is unreasonable to expect others to put in extra effort just because you can't be bothered to be disciplined and organised.
However, perhaps, Linus does need to set a deadline for change submissions and then conduct the two week merge activity.
I'm with you on this. I'm annoyed by people who set deadlines and then complain that stuff arrives five minutes before the deadline expires. It's human nature. As a perfectionist, I get stressed before submitting and will naturally use all the time available to make sure it's perfect. (I've one more day, so I'll put it on the side today and look over it again tomorrow.) If you need more time to process it, set the deadline earlier.
And the trouble with these de facto deadlines that close before the formal deadline is that I have no idea how long you will need. Everybody is different. It can vary according to the individual who is handling the request that week/month/cycle, or even what else is going on in their life. I kind of expect it in the touchy-feely departments, but you'd expect more rigour from engineers. If you can say I can run the CPU at xGHz I expect to be able to do so. Likewise, if the deadline closes on Y, I expect to be able to submit up to Y without whining. If you need more time, make a smaller merge window.
The whole world works smoother when your expectations are is in black and white and I don't have to try and second guess you.
If Intel/AMD can say I can run the CPU at xGHz I expect I can run it at xGHz for a few seconds if it has been idle for the last 10 minutes, is fitted with a bigger heat sink than the one supplied and I need to wear gloves to avoid frostbite. If I complain I expect to be told that the promise applied to the model 1OIl0 I saw reviewed, not the 10lIO that was delivered.
You as a new contributor would get a pass, if anything it's almost expected. You as a regular contributor would be held to higher standards.
The message is telling you to step up your professionalism and step back from absolute deadline-oriented perfectionism, so that you get extra review time. Because unlike an essay deadline, your code is going to be reviewed throughout the RC process and you will have an opportunity to fix bugs, but preferably not rewrite the entire thing from scratch to solve an undiscovered problem. (That's a push to next release.)
I get it, I'm this way too, but sometimes your boss has to set appropriate expectations to manage timelines properly.
> The whole world works smoother when your expectations are is in black and white
The whole world is comprised of phenomena that we can't measure completely (uncertainty) and even if we could we couldn't calculate accurately (chaos) - and that's long before we approach as messy as biology, humans, or their works.
Computers are usually deterministic, but only because we've tried hard to make them that way ( those like Linus who spec ECC RAM try harder than others). Engineers working closer to the mud and stones have to embrace the mess unless they're still at school ("For the purposes of this exercise we shall ignore air resistance...")
This post has been deleted by its author
Your convenience store might be open from 7 in the morning till 11 at night.
But if 200 people turn up at 10:59 wanting coffee don't expect the staff not to be pissed off and some people to go thirsty.
All he's saying is that there are two weeks when we do merges and it's easier if we can use all those two weeks and not have 90% of the work arrive in the last five minutes.
This post has been deleted by its author
Followed by 13 days for him to review submissions, and if he rejects a submission in that time allow them one chance to resubmit a fixed version before the end of that 13 days (if they can't get it right with one resubmission they can wait until kernel x.n+1)
That way he can have a full two weeks to work on it, but it has it all submitted at once so he can organize it how he wants and look at changes to the same subsystems in one day instead of spread across two weeks.
" ... then I would say he still doesn't understand how to manage a project. ... "
Huh, let's see.
It's his project. He's been doing it for what? THIRTY YEARS?
Sorry. It's you that doesn't know how to "manage" a project. If the boss tells you that the project is due by close of business Friday, that means that if you wait until then, YOU ARE LATE. And the rest of the team isn't going to be happy with you.
So maybe YOU should find a different job.
This post has been deleted by its author
Have you ever used git? When you merge a branch, every commit from that branch comes in, and depending on how you do things that can be anywhere from one to a thousand commits. Linux doesn't squash commits, though individual contributors can (but mostly don't), but Torvalds is only going to review the final state of the overall commit (unless something isn't right and something distinctly interesting appears in the git log of the branch).
If most of the commits are undoing earlier commits then the end result may be a small review. Although any change with lots of reverts along the way should be a sign that close scrutiny is required.
For new code, and even if following the lots of small commits strategy, 1m41 is a crazy short time for review. Seems Linus is a "if it compiles it ships" kind of reviewer. I hope there are others doing the real reviews.
These changes have been reviewed his lieutenants. He doesn't need to (or care to) spend time on stuff that won't really affect the overall operation of the kernel. So changes to driver modules (which are the overwhelming majority) that aren't core he will probably merge without review, trusting his lieutenants. Same for very small merges that are changes to documentation/comments, or code style/cleanup type changes - he will trust his lieutenants to have looked at it and verified that's what it is and in such a case merge without review.
So he probably only spends time looking at important changes to core functionality, or where code was rewritten.
" that should have gone out the window after high school"
I'm surprised at how "Americanized" Torvalds has become to reference "high school". Although, I guess he has kids in school here, so it's part of the day-to-day vocabulary. Still, as a dumb Mercan myself, I found it an odd phrase for a Finn to use.
There's not really anything specifically American about "high school". Both "secondary school" and "high school" are commonly used in the various countries of the UK (my own school, and I think most of the schools in that district, was named as a "high school"), and the term is also used in quite a number of other countries. (Gymnasium is also a fairly common term in many parts of continental Europe, but is generally only used in the 'gym hall' sense of the word in English).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
