Linus Torvalds To Kernel Devs: Grow Up and Stop Pulling All-Nighters Just Before Deadline (theregister.com) 93
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. The Register reports: "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." 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." "For all the gory details, please refer to the git tree."
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." 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." "For all the gory details, please refer to the git tree."
Something has to change (Score:3, Interesting)
If people aren't willing to budge to do things last midnight, don't tell people what the real last minute is and update the schedule accordingly. If people don't like it, they don't have to work on the project. I'm sure there are other projects they can work on that they will find interesting.
Re:Something has to change (Score:5, Insightful)
If people are making changes up to the very last minute, those changes aren't actually ready for prime time.
Re: (Score:1)
If people are making changes up to the very last minute, those changes aren't actually ready for prime time.
There's nothing making that logically true.
If I have a technical task to do that requires 8 hours of work and it needs to be done by the end of the work-week, it doesn't matter if I start and finish it Monday, or if I start and finish it Friday. In the real (non-high-school) world, deadlines aren't generally "deadlines". They're due dates. You deliver your product, service, code, or whatever by the due date. Further, most work environments deliver such very close to the due date, not significantly ear
Re: (Score:2)
Uh, no. That work you're referring to need to go through a QA cycle before final acceptance. You're being inconsiderate and arrogant if you're turning it in last minute and causing the QA people stress by making them work crunch time just because.
You've obviously never worked in any sort of manufacturing where deadlines are when the trucks leave with the finished goods and they very much are deadlines and not "due dates".
Re: (Score:2)
That work you're referring to need to go through a QA cycle before final acceptance.
If the code has to be ready at 5 pm, and QA takes two hours, then you tell the devs the deadline is 3 pm, because that IS the deadline for them.
It is dumb to tell the devs the deadline is 5 pm and then complain that they didn't turn it in two hours earlier.
You've obviously never worked in any sort of manufacturing where deadlines are when the trucks leave with the finished goods.
That is the point. The software devs and the truck drivers should have DIFFERENT DEADLINES.
Re: (Score:2)
If your QA takes two hours, and so you set a dev deadline 2 hours before the "real deadline", then anything needing remediation means you failed.
If you're talking about something like a linux kernel, everything should be in the can way before the "due date". That's developed, tested, remediated, retested, signed off and ready to ship.
I agree with Linus here. In my last major dev gig, change management rendered those sorts of behaviours verbotten.
Re: (Score:2)
If your QA takes two hours, and so you set a dev deadline 2 hours before the "real deadline", then anything needing remediation means you failed.
So that PR gets moved to the next release, right?
Re: (Score:2)
Then SLAs should be set whithin the organization.
If person A needs to get something to person B to review/approve/test/etc before release to client than internally you should tell person A that item is DUE to person B at a time early enough person B has both an appropriate perform the work and some flexibility to accommodate other things they might have going on.
This way if person A is later from time to time person B still can crunch it out, and people outside the group don't experience a missed SLA. If pe
Re: (Score:2)
Have you worked with pull requests? These are not "technical tasks" but code changesets. There is no way to submit a changeset for review just shy of the deadline, and believe that it is adequately tested. In general, testing takes _longer_ than coding, especially when the coding is done under time pressure.
Re: (Score:3)
And, we can see how this is true from the stellar quality of software that is released into the world.
Re: (Score:2, Insightful)
If people are making changes up to the very last minute, those changes aren't actually ready for prime time.
Your statement both makes a poor (and in most cases probably incorrect) assumption and then proceeds to come to a conclusion that wouldn't be true even if your poor assumption were correct.
If people are making changes up to the very last minute
Who said anything about them making changes? If I had a deadline for a piece of code important enough to go into a kernel, I would be testing that code right up until the last minute. I would then submit it before the deadline, and if it was down to the wire to the very last second, would feel not a second's remorse for
Re: (Score:3)
You are describing a very disciplined pattern of behavior, that does not fit with the story at hand. Pulling all-nighters to make a deadline, is not an example of disciplined behavior. If you have to pull an all-nighter to make a deadline, you are by definition not ready.
Re: (Score:2)
The point is that Linus doesn't actually know if they're pulling all-nighters, or simply getting it done early but waiting until the last minute to submit in case they spot another issue.
Re: (Score:1)
The point is that Linus doesn't actually know if they're pulling all-nighters,
Plus, for much of the world, it's not even late. It's only midnight in one time zone at once. Linus has always had very self-centric thinking.
Re: (Score:2)
I didn't make up the all-nighter part, it's in the title.
Re: (Score:1)
I didn't make up the all-nighter part, it's in the title.
I didn't say you made it up. I said Linus made it up. You're just arguing for it. The "all nighter" paradigm is Linus-centric, and anyone with an understanding of time zones knows knows it has to be incorrect for half the world.
He doesn't and can't know people are doing last minute all-nighters - all he knows is the timestamp on the submission and then, because it is close to the deadline, then proceeding to make negative assumptions.
If he doesn't want people submitting close to the deadline, then move t
Re: (Score:2)
>In short, first telling people there is a deadline and then castigating them for using that time to make sure the deliverable is the best it can be is highly counter-productive.
There isn't a deadline, there is a merge window with and endpoint. And Linus is requesting that more code come in earlier in the window so there isn't a problem at the end of the window. If people think a few extra days of testing or "mak[ing] sure the the deliverable is the best it can be" is necessary during the window then I
set deadline to noon (Score:3)
Re: (Score:3)
Re: (Score:2)
set deadline to noon adjust your process and you will not get submissions 5 min before midnight
You've obviously never dealt with faculty.
Re: set deadline to noon (Score:4, Funny)
Indeed. Remember folks, the point of university is to graduate from university. Those who linger are the ones who never figured out that basic fact.
Re: set deadline to noon (Score:2)
set deadline to noon
Oh great, then an all nighter becomes 36 hours.
Think of what this would do just to the black market price of Adderall.
Re: (Score:1)
Re: (Score:2)
It's not the timing of the deadline. If the code isn't ready until the very last minute, it's really not ready at all. It's not possible to have completed all necessary testing within seconds of completing the code changes!
Why is this even a thing? (Score:3, Insightful)
New kernels come out like every day. Why would you have to crunch just for one release? Who cares, just get in the next one, or the next. Oh no, your code gets delayed by 2 days... WTF
^frost GSgwn
lts. (Score:3)
6.1 will be an LTS release. It will be supported on the long term, be the one used in the next Android, etc.
Miss that window And you'll need to wait at least one year until the next opportunity to make your feature so widespread that even Debian Stable could have it.
ADHD (Score:4, Interesting)
Re: ADHD (Score:1)
ADHD and kernel code don't seem like they'd go well together.
Re: ADHD (Score:5, Interesting)
ADHD and kernel code don't seem like they'd go well together.
I'll take "Hard Pill to Swallow for $1000, Alex". As a member of that struggling group, I have to concede that your statement seems pretty valid to me. At least in most cases.
But ADHD can also present itself as periods of intense, hyper focus too, depending on the situation. And that can certainly go well with kernel dev.
I've done my share of driver dev in the past and as long as the task is challenging enough and/or will generate enough "bro creds" afterwards due to its perceived difficulty by peers, it works very well.
But when that task *isn't* like that (and most aren't), you're pretty much forced to make it challenging by pushing up against a deadline you have no control over. Once there's "almost no way to get it done now", then it becomes challenging and the dopamine kicks in. Definitely not kernel compatible at that point, IMO.
Re: (Score:1)
Re: (Score:2)
Re:ADHD (Score:5, Insightful)
So set a hard deadline one week before the deadline of the merge window.
That's not how that works. That's not how any of this works. A self-imposed, artificial deadline does not work for those lacking self-regulation. It just doesn't. The dopamine boost that person requires cannot be produced with a deadline over which they have direct control. It has to be external. It has to be fixed. It has to be out of their control to be real. Once it's real, once it's fixed and set in stone, THEN they can get that dopamine hit by running up against it and being "forced" to crank out "whatever" in record time.
It sucks. It really does. Ask me how I know.
Yes, it's a coping mechanism. Yes it's illogical and inefficient, but for many it's the only way to participate.
Re: (Score:3)
If Linus Torvalds sets the deadline, it's not self imposed.
If Linus has a hard deadline for the stuff that he does and he is dependent on other people to get it done, he needs to set their deadline to be a few days in front of that.This is standard practice. It's not complicated.
Re: (Score:2)
If Linus Torvalds sets the deadline, it's not self imposed.
Perhaps you're reading the post I replied to differently than I did. So let's start with that.
So set a hard deadline one week before the deadline of the merge window.
IMO, he's already suggesting a self-imposed deadline here. Sure, it's based off Linus's deadline but it's an arbitrary and self-imposed offset off that. He's suggesting that you make up a new deadline that you're going to try to target yourself; it's self-imposed. To further support that opinion, OP then said:
Being deadline driven doesn't mean you need to rely on other people setting those deadlines.
So whether you interpret that previous statement the same as I did or not, OP went on to specifically s
Re: (Score:1)
Re: (Score:1)
Ah yes. And you probably also think that poor people won't be poor if they just stop trying to be poor?
We're talking about ADHD, which is a mental 'disease', where people literally can't do what you're suggesting.
"Oh, you don't have any legs, well, running a marathon will certainly solve that!"
Re: (Score:2)
> "Oh, you don't have any legs, well, running a marathon will certainly solve that!"
"Man Born Without Arms or Legs Completes Marathon"
https://www.youtube.com/watch?... [youtube.com]
I was poor when I was a kid and I didn't like it. So I decided to do things differently. You can figure out the rest, but I simply stopped being poor. It is not easy, but it has done several times and it is quite well documented process (avoid all spending as much as you can and earn as much as you can and invest it, using traditional inves
Re: (Score:2)
I have a friend like this. I give him a different deadline than everyone else.
Re: (Score:2)
I've found that a looming deadline narrows my focus and (for a short time at least) seems to grant me the ability to see with perfect clarity and all the little forks in the road I didn't know the direction to take (or even see them in the first place) my subconscious just seems to sort out, like a plow clearing me a path while I code.
For me this isn't just "being in the zone", it's more like being the ZONE of the zone.
I can't explain it, I can just recognize it for what it is. And I suppose, hope it keeps
Re:ADHD [and deadline motivation] (Score:2)
Maybe Rome was built in a day.
This isn't about All Nighters or Deadlines. (Score:3)
Re: (Score:2)
Re: (Score:2)
It's on my to-do list. Don't make me put it on my not-to-do list!
Perhaps its Linus Torvalds who needs to grow up (Score:1, Insightful)
Re: (Score:2)
Re:Perhaps its Linus Torvalds who needs to grow up (Score:4, Insightful)
There are no hard and fast rules that work for all situations in real life, nerds.
Re: (Score:3)
There are no hard and fast rules that work for all situations in real life, nerds.
Of course they are. They just can't be expressed in a single sentence. You have already placed criteria on what you think is important enough to be rushed into the same merge window.
That is a rule, and implementable.
Re: (Score:3)
Re: (Score:2)
Expert systems with your hard and fast rules have been tried before and failed miserably.
But apparently you, like all the other fauxtistic nerds on this site, think you know better than hard-earned experience.
Re: Perhaps its Linus Torvalds who needs to grow u (Score:2)
Iâ(TM)d imagine security fixes would be out of cycle? Also, all nighters are probably the worst thing for a security fix, in that you may fix the issue, but exhaustion creates another.
Hmm ... (Score:2)
call for testers to visit Linux's git tree
This made me think of something else [wikipedia.org] ...
Re: (Score:2)
I've worked for HW manufacturers in the past and they have schedules. They invest millions getting the product and SW ready, then Linus (or some other maintainer) voices late concern and POOF! Your product is now unsupported for an additional 3-4 months. Nobody likes compiling custom kernels to add device support, sometimes the only solution is to work until the absolute deadline to see if you can get it in.
It sucks, but what are you going to do?
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
If you want your code upstreamed, it doesn't matter if you think it's reviewed, tested, and ready. It needs at least two groups of maintainers to approve it outside of your control. It an be anything from naming conventions to bugs to "they just don't like your code" to get it bounced. You could have finished the code a month early, then it gets bounced at a later review.
If you think marketing is the only driving force it's obvious you'v
Re: (Score:1)
Just poor project management (Score:5, Insightful)
Just poor project management, honestly. Set a deadline for when all work must be submitted. Schedule an overlapping task to review the incoming work which extends (guessing) an additional week past the work-submission deadline to review the high-volume latecomers, which should be expected and planned for.
Re: (Score:3)
Re: (Score:3, Interesting)
Re: (Score:3)
If there is consistently not enough time for review outside of the merge window and you don't take that into account, you're doing it wrong.
Re: (Score:1)
If there is consistently not enough time for review outside of the merge window and you don't take that into account, you're doing it wrong.
I don't agree. The problem is not review, but people doing changes util just before the deadline, isn't it?
Re: (Score:2)
If you treat the merge window as development time and the end of it as a deadline, then you're doing it wrong.
And what is wrong with that?
What can be merged during the merge window is in the product.
The rest is not.
What is the problem with that?
Re: (Score:2)
Large patches need days for review and discussions, while small patches can be done within minutes. So you would close the window a week in advance to give enough time to review the large patches? That would be inefficient, as it would unnecessarily prevent small patches from being submitted late.
I like the approach of asking people to improve their level of maturity rather than leveling by the bottom. If you have a large patch, make sure you submit it at the beginning of the merge window to give plenty of
Re: (Score:2)
The merge window closes on the 29-(1.0*N)th of the month, where N is the kloc in your PR. Sorted.
Re: (Score:1)
Re: (Score:2)
I don't see any reason for Linus to have a work crunch. Why would he have a deadline for himself? After the merge window he should take as long as it takes. If 90% of the pull requests come in on Day 14, it's going to take him longer. If anybody asks, they can look at the git log and see who backloaded his work. If anybody complains that Linus is taking too long somebody can kick them in the balls.
Re: (Score:2)
He used his backup hardware, so the delay was measured in hours. I would however dearly love to see Linux give you the flame-roasting you richly deserve for your stupidity.
Re: (Score:1)
Hey, if he wants to whine about something he could've very fucking easily dealt with if he were half the hacker he wants to be (protip: the original hackers were HARDWARE hackers) then I can whine at him for being incompetent in such a manner.
Especially since the majority of his history is being an utter ass for no fucking reason.
Maybe he should schedule his (Score:2)
Re: (Score:1)
Isn't that what develop branches are for (Score:2)
compared to master branches? So you can test stuff before the big merge?
Real world to Linus Torvalds: ROTFL (Score:2)
Look who just woke up to the reality of dealing with other people and Parkinson's Law. People will always wait until the last minute to finish their work especially when it affects other people's ability to finish theirs. Tough noogies.
Linus is out of touch (Score:1)
Haha, humans (Score:2)
Haha, Torvalds thinks he can change human nature. People will ALWAYS do this. If you want to live a happy life, don't tell others what YOUR deadline is. Give them THEIR deadline.
Reminds me of a former colleague... (Score:2)
Every time he went on vacation for a week, he'd rush and merge his work to the integration branch at 7pm on Friday, just after everyone else had gone home. Invariably, it would be an oversized atomic merge containing many patches that could and should have been merged individually earlier, and invariably, it would break the build for that branch. Every fucking time.
The first time it happened his team-mates spent much of the week debugging his work to get the build working, only to be told upon his return
Re: (Score:2)
I discovered years ago it was a universally bad idea to commit any major code changes any Friday after noon. After having one Saturday ruined by such a code change, I vowed to avoid doing that again and just save merging the changes until I got back on Monday. It's not a hard and fast policy - sometimes important changes HAVE to be made, but it's actually pretty rare.
One solution is to make everyone be "on call" 24/7. But never really call anyone except the one guy who does that and the occasional teamma
Re: (Score:2)
Or set up processes such that a branch cannot be merged until certain checks pass, such as it compiles, or it passes unit tests. Then merge whenever you want.
Aren't the devs volunteers? (Score:1)
Re: (Score:2)
But then how would the beatings continue until morale improves?