Linus Torvalds to kernel devs: Grow up and stop pulling all-nighters just before deadline
- Reference: 1665989887
- News link: https://www.theregister.co.uk/2022/10/17/linux_6_1_rc1/
- Source link:
Work on each new cut of the kernel commences with a two week "merge window" during which developers are encouraged to add whatever it is they want included in the next version.
In his weekly [1]state of the kernel update Torvalds declared version 6.1 "isn't actually shaping up to be a particularly large release: we 'only' have 11.5k non-merge commits during this merge window, compared to 13.5k last time around."
[2]
He therefore rated version 6.1 "not exactly tiny, but smaller than the last few releases. At least in number of commits."
[3]
[4]
Torvalds also concurred with The Register 's [5]assessment that the arrival of Rust in the kernel will be a modest debut. He described as "the initial Rust scaffolding (no actual real Rust code in the kernel yet, but the infrastructure is there)."
The Emperor Penguin also revealed that his [6]faulty memory misadventure had a sequel of sorts.
[7]
"Let me just say that after I got my machine sorted out and caught up with the merge window, I was somewhat frustrated with various late pull requests. I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window."
He then offered further guidance on how kernel devs can do it right.
"Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not 'two weeks to hurriedly put together a branch that you send Linus on Friday of the second week'," he wrote. "The whole 'do an all-nighter to get the paper in the day before the deadline' is something that should have gone out the window after high school. Not for kernel development."
[8]Linus Torvalds's faulty memory (RAM, not wetware) slows kernel development
[9]Linux kernel 6.0 debuts, Linus Torvalds teases ‘core new things’ coming in version 6.1
[10]Linus Torvalds releases Linux 5.19 – using Asahi on an Arm-powered Mac
[11]Even robots have the right to learn from open source
[12]Open-source leaders' reputations as jerks is undeserved
His next line was: "You know who you are."
"Anyway, it's not the first time I've said this, I doubt it will be the last. But maybe more people could take it to heart, ok?" he added, before concluding his post with a slightly non-traditional call for testers to visit Linux's git tree because "The merge window may not be the biggest ever, but it's certainly big enough that the shortlog is much too big to post, and below is just my usual merge log."
[13]
"For all the gory details, please refer to the git tree." ®
Get our [14]Tech Resources
[1] https://lkml.iu.edu/hypermail/linux/kernel/2210.2/00359.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Y00nuaw-CtkjJrrap7bZWAAAANM&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y00nuaw-CtkjJrrap7bZWAAAANM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y00nuaw-CtkjJrrap7bZWAAAANM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2022/10/14/kernel_61_will_contain_fixes/
[6] https://www.theregister.com/2022/10/10/linus_torvalds_ecc_memory_fail/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Y00nuaw-CtkjJrrap7bZWAAAANM&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2022/10/10/linus_torvalds_ecc_memory_fail/
[9] https://www.theregister.com/2022/10/02/linux_kernel_6_0_released/
[10] https://www.theregister.com/2022/07/31/linux_5_19/
[11] https://www.theregister.com/2022/07/11/robots_open_source/
[12] https://www.theregister.com/2022/05/12/not_all_opensource_leaders_are/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/oses&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Y00nuaw-CtkjJrrap7bZWAAAANM&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://whitepapers.theregister.com/
It seems he understands that using technology to solve social problems is inferior to education.
It's like he actually wants the contributions, just on a reasonable schedule.
The knee-jerk "just chuck it away if it's too late" reaction is typical of the OS community but not our new Linus.
Success!!!
30+ years in development, and I've never had a failure after pulling a 1-nighter the evening before release.....
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.
Err
Isn't the point of having a merge window so people can submit whatever they like in that time, and then the people responsible for looking over those commits have time before the release to deal with them.
Or is Linus implying that the release is going to happen the day after the merge window closes? If so, then I would say he still doesn't understand how to manage a project.
Re: Err
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.
Re: Err
Then why have a two week merge window?
If you can't deal with, or are too childish to accept, people committing things towards the end of those two weeks, don't have a two week merge window. Just force people to use a one day merge window.
Either that or suck it up and accept that people will commit things within the allotted time when they are good and ready.
Re: Err
I'm with you on this to be honest. One week merge window and one week merge review window sounds like it put this to bed.
Re: Err
Well, if I was on the developer team (some hope) I would, as a matter of courtesy, regard it as one week for normal merge requests and one for "Oops! We've just found a nasty bug."
Re: Err
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.
Re: Err
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.
Re: Err
... I would say he still doesn't understand how to manage a project.
Ahh ...
And you are going to explain to Linus Torvalds just how to manage a project?
I see.
Really, do you have any idea how stupid what you have posted makes you look?
O.
I am impressed that Mr Torvalds can review around 12,000 changes over two weeks. That's 1 minute and 41 second each, if he doesn't eat or sleep and doubtless explains the remarkable quality of the Linux kernel and why it needs new versions so often.
I'm sure Linus can knock up a script to scan his emails and reject patches from people who regularly send in patches late.