Logiciel : Le noyau Linux 2.6.21 est disponible
Posté par patrick_g (page perso, ). Modéré le 26 avril 2007.
Cette version a suivi le processus de release candidate qui est maintenant bien rôdé.
- La version RC-1 est apparue deux semaines après la sortie du noyau précédent. Linus s'est félicité de la fiabilité du noyau 2.6.20 qui a facilité la transition vers cette version candidate : "It would seem that 2.6.20 has been a good base, and I don't think we have anything *really* scary here".
- La version RC-2, qui devait normalement comporter uniquement des correctifs, s'est révélée plus invasive que prévu car Linus avait oublié d'intégrer les patchs de V4L (Video for Linux). Il s'en est excusé à sa manière typique : "And yeah, it's largely my fault (...) but I'll rather blame anything else than my own incompetence, I'll just claim that all the other kernel developers have been irresponsible". En dépit de son humour corrosif, Linus s'est ensuite un peu énervé en constatant que les autres développeurs ne respectaient pas vraiment la fenêtre d'intégration des changements (merge window) et continuaient de lui envoyer des modifications lourdes après la sortie des premières versions candidates : "I'm really fed up with having to pull big changes after the merge window, because it just doesn't seem to let up. I'm going to go postal on the next maintainer who doesn't understand what "merge window" and "fixes only" means".
- Le message accompagnant la sortie de la version RC-3 a continué sur le même ton humoristique très torvaldien, puisqu'il est allé jusqu'à menacer de représailles physiques les développeurs réfractaires : "Let's keep the fixes to a minimum, especially since I'm planning on biting peoples heads off if I get any more pull requests for things that aren't real and obvious fixes".
- Ces terribles menaces ont manifestement effrayé les développeurs du noyau puisque les versions RC-4 et RC-5 se sont contentées de résoudre les bugs existants et de corriger les régressions. Linus a félicité Thomas Gleixner d'avoir traqué avec obstination (like a weasel on a dead rat) un problème affectant le code des timers haute résolution.
- Les deux dernières versions candidates (la RC-6 du cinq avril et la RC-7 du quinze avril) n'ont fait que proposer des corrections de bugs, traquer les régressions et améliorer encore plus la stabilisation du noyau.
![[en]](../images/en.png)
Résumé complet des nouveautés (1621 hits)-
Les ajouts de la période d'intégration 1 (175 hits)
-
Les ajouts de la période d'intégration 2 (154 hits)
> Lire la dépêche (59 commentaires, moyenne: 3,9).
Vous avez demandé le commentaire #825919.
Run by 
Cette page a été générée par Templeet en 0.0467s (dont 0.0051 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
L'API de KVM n'est pas figée
l'API KVM présente dans le noyau 2.6.21 est maintenant figée
À noter que l'API de KVM n'est pas figée, Linus ayant refusé certains patches arrivés trop tard. Il est donc prévu de la figer pour le 2.6.22.
ce qui est le signe que le code est considéré comme mature
Je trouve également bizarre le fait de dire que lorsque l'API est figée, le code est considéré comme mature. Certes c'est une étape importante, mais cela ne veut rien dire sur la maturité du code.
À l'extrême, on peut tout à fait définir une API, la figer, mais ne pas avoir écrit une seule ligne de code.
[^]Re: L'API de KVM n'est pas figée
J'ai en fait tenu compte de l'article ici : http://lwn.net/Articles/223839/
On peut y lire ceci (c'est moi qui souligne) :
"The other feature of note is the announced plan to freeze the KVM interface for 2.6.21. This interface has been evolving quickly, despite the fact that it is a user-space API; this flexibility has been allowed because KVM is new, experimental, and has no real user base yet. The freezing of the API suggests that the KVM developers think things are reaching a stable point where KVM can be put to work in production systems."
[^]Re: L'API de KVM n'est pas figée
Hum, je suis pas sûr de comprendre ... : parce que c'est écrit en anglais donc ca a plus de valeur ? chez LWN y'a que des kadors plus forts que DLFP qui parlent donc on discute pas ?
D'autant plus qu'il y a une énorme différence entre le texte en anglais et ta version : en gros c'est comme si tu avais traduit "suggets" par "c'est un signe" alors que tout au plus "suggest" peut se traduire (dans ce contexte) par "laisser penser" ou "peut faire penser", ce qui donne au final :
« ce qui peut faire penser que le code est considéré comme mature »
La formule est moins élégante, mais elle n'aurait fait tiquer personne :)
[^]Re: L'API de KVM n'est pas figée
>>> chez LWN y'a que des kadors plus forts que DLFP qui parlent donc on discute pas ?
Heuuu....C'est Jonathan Corbet qui a écrit l'article alors oui je pense qu'il est largement au-dessus de la moyenne.
Pour info j'ai retrouvé ce compte-rendu de conférence (écrit par Thomas Petazzoni) qui montre bien la dimension du bonhomme et sa hauteur de vue générale sur le noyau Linux : http://thomas.enix.org/OttawaLinuxSymposiumJour1
Quand à ta traduction elle est effectivement plus fidèle que la mienne et rend mieux compte de la réalité.