Comme dit dans un billet précédent, les gens sont repartis au boulot, concentrés sur la sortie de Mageia 3. Il est donc temps de définir les spécificités de la prochaine mouture. Nous avons alors pensé qu’il était temps d’améliorer le processus utilisé pour Mageia 2 :
- la liste des spécifications soumises était très longue et nous n’avons pu en mettre en œuvre que seulement quelque-unes,
- des tas d’idées soumises étaient simplement indéfinies ou manquaient d’informations,
- quelques spécifications soumises n’étaient pas réellement des spécifications, comme la « mise à jour vers la version x » de paquets mineurs,
- nous avions une sorte de catalogue d’articles sans logique,
- et plusieurs d’entre eux étaient proposés sans la moindre ressource.
Nous avons donc décidé d’instaurer un processus différent afin d’améliorer les choses. Nous avons d’abord jeté un coup d’œil sur les autres distributions pour voir comment c’était géré. Nous avons été finalement inspirés par Fedora.
Mageia a donc désormais sa propre politique de fonctionnalités. Cette politique définit qu’est-ce qu’une fonctionnalité, comment elle peut être proposée, et quels critères sont utilisés pour choisir celles qui deviendront officielles pour les versions suivantes.
La procédure est la suivante :
- rédaction des propositions pour Mageia 3 après avoir lu le mode opératoire. Il fallait utiliser un modèle pour les formaliser,
- toutes les propositions ont ensuite été lues et triées. Les contributeurs ont si nécessaire été questionnés pour les compléter ou pour en discuter sur la liste de diffusion mageia-dev,
- le choix final fut réalisé.
Au final, nous proposons une liste divisée en 4 types de fonctionnalités :
- fonctionnalités acceptées : dont la description est maintenant complète et qui seront suivies en réunion d’équipe,
- fonctionnalités en attente : elles seront peut-être introduites, mais pour l’instant nous manquons d’informations sur les ressources,
- fonctionnalités à détailler : elles doivent être complétées,
- fonctionnalités refusées : refusées pour diverses raisons : discussions déjà en cours, fonctionnalités en double, …
Nous verrons les premiers résultats de l’implémentation de ces fonctionnalités dans la première édition alpha, prévue pour le 4 septembre !
