RedHat de profiter du capital de notoriété de la distribution CentOS, acquise au fil des années, et en se reposant clairement sur la confusion que leur décision engendrerait inévitablement
Je me permet quand même de nuancer un peu le propos. RH a embauché les 4 plus gros contributeurs de Centos en 2014, a payé pour les serveurs (une partie, voir une grosse partie dans un DC dont je suis responsable ), les locaux pour divers événements avec au moins une personne a temps plein sur la gestion de communauté. Donc je pense que "se reposer" est une vision relativement déconnecté des faits sur ce qui s'est passé depuis 10 ans. De plus, nié que le succés de Centos est du aussi au travail des ingés RH me parait un raccourci rapide.
Surtout quand on garde en tête le fait que le projet Centos n'allait pas vraiment bien à l'époque de Centos 6 (voir les durées pour recompiler les versions), alors qu'avoir des gens à temps plein a permis de corriger ça. Vu que le but n'était que de recompiler l'existant, ça a pas mal limité l'implication des gens sur le long terme, vu que tu peux rien changer.
À un moment donné RH s’est rendu compte qu’un certains nombre d’entités (déjà client ou client potentiel) montaient leur truc sur du CentOS, mais qu’une fois le truc validé, il y avait un financier pour suggérer que le risque de ne pas avoir de support était sensiblement inférieur au risque de migrer le truc. Que ça marchait plutôt bien. Et là ! L’idée, mais alors L’IDÉE!! de RH, on va transformer CentOS en une sorte de « preview » de notre next version ! }
Comme je l'ai dit si souvent, ce n'est pas du tout ça. On (RH, je bosse dans l'équipe en charge des questions opensource depuis 10 ans) a vu des gens qui sont venus pour demander des changements sur Centos (par exemple, facebook/meta pour ne nommer que le plus gros dont je puisse parler publiquement, cf leur talk) et la réponse a toujours été "faut aller voir les équipes de RHEL, on est qu'un rebuild sans modif". Puis ensuite, les gens vont voir les équipes de RHEL qui ont comme réponse "non, c'est pas le process, les features sont décidés via le product management avant qu'on sorte la distro, faut voir avec le support". Et le support qui dit "oui, c'est quoi votre numéro client".
Autant dire que c'est pas idéal quand tu proposes un patch ou une modif.
Vu que je suis interne, je peux directement pinguer les ingés, et j'ai bien vu comment rajouter 2 lignes dans usb ID (support des yubikeys 4) a pris plus de 6 mois (avec escalade interne auprès de l'équipe sécu), alors que faire pareil sur Fedora, ça m'a pris 2 semaines pour être dispo sur mon pc. L'orga mise en place avant rendait toute contribution et toute collaboration quasiment impossible, ce qui était un souci.
Donc la solution trouvé, c'est finalement de transformer le pipeline Fedora => (flou interne) => beta RHEL => RHEL => Centos en pipeline "Fedora => Centos Stream => RHEL => Centos", puis de ne garder que Centos Stream, car maintenir 4 versions, c’était beaucoup trop.
C’est ça, il ya maintenant de nombreuses années qui a poussé certaines personnes à créer « CentOS », une distribution dite « binairement compatible » avec RHEL
Binairement compatible ne veut rien dire, d'autant plus sur Linux qui n'a pas d'ABI. C'est pas Solaris ou Windows.
[^] # Re: Tout dépend du point de vue ...
Posté par Misc (site web personnel) . En réponse au journal Les distro pionnières, en recul?. Évalué à 10.
Je me permet quand même de nuancer un peu le propos. RH a embauché les 4 plus gros contributeurs de Centos en 2014, a payé pour les serveurs (une partie, voir une grosse partie dans un DC dont je suis responsable ), les locaux pour divers événements avec au moins une personne a temps plein sur la gestion de communauté. Donc je pense que "se reposer" est une vision relativement déconnecté des faits sur ce qui s'est passé depuis 10 ans. De plus, nié que le succés de Centos est du aussi au travail des ingés RH me parait un raccourci rapide.
Surtout quand on garde en tête le fait que le projet Centos n'allait pas vraiment bien à l'époque de Centos 6 (voir les durées pour recompiler les versions), alors qu'avoir des gens à temps plein a permis de corriger ça. Vu que le but n'était que de recompiler l'existant, ça a pas mal limité l'implication des gens sur le long terme, vu que tu peux rien changer.
Comme je l'ai dit si souvent, ce n'est pas du tout ça. On (RH, je bosse dans l'équipe en charge des questions opensource depuis 10 ans) a vu des gens qui sont venus pour demander des changements sur Centos (par exemple, facebook/meta pour ne nommer que le plus gros dont je puisse parler publiquement, cf leur talk) et la réponse a toujours été "faut aller voir les équipes de RHEL, on est qu'un rebuild sans modif". Puis ensuite, les gens vont voir les équipes de RHEL qui ont comme réponse "non, c'est pas le process, les features sont décidés via le product management avant qu'on sorte la distro, faut voir avec le support". Et le support qui dit "oui, c'est quoi votre numéro client".
Autant dire que c'est pas idéal quand tu proposes un patch ou une modif.
Vu que je suis interne, je peux directement pinguer les ingés, et j'ai bien vu comment rajouter 2 lignes dans usb ID (support des yubikeys 4) a pris plus de 6 mois (avec escalade interne auprès de l'équipe sécu), alors que faire pareil sur Fedora, ça m'a pris 2 semaines pour être dispo sur mon pc. L'orga mise en place avant rendait toute contribution et toute collaboration quasiment impossible, ce qui était un souci.
Donc la solution trouvé, c'est finalement de transformer le pipeline Fedora => (flou interne) => beta RHEL => RHEL => Centos en pipeline "Fedora => Centos Stream => RHEL => Centos", puis de ne garder que Centos Stream, car maintenir 4 versions, c’était beaucoup trop.
Binairement compatible ne veut rien dire, d'autant plus sur Linux qui n'a pas d'ABI. C'est pas Solaris ou Windows.