C'est à ça qu'il sert: pouvoir tout casser, mettre du code tout neuf, puis tester avant intégration dans le noyau stable.
C'est pas tout à fait comme ça que ça se passe...
Les développements de linux, comment ça marche ? (bilan de mon observation... ; à quelques exceptions près, c'est comme ça que ça se passe)
Les développeurs travaillent sur la branche instable du noyau (x.y.z avec y impair), en partant d'une version qu'ils estiment suffisament stable de la branche stable.
Sur cette version, ils ajoutent des fonctionnalités, innovent, font des changements en profondeur (on a par exemple vu apparaitre la modularité du noyau dans le 1.3, ipchains dans le 2.1 et iptables dans le 2.3), débugguent, etc.
Si d'aventure ils découvrent un bon vieux bug tout pourri des familles qui traine dans la branche stable, ils back-portent le patch.
Une fois que les fonctionnalités sont suffisamment avancées et stabilisées, la dernière version de la branche instable devient la première de la branche stable suivante (à un patch près).
On fige les fonctionnalités, on lâche les utilisateurs dessus, qui vont apporter tous les bug-reports voire bug-fixes nécessaires.
Par ailleurs, gel des fonctionnalités ne veut pas dire gel du support matériel, on ne refuse pas l'ajout de drivers pour certains matériels (anciens pas encore supporté ou tout nouveau tout beau)
... et ainsi de suite ...
C'est pour ça que les patches 2.5.1pre1 et 2.4.16 ne comprennent pas les mêmes choses...
PS: Je te vois venir, tu vas me parler de la VM de la 2.4.
La VM de la 2.4 a souffert de sa complexité : la maintenance du code et les problèmes qui étaient rencontrés avec ont fait qu'il valait mieux en changer (et pourtant, tout le monde s'accorde pour dire qu'il y avait de bonnes idées)
[^] # Re: Juste pour dire...
Posté par Anonyme . En réponse à la dépêche Le noyau nouveau est arrivé. Évalué à 1.
C'est pas tout à fait comme ça que ça se passe...
Les développements de linux, comment ça marche ? (bilan de mon observation... ; à quelques exceptions près, c'est comme ça que ça se passe)
Les développeurs travaillent sur la branche instable du noyau (x.y.z avec y impair), en partant d'une version qu'ils estiment suffisament stable de la branche stable.
Sur cette version, ils ajoutent des fonctionnalités, innovent, font des changements en profondeur (on a par exemple vu apparaitre la modularité du noyau dans le 1.3, ipchains dans le 2.1 et iptables dans le 2.3), débugguent, etc.
Si d'aventure ils découvrent un bon vieux bug tout pourri des familles qui traine dans la branche stable, ils back-portent le patch.
Une fois que les fonctionnalités sont suffisamment avancées et stabilisées, la dernière version de la branche instable devient la première de la branche stable suivante (à un patch près).
On fige les fonctionnalités, on lâche les utilisateurs dessus, qui vont apporter tous les bug-reports voire bug-fixes nécessaires.
Par ailleurs, gel des fonctionnalités ne veut pas dire gel du support matériel, on ne refuse pas l'ajout de drivers pour certains matériels (anciens pas encore supporté ou tout nouveau tout beau)
... et ainsi de suite ...
C'est pour ça que les patches 2.5.1pre1 et 2.4.16 ne comprennent pas les mêmes choses...
PS: Je te vois venir, tu vas me parler de la VM de la 2.4.
La VM de la 2.4 a souffert de sa complexité : la maintenance du code et les problèmes qui étaient rencontrés avec ont fait qu'il valait mieux en changer (et pourtant, tout le monde s'accorde pour dire qu'il y avait de bonnes idées)