Je fais de la veille depuis un moment mais je me suis fait la réflexion il y a seulement un mois que je devais suivre les mises à jour des logiciels/outils que j’utilise. Quelques raisons à cela :

• Suivre l’actualité, surveiller le développement et les nouveautés des logiciels/outils qu’on utilise est sage et fort utile
• Pour un sysadmin/architecte/dev, ça permet d’avoir une bonne visibilité des dernières solutions/features dans le domaine et de garder un œil sur les bugs résolus
• Intéressant de voir ce « panaché » de différents projets, comment ils travaillent (cycle de dev, release notes, communication, outils utilisés…), comment ça évolue
• Mieux comprendre mes outils, leur fonctionnement, leurs limites et bugs. J’aime beaucoup lire les news Coreutils notamment
• Accessoirement ça peut aider à la prise de décision pour choisir un logiciel. En environnement professionnel un projet avec des commits fréquents, une communauté active peut faire la différence par exemple

RSS comme d’hab

J’ai voulu réutiliser l’outil principal me servant pour ma veille, le lecteur RSS. J’utilise FreshRSS (le meilleur !), il propose les avantages suivants :

• Il permet de créer une catégorie où on rangera spécifiquement certains flux RSS, j’ai créé la catégorie Releases
• Il permet lors de l’ajout du flux RSS de spécifier où envoyer le flux RSS (dans quelle catégorie), si on veut l’afficher dans le flux principal ou seulement dans une catégorie précise (Visibilité > Afficher dans sa catégorie) et de choisir la période de rafraîchissement (Ne pas automatiquement rafraîchir plus souvent que 12h pour ma part)
• Lorsqu’on veut ajouter un flux RSS, il va chercher le flux sur le site. Et c’est très utile vu que la plupart des projets se foutent complètement d’indiquer l’adresse du flux RSS. Par exemple je lui donne https://secure.php.net/releases/, il me propose comme flux RSS https://secure.php.net/releases/feed.php

Bazar comme d’hab

J’ai commencé à lister tous les outils que je voulais suivre, ceux que j’utilise en tant qu’utilisateur (BorgBackup, Raspbian, Termux, Coreutils…), ceux sur lesquels je bosse (MariaDB, PHP, systemd, rsyslog…). Ensuite je me suis penché sur chaque projet, je m’attendais à quelque chose de plus carré et simple… c’est le bazar et pas du tout la cathédrale.

Voici ma liste par ordre alphabétique, je vais attendre un peu (work in progress) et j’en ferai un Mémo. Le premier lien concerne la page releases, le second lien le flux RSS, le troisième (quand il y a besoin) le changelog (news, release notes).

Ansible RSS Changelog
BorgBackup RSS Changelog
Chrony ML
Coreutils RSS
dnsdist RSS Changelog
Elixir RSS Changelog
Etcher RSS Changelog
FreshRSS RSS
Glances RSS
Guake RSS
HAProxy Changelog
MariaDB RSS Changelog
ncdu RSS
Nix RSS
Node.js RSS
peco RSS
PHP RSS
Python RSS
ranger RSS Changelog
Raspbian
rsyslog RSS Changelog
Ruby RSS
scrcpy RSS
Shaarli RSS Changelog
Signal RSS
Syncthing RSS
systemd RSS Changelog
Terminator RSS
Termux RSS
Tilix RSS

Ce que j’ai appris et compris

Le lecteur voit le résultat final qu’on lui présente élégamment dans un article, vous verrez difficilement certains points. Voici ce que j’ai appris et compris :

• Il m’a fallu plus de 3h pour 30 projets entre lister mes outils, ah j’ai oublié celui-là, il est où le flux RSS, bordel le changelog !
• Les 2/3 des projets sont sur GitHub… l’occasion de se remémorer l’article de Carl : Le danger GitHub
• Pour ceux qui ne le savent pas, sur GitHub il suffit en général d’ajouter .atom à la fin de l’URL pour avoir le flux RSS. Ainsi https://github.com/peco/peco/releases devient https://github.com/peco/peco/releases.atom
• Beaucoup de projets publient la release sur GitHub mais ne mettent aucune information. Par exemple rsyslog v8.34.0 (il faut cliquer pour comprendre) : v8.34.0. Dit autrement suivre certains flux RSS ne vous apportera aucune information sauf une date de sortie… il vous faudra systématiquement aller sur la page Changelog. C’est bien pour ça que je les ai donné
• On pourrait croire que les projets plus importants sont mieux lotis ou plus carré, pas du tout ! Pour moi une référence c’est le changelog de Shaarli : 1/ Changelog versionné, nommé CHANGELOG.md bien voyant et à la racine du projet sur GitHub 2/ Une URL qui ne change pas ! https://github.com/shaarli/Shaarli/blob/master/CHANGELOG.md contrairement à https://github.com/borgbackup/borg/blob/1.1.5/docs/changes.rst#changelog avec le numéro de version dedans, ce qui veut dire que ça va changer 3/ Où on renseigne comment est pensé le changelog : The format is based on Keep a Changelog and this project adheres to Semantic Versioning
• A comparer avec Raspbian par exemple, je n’ai pas trouvé de flux RSS… raspbian.org existe mais le changelog est chez raspberrypi.org…
• Citons aussi dnsdist, un sous-projet de PowerDNS. Les releases de PowerDNS et dnsdist sont mises ensemble… donc mélangées : https://github.com/PowerDNS/pdns/releases
• Parfois pas le choix, il faut passer par une mailing list : https://chrony.tuxfamily.org/lists.html https://www.mail-archive.com/haproxy@formilux.org/msg28004.html (on peut se brancher en RSS dessus mais il faudra filtrer sur ANNOUNCE)
• Pour vous rendre compte de la difficulté et du bazar pour trouver les bonnes URL : http://feeds.feedburner.com/PythonInsider https://dev.yorhel.nl/ncdu/changes https://savannah.gnu.org/news/atom.php?group=coreutils https://github.com/systemd/systemd/blob/master/NEWS https://www.haproxy.org/download/1.8/src/CHANGELOG https://elixir-lang.org/blog/categories.html#Releases

Cheminement

Souvent les informations récoltées via flux RSS sont insuffisantes, il faut alors aller chercher le changelog qui peut être difficile à retrouver…

Pour ma part je garde un fichier nommé releases sous la main où j’ai répertorié les URL des projets. Concrètement le cheminement donne 1/ Je suis averti de la nouvelle version du logiciel par flux RSS 2/ Je consulte le changelog ou 3/ J’ouvre mon fichier releases, je clique sur le lien du changelog. C’est une solution peu satisfaisante et perfectible. Comment vous faites de votre côté ? Une meilleure solution ? Partagez !

En conclusion

Il reste encore beaucoup de chemin à parcourir aussi bien côté projets pour qu’ils informent correctement et de manière simple que côté utilisateurs cherchant « juste » à s’informer. Chaque projet gère sa barque comme il l’entend, il faut gérer les priorités et faire avec les moyens du bord mais communiquer, améliorer ou juste fournir un changelog et un flux RSS corrects ne devrait pas être négligé.

Les modèles du genre sont Python, MariaDB, Shaarli. Développeurs au boulot

Original post of blog-libre.Votez pour ce billet sur Planet Libre.