(le billet ci-dessous est également publié sur mon blog, pour mémoire « Salut à Toi » est outil collaboratif et de communication basé sur XMPP).
Beaucoup de travail a été effectué lors des derniers mois, me laissant peu de temps pour parler des nouveautés. Jetons un coup d'œil à la dernière.
Pour le développement de Salut à Toi nous ne voulons pas utiliser de logiciels propriétaires ou centralisés et nous utilisons Mercurial, aussi nous avons jusqu'ici été réfractaires à utiliser les plateformes actuellement à la mode. Avec les améliorations récentes de notre composant SàT Pubsub (vous pouvez lire – en anglais – l'article de jnanar pour plus d'infos), et de Libervia, notre interface web, il est devenu clair que notre vieille idée d'utiliser XMPP et SàT pour gérer les tickets était à portée de main, nous l'avons donc fait.
SàT est maintenant capable de gérer les tickets via XMPP, en utilisant pubsub. Il a de nombreux avantages à cela :
- c'est décentralisé et fédéré, pas besoin de X comptes pour utiliser X gestionnaires de tickets. Vous pouvez également importer des tickets de projets tiers (par exemple des greffons pour votre projet) dans votre propre site web.
- c'est standard : il est possible de retrouver ou gérer des tickets sur un serveur extérieur facilement, sans API propriétaire.
- c'est extrêmement souple : n'importe quel champ peut être utilisé, et le mécanisme peut être utilisé pour toute liste (rapports de bogues, choses à faire, liste de courses, etc.).
- étant basé sur SàT, c'est multi-plateformes
- on peut utiliser des passerelles, pour par exemple intégrer de manière transparente les tickets d'autres services (par exemple Gitlab ou Github)
Le fonctionnement est basé sur pubsub avec une extension expérimentale (non standard pour le moment): les schémas de nœud qui permettent de spécifier une mise en forme des données (en utilisant les « data forms » qui devra être respectée pour chaque élément (chaque ticket). De cette façon, les tickets publiés par des clients tiers peuvent être vérifiés et validés. Pubsub a également un système de permissions qui permet d'avoir des collections de tickets publiques ou privées (des nœuds dans la terminologie pubsub). Les commentaires utilisent l'extension microblogage de XMPP (qui aurait plutôt dû s'appeler « blog »).
Mais ça n'est pas tout ! Une autre fonctionnalité a été implémentée par-dessus ça : les requêtes de merges (« merges requests »). L'idée ici et d'avoir un moyen de proposer des modifications/améliorations à un projet sans être lié à un outil particulier, c'est-à-dire que l'on peut les utiliser avec Mercurial, Git ou potentiellement n'importe quel outil. Encore une fois, nous profitons de la décentralisation, et nous pouvons avoir des collaborations/contributions en personnes sur des serveurs différents.
Ci-dessous vous avez une petite vidéo (en anglais, cliquez sur l'image pour la lire) qui montre les requêtes de merge. On utilise jp (l'interface CLI de SàT) pour envoyer les modifications à un serveur. Par défaut, le serveur va essayer tous les gestionnaires de « merge requests » jusqu'à ce qu'il trouve lequel peut gérer le dépôt demandé. Il y a une petite couche autour des commandes pour faire les opérations de base (en particulier créer les données à exporter), puis les données et métadonnées sont mises en forme et envoyées sur le nœud pubsub. Pour le moment, seul Mercurial est implémenté, mais Git va bien entendu suivre, et peut-être un gestionnaire de base utilisant un diff pour les cas les plus simples.
Bien sûr, la fonctionnalité est nouvelle et encore basique : il n'est pas encore possible de préciser les lignes du code auxquelles un commentaire se réfère, ou d'utiliser une mise en forme riche. Cela va bien sûr venir plus ou moins vite, mais si vous voulez accélérer les choses, eh bien, les « merge requests » sont les bienvenues ;).
Vous pouvez le voir en œuvre sur le gestionnaires de tickets de SàT
Pour celles et ceux qui sont à Paris, je serais au « Paris Open Source Summit » (POSS) demain et jeudi (au stand A2, « Salut à Toi »). Si vous voulez aider le projet, nous sommes sur Liberapay.
Bientôt d'autres billets sur les nouveautés dans SàT…
# Super !
Posté par Yves (site web personnel) . Évalué à 3.
C’est impressionnant ! Bravo !
Reste à voir si la communauté va suivre… Ce serait sans doute bénéfique sur le long terme, face à l’hégémonie des plates-formes centralisatrices.
[^] # Re: Super !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 05 décembre 2017 à 15:01.
Merci !
Il y a bien sûr encore du boulot pour arriver au même niveau de confort que les grosses plateformes, mais c'est déjà utilisable en l'état, et ça peut aller vite si un peu de monde suit.
Les applications vont bien au delà du rapport de bogues, on peut mettre les champs qu'on veut dans les tickets, et les merge-requests sont un exemple d'utilisation.
Il est aussi facile de faire des automatisations (étant basé sur pubsub, chaque nouveau ticket envoie une notification par exemple), et j'aimerais bien ajouter un système d'intégration continue (des tests automatisés) qui nous seraient bien utiles pour le développement de SàT.
J'espère aussi trouver du monde pour avancer sur le développement, si des développeurs python passent par là :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Super !
Posté par seveso . Évalué à 1.
Effectivement c'est peu. Mais ce n'est pas forcément leur seule source de revenus, j'espère qu'ils reçoivent beaucoup de dons par ailleurs.
Personnellement je donne par virement bancaire car ça fait un intermédiaire de moins. Seule ma banque est en mesure de dresser mon profil consommateur et c'est déjà trop. Mais j'ai pas de meilleure solution pour l'instant à moins de pouvoir payer en espèces ou avec GNU Taler quand il sera prêt.
[^] # Re: Super !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Liberapay, les cotisations et les (rares) dons sont nos seules sources de revenues, c'est indiqué dans nos assemblées générales (cf. la dernière par exemple).
Pour ce qui est des déplacement (par exemple pour venir au POSS d'où j'écris), l'hébergement, le matériel, etc. C'est de notre poche, et on se fait parfois rembourser par l'association.
# Fuite possible du mot de passe XMPP ?
Posté par seveso . Évalué à 2.
J'aime beaucoup l'idée de pouvoir m'authentifier auprès d'un service avec mon compte jabber. Cependant je n'aime pas trop l'idée que mon mot de passe jabber puisse être intercepté par la plate-forme qui héberge le service.
Je connais pas mal de personnes ayant déjà un compte jabber, mais si je devais mettre en place un outil de ce style je pense que ça risque d'être rédhibitoire pour beaucoup. J'ai déjà rencontré ce genre de blocage lorsque je voulais faire tester mon instance Movim à des amis ayant un compte sur leurs propres serveurs.
Serait-il envisageable d'implémenter la XEP-0070 qui a déjà été présentée ici-même dans l'article Authentifiez-vous sans mot de passe grâce à XMPP ! ?
En tout cas je dis bravo et merci à l'équipe de SàT pour tout ce que vous faites d'intelligent avec XMPP et aussi pour les journaux "Parlons XMPP" que je trouve très instructifs.
[^] # Re: Fuite possible du mot de passe XMPP ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
La XEP-0070 est déjà implémentée dans SàT (et notamment utilisable via Cagou l'interface Android/bureau), on a même pas mal communiqué autour de cette XEP pour la faire connaître.
Mais elle permet uniquement de s'assurer de qui est un contact (on entre son identifiant, et on vérifie que la personne qui se connecte a accès au compte indiqué), pas de publier à la place de la personne. Pour ça, il faut soit que la personne sur un serveur externe ait un client capable d'utiliser la fonctionnalités voulue (ici les tickets), soit qu'il y ait une connexion via un système sans transmission de mot de passe, par exemple via OAuth.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.