Tout ce que vous avez toujours voulu savoir sur les versions stables de Linux (1/2)

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

Everything you ever wanted to know about Linux -stable releases

(Tout ce que vous voulez savoir sur la version stable de Linux)

Rules on what kind of patches are accepted, and which ones are not, into the “-stable” tree:

Pour l'arborescence "-stable", il existe des règles pour les types de correctifs acceptés et ceux qui ne sont pas acceptables.

• It must be obviously correct and tested.
• It cannot be bigger than 100 lines, with context.
• It must fix only one thing.
• It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
• It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some “oh, that’s not good” issue. In short, something critical.

--Il doit être clairement correct et testé. ――Il ne dépasse pas 100 lignes au maximum, même si vous incluez le contexte. ――Veuillez résoudre une seule chose.

• Vous devez corriger les bogues réels qui ennuient les gens (pas le genre de "cela peut être un problème ...")
• Une solution pour générer des erreurs (mais non marquées avec CONFIG_BROKEN), des oops corrompus, des données de blocage, de vrais problèmes de sécurité ou des problèmes qui causent des problèmes "oh, ce n'est pas bon". Bref, quelque chose d'important.

• Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.

Un problème important signalé pour les utilisateurs distribuant le noyau qui résout les problèmes de performances et d'interactivité. Ces correctifs comportent évidemment un risque élevé de régression délicate et ne sont fournis que par le mainteneur du noyau de distribution, et s'il a des informations supplémentaires sur l'impact que l'utilisateur voit, il devrait inclure un lien par entrée bugzilla. il y a.

• New device IDs and quirks are also accepted.

• No “theoretical race condition” issues, unless an explanation of how the race can be exploited is also provided.

• It cannot contain any “trivial” fixes in it (spelling changes, whitespace cleanups, etc).

• It must follow the Documentation/process/submitting-patches.rst rules.

• It or an equivalent fix must already exist in Linus’ tree (upstream).

• Permet de nouveaux identifiants et bizarreries de périphériques (fonctionnalités). «Ce n'est pas une question de" condition de race théorique ". Cas où aucune explication n'est donnée sur la manière dont la course sera publiée. -Ne peut pas inclure de correctifs "triviaux" (changements d'orthographe, nettoyage de Haku Noba, etc.)

• Vous devez suivre les règles de Documentation / process / submitting-patches.rst.

• Ou des correctifs équivalents doivent déjà exister dans l'arborescence de Linus en amont.

Procedure for submitting patches to the -stable tree

• If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.rst after first checking the stable networking queue at https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= to ensure the requested patch is not already queued up.

• Security patches should not be handled (solely) by the -stable review process but should follow the procedures in Documentation/admin-guide/security-bugs.rst.

-Si le correctif se trouve dans le fichier net / et drivers / net, alors à https://patchwork.ozlabs.org/bundle/davem/stable/?series=1submitter=1state=*&q=1archive= Après avoir vérifié la file d'attente du réseau stable, reportez-vous au guide de soumission netdev stable dans Documentation / networking / netdev-FAQ.rst pour vous assurer que le correctif demandé n'est pas encore dans la file d'attente. S'il te plait donne moi.

• Les correctifs de sécurité ne sont pas gérés (seuls) par les processus de révision -stable. Vous devrez suivre les étapes décrites dans Documentation / admin-guide / security-bugs.rst.

À l'origine, il fait partie du code source du noyau Linux, il sera donc traité comme GPLv2 (reconnaissance qu'il devrait l'être).

https://www.kernel.org/doc/html/latest/index.html

Licensing documentation

The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.

https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing