Bruno Michel a écrit 3285 commentaires

Bonjour,

LinuxFr.org est un site géré par des bénévoles sur leur temps libre et vise à encourager l'utilisation de Logiciels Libres. Quasiment tous les contenus (dont les messages sur le forum) ne peuvent plus recevoir de nouveaux commentaires après trois mois. Cela vient du fait que robots de spam n'hésitaient pas à déposer des commentaires sur des anciens contenus, ce qui nous poser des problèmes de détection et modération.

Pour les notifications par email, nous allons y réfléchir si d'autres personnes en font également cette demande ou votent pertinent sur cette entrée de suivi. Ce n'est pas facile à mettre en place. Nous refusons de passer par des partenaires commerciaux (et donc par des logiciels non libres) pour l'envoi des emails. Cela nous demande déjà beaucoup de travail pour les emails existants et il nous arrive de nous faire interdire par certains fournisseurs d'accès qui classent certains de nos emails dans les spams.

Sur le site, il est possible de consulter une page intitulée « Mon tableau de bord », avec les derniers commentaires que l'on a posté et une icône si un de ceux-ci a eu une réponse. Est-ce qu'il serait intéressant/acceptable d'avoir le même mécanisme pour les réponses à une entrée du forum ?

Ce commentaire sur hacker news parle également de travaux dans les années 90, sur VAX : https://news.ycombinator.com/item?id=16092183. S'en suit une discussion pour savoir si ces travaux auraient dû ou non mettre la puce à l'oreille d'Intel.

J'ai retrouvé un commentaire d'un des éditeurs du WHATWG qui montre bien que la version du W3C est juste là pour faire bonne figure auprès des gens qui donnent des sous au W3C et que les modifications du WHATWG sont souvent copiées-collées sauvagement : https://www.reddit.com/r/javascript/comments/5swe9b/what_is_the_difference_between_the_w3c_and_the/ddkwft4/

Le W3C n'est plus l'organisme qui fait référence pour le HTML, tout se passe dans le WHATWG. De ce que j'ai entendu, le W3C reprend de temps en temps des patchs du WHATWG (et pas toujours très bien) et publie des versions pour faire illusion.

Ben… c'est quand même un business qu'il prépare derrière. C'est du Libre, il contribue, tout ça, mais il veut quand même que ça lui rapporte de l'argent à la fin. Il ne fait pas ça par pur amour pour l'Humanité, et on ne peut pas lui reprocher!

Ce n'est pas ce que Gaël Duval dit. Je cite la page de la campagne de financement :

Je veux qu'eelo soit un projet à but non lucratif, un projet "dans l'intérêt du public". Je pense que les systèmes d'exploitation et les services web devraient être une ressource partagée : comme je l'ai expliqué il y a quelques années, les systèmes d'exploitation sont des infrastructures. Comme les réseaux téléphoniques, les voies ferrées, les routes.

Sans but lucratif ne signifie pas que rien ne sera vendu. Certains smartphones eelo seront probablement à vendre, et certains services premium seront disponibles pour les entreprises. Mais le profit ne sera pas le premier objectif d'eelo.

Si tu n'es pas très à l'aise en crypto, je te recommande fortement de reprendre le mode de fonctionnement d'un gestionnaire de mots de passe existant qui a fait ses preuves.

Pour bitwarden, il existe une documentation de l'API (écrite par un tiers) qui parle des questions crypto : https://github.com/jcs/bitwarden-ruby/blob/master/API.md. Ça pourrait être cool d'avoir une API compatible avec bitwarden.

Il y a également Buttercup. C'est récent, mais ça a déjà l'air d'être assez joli et pratique à utiliser.

Il existe une implémentation en Ruby de la partie serveur de bitwarden. L'auteur de cette implémentation a expliqué sa démarche ici : https://jcs.org/2017/11/17/bitwarden. Et en bonus, il a documenté toute l'API par là : https://github.com/jcs/bitwarden-ruby/blob/master/API.md.

Merci, c'est déployé.

Oui, on garde en base de données une version tronquée des contenus pour des raisons de performance (éviter de les recalculer pour chaque vue).

Ce n'est pas faisable en CSS de tronquer proprement des contenus sur plusieurs lignes qui peuvent contenir des images ou du code. On pourrait le faire en JavaScript, mais tous les utilisateurs n'ont pas du JavaScript activé et ce serait très lent sur les smartphones.

Merci, c'est déployé en production.

Cf https://github.com/nono/html-pipeline-linuxfr/commit/f44bfc23ca0a6cc67ed49feaed471cb905b3619a

L'outil qui sert pour générer une image à partir d'une formule mathématique, svgtex avait l'air dans les choux. Je l'ai relancé. Est-ce que le commentaire passe maintenant ?

Désolé pour le dérangement avec cette nouvelle version de Ruby…

Pas de soucis, merci à toi d'avoir essuyé les plâtres !

Il faudrait peut-être modifier le fichier README pour ne pas conseiller d'installer la version stable de Ruby, mais plutôt une version exacte ?

Il y a malheureusement pas mal de petits points plus très à jour dans le README. Ce n'est pas facile de savoir lesquels sans refaire une installation depuis zéro. Ça fait déjà plusieurs fois que je me fais la remarque que je devrais me refaire une installation depuis zéro de temps en temps (disons une fois par an pour que ça ne soit pas trop difficile) et en profiter pour mettre à jour le README, mais pour le moment, je ne l'ai toujours pas fait.

Je viens de faire un pull request sur la branche before-redesign pour appliquer cette modification au Gemfile et au Gemfile.lock: https://github.com/linuxfrorg/linuxfr.org/pull/215

Merci, c'est intégré.

Maintenant, cette exception n'est plus levée, mais la commande bin/rake db:setup tourne dans le vide.

Je ne suis pas encore passé à Ruby 2.4 et il y a des changements visiblement assez importants qui nécessitent de mettre à jour quelques gems. Ici, ça a l'air d'être spring. J'ai fait cette mise à jour : https://github.com/linuxfrorg/linuxfr.org/commit/2f07cba9558cc4acf77e90ace7e7ed7fb7eaa320. Pour l'appliquer, il faut faire bin/spring stop ; git pull origin before-redesign && bundle.

Je viens de pusher ce commit : https://github.com/linuxfrorg/linuxfr.org/commit/1329455941e5b5481547d0eecb944dc5779ee2b0. Est-ce que ça marche mieux ?

On utilise sass pour les CSS du site. Ça s'écrit comme de la CSS mais ça permet d'importer quelques styles communs (ceux pour la coloration syntaxique du code dans les contenus et commentaires par exemple). Voici un exemple d'utilisation d'une image : https://github.com/linuxfrorg/linuxfr.org/blob/master/app/assets/stylesheets/contrib/kaiska-new.css.scss#L132 et l'image se trouve dans ce répertoire : https://github.com/linuxfrorg/linuxfr.org/tree/master/public/images/contrib/kaiska.

C'est déployé. Merci !

C'est déployé en prod : S/MIME. Merci !

Disons qu'en l'état, j'ai l'impression qu'aujourd'hui la décision de développer une plateforme spécifique se fait sur un à priori dont je n'ai pas vu de justification. Sans doute existe-t-il de bonnes raisons de réimplémenter un forum, un outil de suivi, un wiki, mais elles ne me paraissent pas évidentes.

La question ne se pose pas vraiment en ces termes. Quand on a voulu se débarrasser de templeet, j'ai pris la décision de partir sur un développement spécifique plutôt que des logiciels libres existants en 2008 et je pense que c'était le bon choix. J'avais également l'espoir à l'époque que cette base de code spécifique puisse être utilisée par d'autres sites, mais ça ne s'est pas concrétisé.

Depuis, le contexte a changé et si on devait jeter la version actuelle, je militerais pour partir sur des logiciels libres existants plutôt que de tout redévelopper. Mais la version actuelle existe, fonctionne bien et demande peu de maintenance. De l'autre côté, vouloir migrer même vers des outils existants demande un travail très conséquent pour juste arriver au même niveau. Je ne pense pas que l'on ait les ressources pour réussir un tel chantier. Et si on les avait, ça serait sûrement plus efficace de faire évoluer progressivement l'existant que de se lancer dans un gros chantier qui va forcément prendre du temps et dont l'issue est plus incertaine.

Si j'en crois les statistiques du Github, LinuxFR.org semble développé par à peu près une personne (en supposant que ce ne soit pas un artefact de la gestion des commits).

Github n'affiche pas les personnes qui n'ont pas de compte sur github dans ces statistiques. Par exemple, Benoît Sibaud est le deuxième contributeur en nombre de commits (67 commits), mais n'apparaît pas ici. Il y a également quelques autres dépôts git annexes. Mais même en prenant compte cela, je dois être l'auteur de 90% des commits.

Conséquences : beaucoup d'entrées de suivi non traitées, et si j'en crois une réflexion plus haut, il y a plein de priorités qui ne sont même pas dans ces entrées de suivi.

Dans les priorités qu'il n'y a pas dans les entrées de suivi, il y a notamment le travail de Mathieu Jourdan (l'auteur de cette dépêche).

Est-ce que ce manque de développeurs tiers est problématique ?

J'aimerais bien avoir d'autres développeurs à mes côtés, mais comme tu le fais remarquer plus haut, c'est une situation courante dans le milieu de l'Open Source. Je ne pense pas que ce soit problématique, en tout cas, pas plus que pour d'autres domaines. Côté administration système, il y a aussi des tâches qui prennent du retard (mise à jour debian, cough, cough). Et je ne parle même pas de l'association qui n'a pas tenu d'assemblée générale l'année dernière et ça ne me paraît pas évident que la prochaine arrive avant la fin de l'année. Globalement, la plupart des personnes très impliquées dans le site sont là depuis plus de 10 ans et ont moins de temps à consacrer au site que ça pu l'être par le passé. On aurait bien besoin de nouvelles forces, et si je devais donner une priorité, je dirais animer l'espace de rédaction (ce n'est qu'un avis personnel).

Est-ce que la force de développement aujourd'hui suffit à suivre la maintenance et les nouvelles demandes pertinentes ?

Pour la maintenance, oui. Pour les nouvelles demandes pertinentes, c'est difficile à juger. Il y a pas mal d'entrées dans le suivi qu'il serait bénéfique pour le site d'implémenter mais ça reste du domaine du confort. Je n'ai pas l'impression que ça puisse changer fortement la manière dont les gens voient le site et l'utilisent, mais c'est possible que je rate une entrée de suivi qui pourrait avoir un impact notable pour une partie de notre auditoire. J'ai plutôt l'impression que les demandes viennent des power users, alors que j'aimerais plutôt favoriser l'arrivée de nouveaux lecteurs et surtout contributeurs.

En quoi ce développement par environ une personne peut limiter les décisions que l'on pourrait prendre suite à la réflexion amorcée sur ce topic ? (si on a des bonnes idées mais personne pour les développer, ça ne servira à rien).

Avec plus de développeurs, on pourrait aller plus vite ;-)

Pour le reste, le travail de Mathieu m'a remotivé à passer un peu plus de temps à développer pour le site. Et je vais faire passer ses demandes en priorité. Ce n'est pas que je considère que les autres demandes ne sont pas intéressantes, c'est juste que je vois dans son travail une attention pour attirer de nouveaux lecteurs et contributeurs sur le site, chose qui me motive tout particulièrement.

J'ose le demander : ne serait-il pas pertinent de passer LinuxFR.org sur une plateforme libre tierce (voire plusieurs outils : publication / forum / wiki / suivi…), en remplacement d'un code purement spécifique ? (quitte à faire des adaptations)

Non, ce n'est pas une bonne idée quand on se dit que l'on a trop de travail que de s'en rajouter encore plus. Pour arriver à monter un clone de LinuxFr.org avec une qualité équivalente et en conservant l'historique, il y a un boulot colossal à fournir. J'ai passé plusieurs mois à migrer les contenus de templeet vers la version rails de LinuxFr.org (pas à temps plein) et à l'époque, il n'y avait pas de wiki, de tags, de dépêches collaboratives, etc.

c'est dommage de bloquer

Mais je ne bloque pas. Si quelqu'un m'envoie un patch pour pouvoir éditer des contenus avec un historique, je l'intégrerais avec plaisir.

Vous devriez lire en entier les commentaires auxquels vous répondez, pour pouvoir y répondre honnêtement, par exemple en expliquant en quoi l'affichage de l'historique (discuté comme manière d'éviter les problèmes dont vous parlez, ben oui les gens à qui vous répondez connaissent déjà ce problème) ne résoudrait pas les problèmes que vous soulevez (vous faites comme si les gens n'y avaient pas déjà réfléchi).

On a de l'historique sur les dépêches dans l'espace de rédaction et ça n'empêche pas les gens de venir s'y chamailler. Mais je ne réfute pas l'intérêt de pouvoir éditer des journaux ou commentaires. C'est juste que sur LinuxFr.org, comme sur Hacker News, il y a des commentaires techniques très intéressants mais aussi beaucoup de commentaires inutilement agressifs. Et que l'on soit en possibilité de modifier ses commentaires ne change pas grand chose : il y a aura toujours des gens dans les deux camps pour venir râler. Je pense que pouvoir éditer ses commentaires va légèrement augmenter cette proportion, mais que ça reste acceptable au vu de l'intérêt de la fonctionnalité. Par contre, très clairement, je n'ai pas envie de passer du temps à coder sur ça, il y a plein d'autres choses dans le suivi qui me semblent bien plus importantes (et d'autres d'ailleurs qui ne sont pas dans le suivi).

Parsing JSON is a minefield

Ce n'est probablement qu'une coïncidence, mais je suis tombé sur ce fil de discussions aujourd'hui : https://news.ycombinator.com/item?id=15524640. L'auteur du commentaire initial est critiqué par une autre personne pour avoir édité son commentaire :

I think it's fair to note that they edited that part in after I wrote my comment using that exact same wording, but failed to mention they edited it. It's not that their wording didn't stop me from replying, its that their wording did not exist when I replied.

It's a scummy argument tactic, which you've proven is highly effective.

J'ai remis Expérience utilisateur à la place d'ergonomie.

Et merci pour cette dépêche !