Le vrai point positif c'est qu'on ne sort pas à une date fixe
à tout prix même si ça n'est pas prêt du tout, qu'on est prêts
à repousser si c'est nécessaire, même si ce n'est pas un but
en soi et qu'on aime tenir les délais.
Le simple fait de se dire que "tenir les délais" soit juste un "nice to have" est déjà un souci.
Par exemple, ça a des implications assez embêtantes pour publier un magazine avec, ça pose souci pour organiser un événement à l'avance, etc. Je ne verrais pas l'ubuntu party avoir autant de monde si l'équipe d'orga n'avait pas la certitude de la date de sortie par exemple.
Et contrairement à ce qu'on peut croire, avoir des délais n'est pas incompatible avec le fait d'être volontaire. Par exemple, l'organisation d'un événement (ou d'un mariage), le fait de publier un magazine (Linux mag spécial Perl/python/bsd/etc) sont autant d'exemple de choses ou une organisation de volontaire a marché, parce que le but est claire à atteindre et parce qu'on se dit pas "c'est ok d'être en retard".
Mageia 4 a été sorti à temps, c'est bien la preuve que ç'est faisable.
Mais le fait de se dire "ça arrive, on y peut rien" est sans doute une des raisons qui fait que je ne vois pas avoir de discussions ou d'annonce d'un postmortem pour voir ce qui a causé des soucis, et comment éviter ça pour le futur.
Parce que tout le monde a internalisé que c'est une bonne chose.
Pourtant, il suffit de lire le blog pour voir qu'il y a sans doute des choses à proposer et à discuter.
Et au vue des commits qui ont suivi, le paquet n'était clairement pas prêt.
Donc pourquoi avoir choisi de pousser rpm au lieu de faire d'abord une recompilation à part, puis de pousser une fois qu'on voit que ça ne casse pas tout ?
Pourquoi rpm 4.12 n'est pas passé comme une feature de mageia vu son potentiel à tout foutre en l'air, vu que le processus est modélisé sur la base de celui de Fedora. (et rpm 4.12 est passé comme feature chez Fedora par exemple)
Ce processus implique notamment de détailler quoi faire si ça va pas si c'est pas prêt à temps et comment revenir en arrière sans filer un truc pas prêt.
Mais la partie "on a un plan de secours pour s'assurer que les délais sont tenus", c'est visiblement totalement secondaire. Le template des features parle de conteingency, mais en regardant sur https://wiki.mageia.org/en/Category:ProposedFeatureMageia5
J'ai trouvé 5 features avec un plan de secours.
Sur un total de 21, c'est quand même assez peu. Et encore, aucune n'a de critère d'activation du plan de secours et je parle même pas du planning, qui est visiblement un peu pris à la légère.
Donc oui, la communauté se dit que c'est pas important de tenir les délais et que personne fait rien pour permettre de les tenir.
Un autre example, les mises à jours avec urpmi vont toujours de l'avant donc du coup, une fois qu'un truc est poussé, c'est dur de revenir en arrière dans Cauldron. Il faut mettre un tag epoch, et c'est "moche", et parfois pose des emmerdes.
Mais il est possible de faire des downgrades avec rpm (yum le fait depuis des années). Donc il suffirait juste de dire à urpmi que si le paquet est plus récent sur les dépots, on mets à jour, et si il est plus vieux, on rétrograde pour Cauldron. Et une fois en freeze, on reviens au mode normal avec mise à jour uniquement, mais plus grand contrôle de ce qui rentre.
[^] # Re: patapay
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Mageia 5, la magie continue !. Évalué à 10.
Pas vraiment, il a juste suivi ce qui est dit sur le blog:
https://blog.mageia.org/fr/2015/06/20/mageia-5-brille-dans-firmament-libre/
Le simple fait de se dire que "tenir les délais" soit juste un "nice to have" est déjà un souci.
Par exemple, ça a des implications assez embêtantes pour publier un magazine avec, ça pose souci pour organiser un événement à l'avance, etc. Je ne verrais pas l'ubuntu party avoir autant de monde si l'équipe d'orga n'avait pas la certitude de la date de sortie par exemple.
Et contrairement à ce qu'on peut croire, avoir des délais n'est pas incompatible avec le fait d'être volontaire. Par exemple, l'organisation d'un événement (ou d'un mariage), le fait de publier un magazine (Linux mag spécial Perl/python/bsd/etc) sont autant d'exemple de choses ou une organisation de volontaire a marché, parce que le but est claire à atteindre et parce qu'on se dit pas "c'est ok d'être en retard".
Mageia 4 a été sorti à temps, c'est bien la preuve que ç'est faisable.
Mais le fait de se dire "ça arrive, on y peut rien" est sans doute une des raisons qui fait que je ne vois pas avoir de discussions ou d'annonce d'un postmortem pour voir ce qui a causé des soucis, et comment éviter ça pour le futur.
Parce que tout le monde a internalisé que c'est une bonne chose.
Pourtant, il suffit de lire le blog pour voir qu'il y a sans doute des choses à proposer et à discuter.
Par exemple, rpm 4.12 a causé des soucis au point de casser tout et de repousser le beta de facile un mois, voir plus, cf https://blog.mageia.org/fr/2014/11/12/une-longue-route/.
Il faut bien voir que si on suit le planning, le version freeze était le 9 septembre (https://wiki.mageia.org/en/Mageia_5_Development).
Rpm 4.12 est sorti le 16 septembre
(http://lwn.net/Articles/612037/).
Le premier paquet de rpm 4.12 a été poussé le 6 septembre :
http://sophie.zarb.org/distrib/Mageia/cauldron/x86_64/media/core-release/by-pkgid/9928e5fe5f5197e4234939cd11929c8f/changelog
Et au vue des commits qui ont suivi, le paquet n'était clairement pas prêt.
Donc pourquoi avoir choisi de pousser rpm au lieu de faire d'abord une recompilation à part, puis de pousser une fois qu'on voit que ça ne casse pas tout ?
Pourquoi rpm 4.12 n'est pas passé comme une feature de mageia vu son potentiel à tout foutre en l'air, vu que le processus est modélisé sur la base de celui de Fedora. (et rpm 4.12 est passé comme feature chez Fedora par exemple)
Ce processus implique notamment de détailler quoi faire si ça va pas si c'est pas prêt à temps et comment revenir en arrière sans filer un truc pas prêt.
Mais la partie "on a un plan de secours pour s'assurer que les délais sont tenus", c'est visiblement totalement secondaire. Le template des features parle de conteingency, mais en regardant sur https://wiki.mageia.org/en/Category:ProposedFeatureMageia5
J'ai trouvé 5 features avec un plan de secours.
Sur un total de 21, c'est quand même assez peu. Et encore, aucune n'a de critère d'activation du plan de secours et je parle même pas du planning, qui est visiblement un peu pris à la légère.
Donc oui, la communauté se dit que c'est pas important de tenir les délais et que personne fait rien pour permettre de les tenir.
Un autre example, les mises à jours avec urpmi vont toujours de l'avant donc du coup, une fois qu'un truc est poussé, c'est dur de revenir en arrière dans Cauldron. Il faut mettre un tag epoch, et c'est "moche", et parfois pose des emmerdes.
Mais il est possible de faire des downgrades avec rpm (yum le fait depuis des années). Donc il suffirait juste de dire à urpmi que si le paquet est plus récent sur les dépots, on mets à jour, et si il est plus vieux, on rétrograde pour Cauldron. Et une fois en freeze, on reviens au mode normal avec mise à jour uniquement, mais plus grand contrôle de ce qui rentre.
Mais personne ne bosse sur ça ou ne propose ça.