Nouvelles du noyau : Git et modèle de développement

Posté par Thomas Petazzoni (site web personnel) le 09 août 2005 à 00:54. Modéré par Pascal Terjan.

Étiquettes :

août

2005

LinuxFr a largement couvert l'affaire qui avait conduit à l'abandon de la version gratuite de BitKeeper par BitMover. BitKeeper était alors utilisé par les développeurs du noyau pour gérer les sources de ce dernier. Ceux-ci, autour d'un prototype développé par Linus Torvalds ont créé leur propre système de gestion des sources, adapté à leurs besoins : Git.

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 le 09 août 2005 à 08:30. Évalué à 10.

Si comme moi, vous vous posez des questions au sujet de ce "suite à la sortie d'une version du noyau" et qu'en plus vous avez la flemme d'aller y voir de plus près, alors voilà peut-être la réponse à votre question:
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 le 09 août 2005 à 09:22. Évalué à 3.
  
  Ca veut dire aussi que si le dev a une idée géniale, et qu'il met deux semaines et un jour à la développer, ben il ne pourra pas la voir arriver avant le noyau suivant, il devra attendre patiemment.
  
  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) le 09 août 2005 à 09:29. Évalué à 10.
    
    Actuellement, le rythme de sortie du noyau est d'environ un par mois ou un tous les mois et demi, donc la fonctionnalité n'attendra pas trop longtemps avant d'être intégrée.
    
    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) le 09 août 2005 à 09:37. Évalué à 10.
    
    De toutes façons, un patch n'est intégré au noyau qu'après avoir été testé un certain temps (je crois qu'un séjour dans la branche -mm est obligatoire). Donc, même si la fonctionalité était prête un jour avant la "deadline", elle ne serait pas intégrée pour autant. Les 15 jours ne correspondent pas au temps pour développer une nouvelle fonctionalité, mais au temps pour convaincre Linus d'appliquer le patch.
  - [^] # Re: Suite à la sortie d'une version du noyau...
    
    Posté par tinodeleste le 09 août 2005 à 09:39. Évalué à 10.
    
    et puis les idées géniales, c'est bien, mais quand elles sont codées avec les pieds, ca n'aide pas;
    
    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 le 16 août 2005 à 11:23. Évalué à 5.

(reprise d'un message à l'origine posté sous un journal)

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.