Journal Des noyaux Linux LTS au début de chaque année

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
72
4
mar.
2016

Petit journal bookmark pour relayer une information que je n'ai pas vu passer ici.

Le contexte :

C'est Greg Kroah-Hartman qui est en charge de la branche -stable c'est à dire de la maintenance des noyaux après leur sortie officielle annoncée par Linus. Il patche ces noyaux avec les corrections postées sur la liste -stable et publie ces versions à peu près une fois tous les dix ou quinze jours.
Généralement il maintient ces noyaux -stable sur 5 ou 6 versions avant de les abandonner. Par exemple le 4.3.6 est la dernière version annoncée et il n'y aura plus de version 4.3.x.

Toutefois, environ une fois par an Greg sélectionne un noyau et décrète que celui-ci sera une version support à long terme (LTS) qui sera maintenu par lui pendant 2 ans.
Jusque là on ne pouvait pas savoir à l'avance le noyau que Greg allait choisir comme version LTS. C'était fait pour éviter que les gens ne se dépêchent d'envoyer leur code à moitié fini dans ce futur noyau LTS pour ne pas rater le coche.

Mais finalement il semble que ce risque soit assez faible et que les inconvénients l'emportent sur les avantages. Par exemple les distributions aimeraient bien savoir à l'avance quel noyau sera un LTS pour pouvoir en tenir compte dans leur planification de version.
Greg a donc décidé de changer de politique.

La nouveauté :

C'est Ben Hutchings (mainteneur noyau Debian) qui a communiqué l'information au sujet de cette nouvelle politique. Greg va désormais désigner le premier noyau à sortir chaque année comme étant une version LTS.
Ainsi le 4.4 qui est le premier noyau de 2016 (sorti le 10 janvier) est une version LTS. L'an prochain le premier noyau à sortir en 2017 sera une version LTS…et ainsi de suite.

Conséquence immédiate, le release team de Debian a annoncé un report de deux mois du freeze de la future version stable Stretch afin de se caler sur le noyau stable de 2017 (qui sera sans doute le 4.10).

Plus de prédictibilité et un noyau maintenu par Greg pendant deux ans ce qui va faciliter la vie de l'équipe noyau Debian.

Elle est pas belle la vie ?

  • # Une seule personne en charge ?

    Posté par  . Évalué à 10.

    Alors c'est très très bien.

    Mais je suis le seul que ça surprend qu'une seule personne suffise pour assurer une version LTS ?

    Je ne remets absolument pas en cause les compétences du personnage. Mais s'il lui arrive des bricoles, on peut dire adieu aà la LTS ou prier pour que d'autres en reprenne les commandes (mais qui) ?

    Quelqu'un aurait des infos sur ce genre de process ?

    • [^] # Re: Une seule personne en charge ?

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 05 mars 2016 à 07:57.

      Mais je suis le seul que ça surprend qu'une seule personne suffise pour assurer une version LTS ?

      Greg n'est évidemment pas seul pour maintenir ces noyaux. Il est juste en charge de :
      - Vérifier que les patchs correctifs publiés sur la liste de diffusion -stable correspondent bien aux règles édictées.
      - Intégrer ces correctifs dans le futur noyau -stable.
      - Publier ces nouvelles versions du noyau.

      Mais les correctifs eux-mêmes (donc 99,9% du travail) sont écrits par pleins de gens.
      Regarde par exemple l'annonce du 4.4.4 : http://article.gmane.org/gmane.linux.kernel.stable/168712
      Il y a des dizaines et des dizaines d'auteurs pour les patchs portés sur -stable !

      • [^] # Re: Une seule personne en charge ?

        Posté par  . Évalué à 10.

        En fait, il fait le boulot de Linus mais pour les versions stables. Donc dire qu'il maintient tout seul les lts, c'est comme dire que Linus développe tout seul ses kernels.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Une seule personne en charge ?

          Posté par  (site web personnel) . Évalué à 3.

          Mieux, Greg a plein de scripts qui automatise la majorité de son travail, et d'autres chez canonical font le même travail que lui.

          Connaissant le personnage, il a des proches qui sauront reproduire son travail !

  • # Donc un noyau LTS sur la nouvelle LTS d'Ubuntu

    Posté par  . Évalué à 5.

    Merci d'avoir partagé cette news. Je me demandais aussi comment était choisi les versions des noyaux qui sont LTS, c'est bien, cela offre un peu plus de clarté du coup !

    Et du coup, si j'ai bien compris, Ubuntu 16.04 (et ses dérivées) seront donc sur un noyau LTS (le 4.4). C'est super !

  • # hypothèse

    Posté par  . Évalué à 3.

    Mais finalement il semble que ce risque soit assez faible et que les inconvénients l'emportent sur les avantages. Par exemple les distributions aimeraient bien savoir à l'avance quel noyau sera un LTS pour pouvoir en tenir compte dans leur planification de version.

    Il y a peut-être un autre argument : les vacances de Noël. L'activité du noyau est peut-être moins forte. Les développeurs sont peut-être moins à même de mettre de nouvelles fonctionnalités.

    Ais-je tord ?

    • [^] # Re: hypothèse

      Posté par  . Évalué à 4.

      Tu as bien TORDu le cou aux mauvaises langues !
      Bref tu n'as pas tort !

    • [^] # Re: hypothèse

      Posté par  (site web personnel) . Évalué à 9.

      les vacances de Noël. L'activité du noyau est peut-être moins forte

      Linus ne fait pas sa fenêtre de merge durant les vacances de Noël et puis les stats du noyau infirment ton hypothèse (il ne semble pas y avoir de variation annuelle récurrente).
      Non je pense que la vraie explication tient plus au fait qu'il y a un véritable cerbère qui garde les portes du noyau et que les gens savent très bien que si ils essaient de refiler du code à moitié cuit à Linus ils vont se faire publiquement souffler dans les bronches.
      Et la hiérarchie des mainteneurs applique la même politique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.