Depuis, le développement de cet outil a suivi son cours, s'améliorant, se voyant doté d'interfaces graphiques ou de scripts évolués. Linus Torvalds a décidé fin juillet de passer la main pour la maintenance et l'évolution de cet outil à Junio Hamano. En effet, Linus a expliqué qu'il avait « toujours dit qu'il ne voulait pas vraiment le maintenir sur le long terme ». Ceux qui s'intéressent à Git pourront lire le Kernel Hackers' Guide to git, suivre la liste de discussion, ou même consulter la toute nouvelle homepage du projet.
Par ailleurs, depuis le Kernel Summit, également couvert sur LinuxFr, Linus a décidé de modifier sensiblement le modèle de développement du noyau. Désormais, suite à la sortie d'une version du noyau, des ajouts de fonctionnalités et modifications importantes ne seront acceptés que pendant deux semaines. Au delà de ce délai, et jusqu'à la sortie de la prochaine version, le travail des développeurs sera consacré à la correction de bugs.
Enfin, toujours suite aux discussions ayant eu lieu durant le Kernel Summit, Andrew Morton, mainteneur de la branche -mm, a publié son weekly report. Dans celui-ci, il liste les grands changements qui sont intégrés pour la prochaine version du noyau, ainsi qu'une estimation de la date de sortie de ce dernier. Il doit permettre aux mainteneurs des différents sous-systèmes du noyau d'être mieux tenus au courant des évolutions en cours.
Aller plus loin
- KernelTrap: Junio Hamano New Git Maintainer (5 clics)
- KernelTrap: Git Homepage (5 clics)
- KernelTrap: 2.6.13-rc4, Improved Development Process (4 clics)
- KernelTrap: Weekly Status Summaries (3 clics)
- LinuxFr: Bilan du sommet 2005 des développeurs du noyau Linux (4 clics)
- LinuxFr: Le développement du noyau continue autour de Git (6 clics)
# Suite à la sortie d'une version du noyau...
Posté par lesensei . Évalué à 10.
Il s'agit de sortie de noyau stable, en x.y.z. Cela signifie, par exemple, qu'après la sortie du 2.6.13 (qui est imminente), les développeurs n'auront que deux semaines pour convaincre Linus d'intégrer leurs patchs dans le 2.6.14.
Donc comme le dit Linus, s'il y a des patchs que vous souhaitez voir intégrer dans la branche stable ASAP, n'oubliez pas de réveiller votre dév préféré en temps voulu...
[^] # Re: Suite à la sortie d'une version du noyau...
Posté par iznogoud . Évalué à 3.
J'aime bien l'idée dans le principe, mais dans les faits, je trouve ça assez dommage : ne risque-t-on pas de voir des développeurs proposer à droite et à gauche des patches pour inclure des fonctionnalités prévues non pour le noyau suivant, mais pour celui d'encore après ?
On avait déjà pas mal de noyaux patchés dans les distributions, cela ne risque-t-il pas de s'intensifier ?
[^] # Re: Suite à la sortie d'une version du noyau...
Posté par Thomas Petazzoni (site web personnel) . Évalué à 10.
C'est à l'époque du 2.5 que les distributions backportaient énormément de patches: le 2.5 n'était pas assez stable pour être utilisé, et le 2.4 manquaient de nombreuses fonctionnalités, en particulier en terme de support matériel.
[^] # Re: Suite à la sortie d'une version du noyau...
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
[^] # Re: Suite à la sortie d'une version du noyau...
Posté par tinodeleste . Évalué à 10.
http://kerneltrap.org/node/5528(...) Andrew Morton sur l'évolution et le traitement des bugs :
There are 60 bugs here. They're almost all post-2.6.12 regressions. Longer-term we simply have to do better than this, else we'll stabilise at a pretty buggy level. (...)
il faudrait que tout les développeurs fassent un peu plus attention à leurs bugs, vu que pas mal des bugs apparus après le 2.6.12 sont des régressions par rapport aux noyaux précédents.
# Mercurial vs. git
Posté par Antoine . Évalué à 5.
A propos de systèmes de gestion de versions, j'ai découvert Mercurial (abbrévié "hg"), un autre système de gestion de versions distribué qui bénéficie d'un format de stockage et de transmission réseau très efficace. A titre d'exemple, trois mois d'historique de la branche de Linus du noyau 2.6 ne prennent que 200 Mo (pour environ 5000 changesets), et quelques minutes à télécharger avec un ADSL 1024.
Mercurial est très intéressant car, comme Bazaar-ng, il est écrit en Python, il dispose d'à peu près les mêmes fonctions, et il semble beaucoup plus performant.
La page d'accueil de Mercurial :
http://www.selenic.com/mercurial/(...)
Une comparaison Mercurial / git / BitKeeper :
http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)
Naviguer dans le miroir sous Mercurial de Linux 2.6 (branche Linus) :
http://www.kernel.org/hg/linux-2.6/(...)
Cloner cette branche dans un repository local :
$ hg clone http://www.kernel.org/hg/linux-2.6/(...) hg-linux
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.