Une seconde journée au Flock, également bien remplie !

Gnome-Software

Dans sa présentation, Richard Hughes réalise une présentation de PackageKit dans la résolution des dépendances et son fonctionnement interne.
Historiquement, PackageKit contenait une interface contenant des catégories et déduisait du contenu du fichier, puis se chargeait de l’installation, mais finalement tout ça a été abandonné car trop compliqué et non maintenable. Le choix a été de refondre l’interface pour la rendre plus simple et compréhensible : c’est la naissance de gnome-software (appelé Logiciels en français).

Celui-ci ne se charge plus du tout d’essayer de se charger des dépendances mais en s’appuie sur le gestionnaire de paquets local. En termes de mise en page, Richard s’appuie complètement sur l’équipe design de GNOME. Ces deux appuis lui permettent de se focaliser sur la pertinence des résultats et l’ajout de nouvelles fonctionnalités.
Pour éviter d’avoir à réinventer les descriptions de chaque paquet et de devoir produire des descriptions pour chaque logiciel, Richard travaillé à la normalisation des logiciels entre les distributions. C’est là que le fichier AppData arrive, qui petit à petit devient de plus en plus riche et précis avec le temps, avec un côté gagnant-gagnant, plus le fichier est complet, plus l’application est mise en avant !

En complément, pour obtenir des retours des utilisateurs, un mécanisme de collecte des retours utilisateurs a été construit : Open Desktop Review System.

Il faut que ce dernier permette à n’importe quelle personne d’écrire un commentaire et donner une note au logiciel, sans imposer de connexion et modéré par le signalement de la communauté. Pour trouver que garder et que jeter, l’algorithme utilisait initialement les statistiques d’Amazon pour modérer les résultats : globalement 5 revues négatives pour une positive, étrangement, dans la communauté Linux, le ratio est plutôt l’inverse : 3 positives pour 1 négative.
Ce seuil permet de choisir à quel moment ne plus afficher un commentaire. Les commentaires qu’on voit peuvent venir de n’importe quel OS et pour n’importe quelle version du logiciel pour l’instant. Cependant, une fois le volume suffisant, des filtres ou mises en priorité permettront d’être un peu plus restreints.
Les revues peuvent être écrites dans n’importe quelle langue et sont affichés en priorité pour l’utilisateur parlant cette langue.

Ubuntu a migré à Gnome-Software faute de capacité à maintenir leur plate-forme logicielle. Ils utilisent également les fichiers AppData quand ils existent au niveau des projets source. La seule différence c’est qu’ils veulent utiliser un fichier YAML et non XML.

Richard est ensuite revenu sur le grand travail sur Fedora 23, consistant à rétro-porter les fonctionnalités de la future version de Gnome pour permettre la montée de version Fedora 23 vers Fedora 24 via Logiciels. Dans les travaux en cours, on peut notamment citer :

• La prise en charge plus complète des Flatpack, qui permettent également de restreindre les logiciels dans un bac à sable. Richard a indiqué que plus le logiciel est contraint/contrôlé, plus un petit bouclier qui est présent en dessous du nom du paquet sera rempli.
• La licence logicielle sera également mise en avant afin d’indiquer si le logiciel est libre ou non. Une plate-forme de mise à disposition de Flatpak multi projets est en cours d’implémentation, pour faciliter la diffusion.

J’ai posé une question sur la redondance entre le contenu de ces fichiers et les fichiers inclus dans RPM et DEB ?

• appstream-util permettrait de limiter la redondance et de générer à partir du fichier AppData le nécessaire dans les fichiers RPM et DEB.

Les impressions d’écran peuvent-elles être traduites pour offrir des images contenant du texte français ?

• apparemment c’est possible en modifiant simplement le fichier en mettant un « _ » devant le nom balise ( devient <_image>).

Factory 2.0

Présentation par Ralph Bean (threebean), qui va nous parler d’automatisation, mais il parlera à un rythme effréné et peu fort. On parle ici de l’accélération de la demande et de l’évolution du développement, de la nécessité d⁽être capable de suivre.

Factory 2.0 n’est pas un site internet, pas une réécriture de tout leur processus, pas un œuf d’or, pas seulement de la modularité, pas facile. On dirait la reprise de la chanson Léa de Louise Attaque.
L’idée est toujours la même : limiter l’intervention humaine, la sérialisation trop forte des tâches et automatiser tout ce qui peut l’être.

La présentation comporte une cartographie des problèmes qu’ils rencontrent et leurs relations, sur les problèmes modularité qui entraînent des interventions humaines qui entraînent des problèmes de cadences, etc.
Tous ces problèmes sont connus mais sont amplifiés avec le temps, avec pour une illustration de la modularité sans l’automatisation, une vidéo d’un mec en train de courir pieds nus sur un tapis roulant pendant qu’un autre met plein de LEGO : D

Je n'ai malheureusement pas réussi à comprendre les détails, un exemple de problème donné est le conteneur Docker, pour mettre à jour quelque chose dedans, on doit tout reproduire, que ce soit pour corriger un bug, ou ajouter des fonctionnalités. Pour résoudre ce type de problèmes, ils prévoient de mettre en place un « openshift build service » pour les conteneurs docker.
Le deuxième point c’est d’avoir une orchestration de la construction du paquet dans koji pour reconstruire les paquets automatiquement.
Le troisième c’est gestion des parutions, pour Fedora Atomic, le cycle est de 2 semaines, mais ils ont dû faire un processus de production dissocié qu’ils souhaitent rationaliser en suivant le même processus unique et global que pour le reste.

IoT

La présentation sur l’internet des objets et les objets connectés était hyper technique et orienté tout d’horizon sur la situation actuelle de Fedora vis-à-vis de ce monde.

Je comprends qu’une bonne partie des protocoles de communication sont présents ou en bonne passe de l’être, mais ce sont les piles logicielles qui ne sont pas encore empaquetés. Le même problème récurrent lié à la multitude de logiciels venant de partout, ils précisent par exemple qu’ils ont 700 paquets à produire pour pouvoir mettre à disposition Node-RED et qu’ils en sont à presque 400 de “prêts” :

L’autre exemple pris est OpenHab qui ne rencontre cette fois ci ce n’est pas un problème de dépendances jabascript, mais de difficulté sur Java.

Sur la partie analyse de données, plusieurs éléments existent et fonctionnent bien, comme Elastic Search, Kibana et divers outils liés à Hadoop. Mais concernant les différents panneaux de contrôles basés sur nodejs, mais vu la diversité et les mêmes soucis de dépendances ce n’est pas empaqueté… Seul freeboard devrait l’être prochainement.

Pagure

La présentation de Pierre-Yves Chibon/Pingou sur Pagure qui est une alternative récente à Github et Gitlab ! La présentation a réuni une cinquantaine de personnes et réceptionné des applaudissements à plusieurs occasions par l’assemblée, les utilisateurs sont enthousiastes et n’ont pas manqué de le faire savoir.

Fonctionnalités existantes ou arrivant très prochainement

Globales

• le suivi de projet sera bientôt possible pour avoir des alertes sur l’activité, un peu à la github ;
• héberger de la documentation html sur docs.pagure.org/nom_du_projet ;
• ajout d’un README par défaut, permettant d’éviter à ce que l’utilisateur ai à initialiser la branche master (j’en ai moi-même bénéficié et je n’ai rien eu besoin de faire pour que ça marche, vu mon niveau de technique je suis bien content de ne pas avoir à m’y intéresser) ;
• ajouter un texte qui s’affichera sur l’écran de pull-request pour informer le contributeur d’actions ou de procédure à suivre ;
• possibilité d’avoir un « Fake namespace », je crois que c’est pour permettre d’avoir une barre oblique « / » dans le nom grâce à une astucieuse solution basé sur la longueur des chaînes. Pour éviter les soucis, quelques noms de projets sont rejetés, bref tous les mots clefs déjà pris par Pagure et quelques longueurs utilisées pour permettre ce mécanisme ;
• plusieurs points d’accroche (hooks) ont été créés, notamment un pour ReadTheDoc, pour fermer automatiqument un ticket, etc.

Gestion des tickets

• la création de feuilles de route (roadmap) va également arriver à l’avenir, il recommande actuellement d’utiliser les étiquettes (tags) sur la liste des tickets pour avoir des regroupements permettant de répondre de façon transitoire au besoin ;
• des modèles vont être disponibles pour mettre des titres par défaut et guider la saisie ;
• nouveau bouton permettant de s’assigner directement une tâche en un clic ;
• ajout du remplissage automatique quand on fait @ et #.
• fonctionnalité de différence entre les diffs : prendre deux hash permet de montrer ce qu’il s’est passé entre les deux ;
  • j’ai demandé s’il était possible de le faire par date, visiblement ce n’est pas trop compliqué, mais ce n’est pas encore fait, et il risque d’y avoir des comportements étranges lors des fusions de branches.

À l’avenir, les fonctionnalités suivantes devraient arriver :

• la possibilité de créer des projets privés ;
• l’intégration continue avec jenkins (CI Integration) ;
• une nouvelle interface pour pkgs.fp.o qui est actuellement en test

Quelques chiffres sur Pagure

Pagure c’est : 56 contributeurs jusqu’à aujourd’hui ! À titre d’information, pour la v1.0 c’était 33 !

Dans le top 10, seuls 2 sont des contributeurs Red Hat. Pagure est désormais disponible dans Debian, deux instances publiques existent également en dehors de Fedora c’est également utilisé par le hackerspace de Brno ainsi qu’une distribution minimaliste RPM pour Raspberry pi.

Ceci montre que c’est un bon outil, que ce n’est pas un produit 100 % interne à Fedora/RedHat.

Bravo pingou !

Fedora Hubs et IRC en temps réel

La dernière présentation à laquelle je me suis rendu est l’interconnexion entre Fedora-Hubs, une plate-forme en cours de développement visant à connecter tous les flux d’informations liés à Fedora, avec IRC. La simplicité volontaire d’IRC rend les problématiques de diffusion multi-client, d’authentification et autre très complexe.

On sent que les deux développeurs se sont donné beaucoup de mal, mais si le POC fonctionne plus ou moins, l’approche semble étrange quand on a lu les articles très complets « Parlons XMPP de Goffi » ou même plus généralement de XMPP

Vous voulez me parler de cet article ? Contactez-moi sur le salon « traducteurs » de jabberfr.org (client XMPP javascript disponible en bas de chaque page).