Bruno Michel a écrit 3286 commentaires

Sommaire

• Décomposition des changements
  • Priorité 1
    • 1ère série - préparer le terrain dans l'espace de rédaction
  • Priorité 2
    • 2ème série - soigner l'accueil
    • 3ème série - affiner la liste des articles
    • 4ème série - affiner la liste des billets
  • Priorité 3
    • 5ème série - améliorer le suivi des commentaires
    • 6ème série - nouvelle barre de navigation
  • Priorité 4
    • 7ème série - blogs
    • 8ème série

Merci pour la contribution.

Pour information, Mathieu m'avait également donné une suggestion pour l'ordre des modifications à faire. Je la mets ci-dessous.

---

Décomposition des changements

Ci-dessous on décompose les changements qui nous paraissent essentiels. On propose d'implémenter ces changements par série, de sorte à garder la cohérence des changements liés entre eux et que chaque série apporte une amélioration perceptible.

Priorité 1

1ère série - préparer le terrain dans l'espace de rédaction

Objectif : lister plus de contenus sur un même écran, inciter à consulter d'abord les contenus publiés sur LinuxFr, et à aller voir les ressources externes dans un second temps.

• [ ] [Rédaction] faire évoluer le gabarit d'article pour inciter à écrire un chapeau
• [ ] [Rédaction] faire évoluer le gabarit pour intégrer au moins une image
• [ ] [Rédaction] faire évoluer le gabarit pour toujours afficher les liens à la suite de l'article
• [ ] [Rédaction] permettre de créditer les auteurs des images
• [X] [Actualités] sur la liste des articles, retirer les liens
• [X] [Actualités] sur les articles, placer les liens externes à la suite du texte

Dans chaque article, on peut placer les liens externes dans deux colonnes à la suite du texte :

https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/3.1.0_article.png

Priorité 2

2ème série - soigner l'accueil

Objectif : faciliter le premier contact, la compréhension de l'objet du site et des différents types de contenus.

• [ ] [Navigation] déplacer le menu utilisateur vers la partie droite du bandeau de navigation
• [ ] [Navigation] ajouter le bouton « À Propos » dans le bandeau du haut
• [ ] [Navigation] màj la terminologie pour la rendre plus accessible
• [ ] [Accueil] afficher les unes (?) / actualités / billets séparément avec leurs traitements visuels respectifs
• [ ] [Accueil] faire apparaître les sondages, derniers messages de forums, et dernières modifications de wiki
• [ ] [Préférences] supprimer les préférences liées à l'accueil devenues obsolètes

Sur la maquette ci-après, on a pas de « une » persistante. On garde la possibilité de mettre en avant des articles (cf Paperwork 1.1) mais ceux-ci peuvent descendre dans la liste au fil du temps :

https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/1.0.0_accueil.png

La barre de navigation en haut et le menu utilisitateur doivent s'adapter au mobile :

https://github.com/mjourdan/linuxfr-design/blob/master/experimentations_5/barre_de_navigation.png

3ème série - affiner la liste des articles

Objectif : inciter à consulter les articles publiés sur LinuxFr, distinguer les différents types de contenus

• [ ] [Actualités] sur la liste des articles, afficher les chapeaux (ou un texte tronqué) et illustrations
• [ ] [Actualités] sur la liste des articles, retirer la possibilité de pertinenter / inutiler
• [ ] [Actualités] sur la liste des articles, implémenter le traitement visuel
• [ ] [Actualités] sur la listes des actualités, faire apparaître les articles les plus visités et les derniers commentaires

4ème série - affiner la liste des billets

Objectif : inciter à consulter les billets, renforcer la distinction articles éditoriaux / billets personnels

• [ ] [Blogs] sur la liste des billets, afficher les chapeaux et illustrations
• [ ] [Blogs] sur la liste des billets, retirer la possibilité de pertinenter / inutiler
• [ ] [Blogs] sur la listes des blogs, faire apparaître les billets les plus visités et les derniers commentaires
• [ ] [Blogs] sur la liste des billets, implémenter le traitement visuel

Priorité 3

5ème série - améliorer le suivi des commentaires

Objectif : améliorer le confort de navigation parmi les commentaires, augmenter le rapport signal / bruit.

• [ ] [Commentaires] mise en forme des commentaires (avatars arrondis, notes…)
• [ ] [Commentaires] mettre en valeur les commentaires jugés pertinents par les auteurs des articles auxquels ils répondent (les messages des autres utilisateurs et ceux des auteurs eux-mêmes)
• [ ] [Commentaires] permettre de rédiger un commentaire sans perdre le contexte (ni quitter la page ni perdre le suivi des commentaires non lus)
• [ ] [Commentaires] nouveaux filtres de navigation (selon la note, afficher/masquer les erreurs de français)
• [ ] [Commentaires] permettre de signaler des erreurs de français (fil positionné à la suite des autres commentaires)

6ème série - nouvelle barre de navigation

Objectif : adapter la navigation aux mobiles et aux interfaces tactiles

• [ ] [Tribune] regrouper les espaces de discussion instantanée
• [ ] [Tribune] permettre de les afficher/masquer à volonté sur mobile, depuis les barres de navigation
• [ ] [Navigation] implémenter la nouvelle barre pour naviguer parmi les contenus / commentaires
• [ ] [Rédaction] implémenter la nouvelle barre pour naviguer dans l'espace de rédaction
• [ ] [Rédaction] implémenter la nouvelle barre pour rédiger les articles
• [ ] [Navigation] màj la liste des catégories, plus courte et accessible

Priorité 4

7ème série - blogs

Objectif : transformer les journaux en des blogs attrayants

• [] [Blogs] soigner la présentation des profils
• [] [Blogs] permettre d'éditer son profil depuis la page idoine
• [] [Blogs] séparer les différents contenus par onglets
• [] [Blogs] permettre d'épingler quelques contenus

8ème série

Objectif : améliorer le confort de rédaction & de navigation

• [ ] [Rédaction] lister l'ensemble des articles et billets auxquels les gens participent sur la page de rédaction
• [ ] [Notification] mettre en place le système de notification

Pendant un paquet d'années, les navigateurs se faisaient concurrence sur les performances et les benchmarks étaient les juges en la matière. Chaque éditeur avait plus ou moins son benchmark où, étonnamment, son navigateur s'en sortait mieux que dans les benchmarks des autres navigateurs. Depuis 2 ou 3 ans, les éditeurs ont changé de bord et abandonnent ces benchmarks. Ils se sont rendus compte qu'ils étaient arrivés à une situation où améliorer le score pour les benchmarks donnait souvent des résultats moins bons dans la vraie vie (un phénomène de sur-optimisation pour des cas spécifiques).

D'autre part, les benchmarks mettent souvent en avant les calculs en JS, ce qui est rarement là que l'impression de vitesse pour les utilisateurs se joue. Les accès au DOM ou savoir charger les bonnes ressources au bon moment sont souvent plus importants.

Bref, aujourd'hui, Firefox est généralement considéré comme le navigateur le plus rapide (suite à pas mal d'optimisations très récentes), suivi de très près par Chrome. Chrome est généralement considéré comme le navigateur le plus avancé en termes de sécurité (séparation en plusieurs processus notamment), suivi de près par Firefox. Derrière, j'entends de temps en temps parler en bien de Falkon, mais les autres navigateurs jouent surtout sur le côté plus léger (moins de fonctionnalités, moins d'extensions, etc.).

A priori, sass-rails va devenir un wrapper autour de sassc-rails : https://github.com/rails/sass-rails/pull/424.

On a maintenant un score de A sur https://tls.imirhil.fr/https/linuxfr.org

C'est effectivement un problème connu depuis un bout de temps. Pour le moment, la communauté Rails n'a pas l'air très décidée sur le chemin à prendre :

• certains proposent effectivement d'utiliser Dart Sass en l'embarquant dans une gem Ruby, mais personne n'a l'air d'avancer dans ce sens (ie écrire du code et être prêt à le maintenir)
• d'autres suggèrent de passer à sassc-rails, mais ce n'est pas très clair si le mainteneur de sassc-rails va encore maintenir cette gem très longtemps, et là encore, il n'y a pas de contributeurs
• enfin, Rails est en train de migrer progressivement de son assets pipeline vers webpack, et possiblement, la manière conseillée d'utiliser sass avec Rails 6.0 sera de passer via webpack.

Bref, pour le moment, le mieux est sûrement de continuer à attendre https://github.com/rails/rails/issues/32896, sachant qu'il n'y a pas d'urgence. Même si la version Ruby de Sass n'est plus prise en charge officiellement, elle ne va pas s'arrêter de marcher du jour au lendemain.

Merci, c'est fusionné et déployé en prod.

Il semblerait qu'une bonne partie de ces critiques de Wayland ne sont plus valides actuellement, voir ont toujours été inexactes/fausses.

Source : https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

Merci, c'est corrigé.

Je me suis permis d'éditer le commentaire pour corriger le lien vers le Site de dokiel.

J'ai regardé rapidement, ça plante sur un lien avec ce message d'erreur :

URI::InvalidURIError (URI must be ascii only "https://inkscape.org/fr/~wwderw/\u{2605}inkstitch-embroidery-extension")

En lisant rapidement les logs, le problème vient d'un lien avec un titre trop long pour la colonne dans MySQL : 'From the bitstream to the netlist, la démonstration qu'il est possible de faire la rétro-ingéniérie des bitstream'.

Ce qui peut être très pénalisant quand tu dois cloner souvent comme par exemple les serveurs de build.

Pour des serveurs de build, ça se contourne facilement en ne clonant que la branche à builder, voir même que les derniers commits de la branche en question. C'est ce que fait travis par exemple (avec ). On peut même aller plus loin avec les sparse checkout.

le merge request proposant un nouveau nom à eu une réponse via le bug tracker

La réponse vient d'une personne qui n'est pas un des développeurs de weboob et qui regrette l'absence de réponse :

I have no power here and I am a bit sad your ticket has no answer

Bref, on adapte la "règle" pour que ça rentre dans le "acceptable" en faisant de sorte que ça passe pour ce qu'on aime et que ça ne passe pas pour ce qu'on n'aime pas.

Non, je n'adapte pas la règle. Oui, c'est un plus pour un projet que d'être dans les dépôts standard, mais ce n'est pas pour autant que c'est de la censure que d'exclure un projet.

Si je prends un parallèle : sur LinuxFr.org, on refuse les dépêches qui parlent de logiciels propriétaires avec peu de rapport avec Linux. Je ne considère pas ça comme de la censure, vu que ces logiciels peuvent faire trouver d'autres endroits pour parler d'eux. Et pourtant, je suis convaincu que ça serait un plus pour ces projets que d'être cités sur LinuxFr.org (c'est un bon relai pour toucher certains publics).

Je ne considère pas que Debian soit l'autorité compétente sur les publications, émissions et spectacles destinés au public. Debian fournit de base les outils pour utiliser des dépôts tiers et n'a mis en place aucune restriction pour empêcher un dépôt tiers de fournir weboob. Debian ferait de la censure s'ils empêchaient d'avoir weboob sur les ordinateurs qui tournent avec Debian, ce qui n'est pas le cas ici.

Mes affirmations s'appuient sur ce mail de Ian Jackson (ancien Debian Project Leader) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199;msg=32. je cite :

Well, others have definitely been trying that. There is an issue in
the upstream tracker (mentioned in the footnote of Niels's message);
https://git.weboob.org/weboob/devel/issues/154

This was reported in early August and has had no responses from the
upstream maintainers, despite several pings from other people. I
think it is clear that upstream are aware of the complaint but are not
dealing with it (perhaps because it's no fun, or perhaps as deliberate
strategy).

[…]

So it's true that we don't know for sure what upstream's current view
is on this situation, but that's not because no-one has tried to talk
to them about it.

[…]

l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse

En fait, il y a aussi cette entrée sur le bugtracker de weboob : https://git.weboob.org/weboob/devel/issues/154

Ils ont accepté les merge request pour virer les insultes; je n'appelle pas ça aucun effort.

Je n'ai pas été très clair :

• l'équipe Debian n'a pas fait cette merge request, j'ai mis la merge request que pour illustrer les commentaires litigieux
• l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse
• par aucun effort, je voulais dire que les développeurs de Weboob n'ont fait aucun effort pour collaborer avec l'équipe Anti harrasement de Debian.

les distros sont de plus en plus lisse, et acceptent de moins en moins l'humour

Dans le cas de weboob, on peut difficilement qualifier ça d'humour. L'article l'explique mal mais la décision de Debian ne s'appuie pas sur le nom weboob et les logos associés. Quand la question avait initialement été levée, Debian avait d'abord choisi de conserver le paquet. En parallèle, l'équipe Anti-Harassment de Debian a essayé de travailler avec les développeurs de weboob pour améliorer les choses. Ils ont suggéré de trouver un autre nom (mais ça restait une simple suggestion, pas une obligation ou une menace) et surtout il y a eu une demande pour retirer des commentaires homophobes du code (cf https://git.weboob.org/weboob/devel/merge_requests/228/diffs). Les développeurs de weboob n'ont fait aucun effort, pas même de répondre à l'équipe Debian pour leur donner leur point de vue. Et c'est tout ce contexte ensemble qui a mené à inverser la décision et à retirer le paquet de Debian.

Je ne sais pas quel a pu être le problème, mais le journal est maintenant en ligne ici : https://linuxfr.org/users/maxima/journaux/ikos-un-analyseur-statique-developpe-a-la-nasa

LinuxFr.org n'utilise plus les gravatars. Pour modifier son avatar, il suffit de le changer dans les préférences.

Redo est une autre alternative à Make. Je serais curieux d'avoir l'avis de l'auteur de smk pour comparer les deux. Par exemple, est-ce que smk s'appuie uniquement sur le mtime pour savoir si un fichier a été modifié depuis la dernière exécution d'une commande ? L'auteur de redo considère cela comme étant fragile : https://apenwarr.ca/log/20181113.

Sinon, j'ai vu passer https://github.com/jacereda/fsatrace qui pourrait aider l'auteur :

This tool injects code into other applications in order to trace file accesses. This can be useful for things like build systems, since it allows to automatically generate dependencies in a toolchain-agnostic way or to ensure declared dependencies match the real ones.

En fait, c'est volontaire, j'avais eu pas mal de retours de personnes qui voulaient plus de densité pour les liens que pour les autres contenus. C'est aussi le cas sur la page d'accueil pour les personnes qui ont activé les liens sur leur page d'accueil via les préférences.

Ça va dépendre des langages, mais certains autorise les types unions. Ici, ça dira que ça retourne soit une chaîne de caractères, soit un entier, soit null. J'imagine que d'autres langages peuvent essayer de trouver un ancêtre commun, genre Object (je n'ai pas d'exemple d'un tel langage en tête). Enfin, certains langages vont juste donner une erreur à la compilation.

Globalement, ça dépend surtout de la manière dont les types sont définis par le langage, pas vraiment de l'inférence de type. Même sur un tel exemple, le type donné par l'inférence de type sera très certainement le même que celui qu'un humain aurait donné.

Essaye de faire un apt install libsodium-dev en root. Je dirais que c'est une bibliothèque en C dont thrussh-libsodium est un wrapper et que cette dépendance de pijul a donc besoin de trouver la bibliothèque en question.