Linus Torvalds Rants About Last Minute Linux Patches

It's time again for Linus Torvalds to go on another rant, it's not the first and certainly not the last time, this time it's about people submitting patches during the kernel merge window

==========Support The Channel==========

==========Resources==========

=========Video Platforms==========

==========Social Media==========

==========Credits==========
🎨 Channel Art:
Profile Picture:

#Linux #OpenSource #FOSS #LinuxDesktop #LinuxKernel #LinusTorvalds

🎵 Ending music

DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase I may receive a small commission or other compensation.

[kj_sh]

A "Priority Deadline" or a better term could work, so that if you do a PR after the Priority Deadline it CAN still be discussed during the current Merge Window (if they want to), but there's no promises that it'll make it to release since there would be a higher priority for the PRs that were made on/before the Priority Deadline.

[rhekman]

I don't know that partitioning the merge window is going to help.
I think the only solution is to start refusing late merges for patches that can survive until the next window. Perhaps make a rule that late merges are only allowed from trustworthy devs for patchsets that have lived in linux-next or other suitable staging trees for a good while.

[foxcode]

I think the merge window should only accept patch submitted before the merge windows unless it is a serious or severe security issue related patch.
The merge window is not the submission window, if it's not ready when the merge window start, it will not be ready before the window end.

[donday]

Even if it's for hobby, open source or woth other good intentions, last night finish is unhealthy both for professional and personal aspects. If its something like intel arc gpu drivers, it becomes a guaranteed crunch time, and if its for more personal projects, you are bound to have more bugs than if it were done slow and steady. Maybe the whole 6.0 thing unconsciously pressured devs?

[felipec]

The window is already split: between the merge part, and the stabilization part. If you split the merge window again, you are just shifting the problem, now people are going to submit late on the first window.

[blank-mqef]

personally in linus' position id prob give a dead line for submissions the day before the merge window and say that anything afterwards gets ignored, with room for edge cases

[wagyourtai]

A "submission window" is probably a good idea

[OcteractSG]

For a given thing to merge, it seems to have a multi-step process that it needs to go through. The logical thing to do, seeing as different actors are involved in each step, is to set a deadline for each step rather than for the whole process. As an example, if a teacher wants all papers graded by a certain date, they will determine how long it takes to grade papers and then set a deadline for the students that will allow the teacher enough time to grade the papers by the time they should be graded.

[unknownpresident]

🤔 the problem with any coder is

1. Can't code
2. Don't check their work
3. Don't beta test, 100%

Equals ... abuse

Priceless

[draconpern]

He can do deadline based on size of patch. So the larger the patch, the earlier the deadline is.

[Grhaan]

I'm currently studying university of applied sciences and people are doing one minute before submission and it annoys a lot of teachers because they cannot allocate time earlier to check the submissions. So one of the teachers actually changed the assignment return timetable for two weeks before the end of the course. Teacher knew that a lot of students will start working on the assignment 8 hours before the deadline and try to return assignments one minute before the deadline. Later during that year I heard from the teacher that it was very effective way to keep students working on the assignments based on his schedule to have proper time to check all of the assignments.

[snail]

I'm fairly certain it would be the correct solution (to split the merge window). Certainly what I would do if this started becoming a problem. This will, however, mean that people would have less time to send their pull requests, and might actually make a big mess with all the requests for a while.

[Winnetou]

Frankly, I think that not changing anything in the process is actually the best way. Splitting the window or what others said having a "Priority Deadline" or making a rule that only trustworthy devs can do late merges etc is just making the system more complex. It's slippery slope to a system where there's so many rules and regulations that you can't do anything effectively. Not to mention make it nearly impossible for new people to enter because they have to do an entire Ph. D. just to know how to contribute.

Keeping the rules simple and as few as possible and forcing the people to realise the rule intention not simply follow them ad-literam is the best way, though not immediately obvious, as it will take time to get to be common place, and I guess that you'll always have cases where people don't understand and do the wrong thing. Because, you know, there's a reason the window is 2 weeks and not 2 days. Thing is, people contributing are smart enough, they can certainly understand these things too without the need to excessive "perfect" regulation where it has to be stated extremely precise, down to the last detail. Having a more lax system is more flexible.

[brunoais]

Two windows appears to be the best option.
Pull Request window
Merge window

Commits during merge window are ONLY allowed for bugfixing of bugs that affect (estimately) 1% or more of linux users to prevent a bug from going to a complete kernel build.
After that, it's bugixing for the RC versions.

[ChristopherCobra]

We have certain deadlines (research and reporting). They are for money (and other things). They have to be submitted for approval to submit before being submitted by a hard deadline at a specific time in a specific time zone. There are no exceptions for individuals (we are one among thousands that do this). If you were in a plane wreck - well, they care, but the deadline still holds. As a result, we have other deadlines - one at 30 days out to warn folks we will be making a submission, one at two weeks out to get the most problematic parts in for review, one at 5 days out for the rest of it for approval to attempt to submit, and review of the remaining parts. And a final "dropdead" at 1 day for submitting corrections. On "day 0" (the actual deadline) we basically have to be on call and wait to see if there are any last minute snags. It seems really stupid. But the fact is, if you don't do this and enforce it there will be folks (like myself) who will make life harder for everyone by not getting it in with enough time to make the deadline. With thousands of people doing this - it would become chaos. So, I hate it - but I get it - because I am part of the problem, lol./

[Fesiug]

Splitting the merge and submission window seems reasonable

[tiagotiagot]

What's exactly the point of the "merge window" if you don't expect people to try to fit things thru the window?

[unfa]

Linus to kernel developers:

"Stop pulling my leg from the git repo"

[shayes.x]

Personally, I would waitlist all PRs submitted within the merge window, with exceptions only for maximum priority PRs. Preferably, most time extensions would be established before-hand with the approval from maintainers. This would force those causing issues to treat the submission deadline more seriously.

[wheezybackports]

If kernel code quality ends up going down I'm going to use OpenBSD instead or just try to fork the Linux kernel and fail massively.