Linus Torvalds stops signing Linux kernel RC tarballs
Linus Torvalds, Founder of Linux foundation who has the reputation of overseeing all the releases and editions of Linux and lashing out at those who doesn’ t meet his standards has stopped signing the latest Linux kernel tarballs.
He has released the Linux 4.12 a day early from mother’ s day. “ So I' m doing this one day early, because I don' t like last-minute pull requests during the merge window anyway, and tomorrow is mother' s day, so I may end up being roped into various happenings,” Torvalds wrote on the Linux Kernel Mailing List.
The release is dominated by new AMD Vega 10 header files that have all the register definitions and the new Intel Atom IPU driver. He also adds that this release will contain more drivers, arch updates, documentation and misc. It also contains the USB-C manager, Budget Fair Queuing and Kyber I/O scheduler, which will speed up the I/O, storage and memory on Intel CPUs.
This release also marks the end of line for Linux on Atmel’ s AV32 RISC silicon. Torvalds also informs the users that he hasn’ t uploaded any diffs or tar-balls for this rc, because they should be automatically generated by kernel.org for the rc’ s and if any user really needs to sign by key, they can get the repo via Git and check the tags.
It would seem like a small change in this release but one has to aware of the security concerns around it.
Ensure the patch does not have trailing control-M characters on each line. A number of broken tools used to encode patches add control-M for "DOS compatibility". This breaks many versions of patch, so be sure to configure your tools properly, or use unbroken tools, otherwise your patch will be silently deleted.
Include the patch inline in your email, in plain text. Do not post it as a base64 MIME attachment. Many people will not be able to read your patch, and thus your patch will be deleted without comment.
This FAQ previously advised posting a URL to a patch if the patch is large. This is no longer recommended. The preferred way to submit a large patch is to break it up into logical chunks, with a descriptive comment for each, and post each piece with a subject line like
"[PATCH] cleanup of foo driver [1/5]".
Do not start a new thread for each chunk - rather, post each chunk as a followup to the previous chunk. You may want to begin with an explanatory post, and label it something like
"[PATCH] cleanup of foo driver [0/5]".
See Documentation/SubmittingPatches for more information.