Adrien Dorsaz a écrit 900 commentaires

Super, merci pour la clôture et pour l'assignation :)

1) veux-tu être admin ?

Merci, mais je ne voudrais pas être admin, parce que ça active beaucoup trop de droits sur le site.

2) modifier le système pour choisir parmi les admins ou ceux ayant déjà eu un ticket attribué et un compte encore ouvert (ça résoudrait pas la première fois, juste les suivantes)

Ça c'est une idée intéressante, je vais regarder pour essayer de proposer une modification de ce genre.

Mais, si je ne me trompe pas, on pourrait aussi créer un rôle "mainteneur" qui ajoute juste la gestion du système de suivi à un utilisateur. Ça serait plus propre, mais je me demande si ça compliquerait trop la vie aux admins du site ?

Si je me souviens bien, rms avait vu ce problème de sémantique pour le terme "logiciel propriétaire" et il avait proposé "logiciel privateur [de libertés d'usage]".

Je pense que tu as raison et que " logiciel libre" a exactement le même problème de sémantique.

On pourrait l'appeler "logiciel libérateur [d'usage]".

Comme ça on a une sémantique cohérente pour les 2 opposés : logiciel privateur VS logiciel libérateur 😀

idle n'est pas un mot réservé au CPU, le nom va bien 😉

Pour le cas des contenus cachés, on pourrait utiliser la gem counter_culter qui permet de mettre à jour le cache aussi sur des mises à jour de valeur.

Hello !

J'ai trouvé la solution et j'ai proposé la modification ici: https://github.com/linuxfrorg/linuxfr.org/pull/289

Il est à noter que le compteur garde dans son compte les contenus "supprimés":

En effet, les contenus ne sont pas vraiment supprimés, mais uniquement cachés et du coup les méthodes de callback de counter_cache ne sont pas appelées.

D'un côté, ça serait logique d'enlever les contenus supprimés des compteurs, car ils ne sont plus accessibles.

Mais d'un autre côté, ça voudrait dire que l'on doit supprimer les tags au moment où on supprime le contenu et, du coup, on ne pourrait plus "restaurer" en l'état le contenu en changeant le flag node.public à true.

C'est la comparaison qui me fait rire, elle n'est pas honnête.

Je n'excuse ni les constructeurs, ni Google, ni ARM. Je relève les points qui font que ta comparaison me semble ridicule.

Tout à fait, les lois peuvent faire avancer les choses, mais en même temps, la loi a imposer la recharge par USB et Apple n'en avait rien à faire…

Ça me fait vraiment rire de comparer Apple qui a un parc déterminé et fini de SoC ARM et de firmware sur le marché et Google qui n'a aucune maîtrise des SoC et firmware et qui en a potentiellement un nombre de combinaison infini.

Si tu comparais Apple à Samsung, là j'aurai déjà mieux compris, mais ça ne va pas aussi: Samsung ne maîtrise pas du tout ce qu'il y aura dans les prochaines versions d'Android.

Si ARM standardise le démarrage du matériel et la découverte du matériel, ça aidera déjà beaucoup : il n'y aurai plus besoin de build un noyau custom juste pour son matériel… Ça marche très bien avec les "compatible PC".

Ensuite, Google devrait avoir un développement ouvert du projet AOSP et ne pas travailler en cachette pendant 1 an puis balancer les sources d'un coup. Ça doit être un travail de fou de reprendre leur OS complet chaque année et de tout tester sur son matériel. Bravo d'ailleurs aux contributeurs bde LineageOS pour ce travail !

Bref, Apple mène bien ses mises à jour, mais il maîtrise toute la chaîne du matériel à l'OS. Ils doivent juste faire attention à ne pas créer d'incompatibilités entre tout ça (jusqu'au jour où ils décident que les clients doivent repasser à la caisse, en rendant l'OS moins performant artificiellement sur les vieux périphériques).

C'est ça, ça va arriver, mais pas aussi vite que prévu.

Pour 2024, si j'étais à la place d'IdenTrust, je ferai la moue d'utiliser encore un certificat racine expiré (il est valide jusqu'en septembre 2021 théoriquement) pour créer de nouvelles signatures. En plus, ça pourrait réduire la confiance des systèmes dans leur gestion des certificats.

Par contre, je pense que le parc de téléphone Android aura déjà largement migrer vers des versions olus récentes que la 7.1.

Il y a un graphe sur Wikipedia si je me souviens bien qui montre l'évolution du parc, c'est assez intéressant.

C'est impressionnant comment le parc évolue vite. Je me dis qu'il doit y avoir beaucoup de gâchis de matériel à cause des techniques de ventes des constructeurs et de l'irrationalité des clients…

Wow, merci pour ces précisions, je n'avais jamais réfléchi à ces notions et là ça me paraît beaucoup plus claire !

Je pense d'ailleurs que je fais parti de ces utilisateurs qui ne comprennent pas tout 😅

Je comprends mieux pourquoi il y a un menu pour la taille de l'impression qui ne change rien à la visualisation de l'image sur l'écran, c'est tellement logique maintenant 😂 En plus, je pouvais ne voir aucune différence, même à l'impression si mon imprimante n'a pas un DPI assez élevé.

Ça serait peut être un bon endroit où on pourrait placer une petite aide à l'utilisateur pour l'éduquer un peu.

Bon, finalement, j'ai trouvé un peu de temps et de motivation pour voir comment faire des emails et des tâches automatique.

J'ai décrit un système de notification et de suppression automatique, dans un commentaire plus bas, je propose de continuer la discussion là-bas.

Voilà, si ça vous dit, j'ai préparé un commit pour ajouter 2 tâches cron exécutées quotidiennement:

1. Une première tâche qui repère quand un brouillon de dépêche n'a pas été mise à jour depuis 5 mois et 2 semaines
   • Cette tâche envoie un email de relance comme les animateurs peuvent le faire et ajoute le message: La dépêche semble abandonnée et sera automatiquement supprimée dans 2 semaines si aucune modification n'y est apportée.
   • Ce même message est publié sur la tribune de la dépêche
2. Une seconde tâche qui prend tous les brouillons de dépêche dont la dernière modification remonte à plus de 6 mois
   • Elle passe la dépêche de l'état "brouillon" à "supprimé"
   • Elle envoie un email à l'auteur (et, en copie, l'équipe de modération) expliquant que la suppression est automatique et joint le contenu de la dépêche

Si vous pensez que ça peut être utile, dites-le moi et je ferai un Pull Request sur Github.

Je pense que si on a ce système automatique, il n'y a plus besoin de mon autre proposition de "cacher" les vieux contenus, puisqu'il ne restera que les "frais" (moins de 6 mois d'abandon).

Je viens de voir que l'on a des template de réponses pour les dépêches refusées et il y en a déjà une pour "Dépêche abandonnée" avec ce texte:

La dépêche que vous avez proposée est restée très longtemps dans l’espace de rédaction collaboratif sans aucune modification alors qu’elle n’est pas terminée.

Considérant ce contenu abandonné, et pour conserver un certain dynamisme dans l’espace de rédaction collaboratif, nous préférons le refuser.

Rien ne vous empêche de le proposer à nouveau si besoin.

Je vais l'utiliser pour le cron de "nettoyage" et je peux préparer un autre template pour le cron de "relance avant nettoyage".

Oh, tout est déjà en place, ça doit être faisable en fait.

On a le système de cron dans lib/tasks/linuxfr.rake et le système d'envoi de mail dans app/mailers/news_notifications.rb.

Je vais faire quelques tests ces prochains jours 😀

Tout à fait, le but de cette proposition est juste d’éviter d’apeurer les nouveaux venus.

Pour le problème de fond, je pense que le système des animateurs prévu était bien fait. Je me souviens d’une époque où Nÿco (je crois) faisait régulièrement des relances sur les dépêches qui tombaient dans les Abymes de l’oubli avec un petit délai genre « si non suppression dans 1 semaine ».

Peut-être que la vraie solution est de rendre ça automatique en expliquant que l’espace de rédaction est un espace commun où le ménage est fait régulièrement par un script de relance et un de nettoyage.

Comme je disais plus haut, malheureusement, ça me demanderait pas mal d’investissement parce que je ne connais pas bien Ruby On Rails et je ne sais pas comment y ajouter des crons. Si je me souviens bien, il y a déjà un système en place pour recalculer le karma régulièrement, je pourrais m’en inspirer.

3 mois c'est peut-être court. Mais perso, je n'ai pas de religion dessus.

En regardant la liste actuelle, je trouvais que 3 mois ça faisait déjà pas mal de dépêches actuellement actives: toutes les dépêches mises à jour après le 12 septembre restent affichées et du coup ça fait jusqu'à la dépêche "Python pour Noël 2020 — partie 7 — Environnements virtuels" actuellement.

En complément, il faudrait peut-être prévoir d'envoyer un mail au rédacteur initial pour le prévenir que sa dépêche est passée au statut d'adoptable. Soit automatiquement, soit à faire par l'équipe d'animation de l'espace rédaction.

En fait, il n'y a pas vraiment de changement d'état, le système est très simple pour l'instant: si la dernière mise à jour date de plus de 3 mois, on cache la dépêche. Ça veut dire que, dès que quelqu'un fait la moindre modification, elle repasse en "dépêche active".

On pourrait imaginer ajouter une tâche journalière qui envoie un mail, mais j'avoue que je n'ai pas la motivation de faire 😅

En fait, je ne m'y connais pas trop en Ruby on Rails, du coup, ça me demanderait pas mal d'investissement personnellement.

C’est bien vu et ça tombe bien, parce que j’ai proposé de mettre les textes suivants comme explication:

Les dépêches suivantes n’ont plus d’activités depuis plus de 3 mois et peuvent être adoptées pour être finalisées et publiées par d’autres rédacteurs.

Pour adopter une dépêche, vous pouvez demander dans la tribune de rédaction de devenir l’auteur de la dépêche. Ainsi, l’équipe de modération vous donnera le rôle d’auteur de la dépêche et vous pourrez terminer le processus de publication.

Est-ce que ça irait ou est-ce qu’il faut préciser « la tribune de rédaction ci-contre » ?

Oh, et si tu veux tester en direct, tu peux aller sur mon site de test.

Une alternative sans doute plus compliquer à mettre en oeuvre serait d'avoir trois catégories :

dépêche en cours de rédaction
dépêche à adopter
dépêche en cours de modération

avec un passage automatique de la catégorie 1 à la catégorie 2 après x mois de non-activité.

Ça tombe bien, c’est exactement le système que j'ai proposé dans le PR: les dépêches « cachées par défaut » sont les dépêches à adopter et elles passent là après 3 mois de non-activité.

Tu as raison, il vaut mieux donner des noms un peu plus clairs, j’ai donc ajusté le titre en « 9 dépêches à adopter »:

Et quand on ouvre la catégorie, j’ai ajouté une notice pour expliquer ce que veut dire « à adopter » et en dessous un texte pour expliquer comment procéder:

Au cas où les images ne passent pas, j'ai mis les textes suivant:

Les dépêches suivantes n’ont plus d’activités depuis plus de 3 mois et peuvent être adoptées pour être finalisées et publiées par d’autres rédacteurs.

Pour adopter une dépêche, vous pouvez demander dans la tribune de rédaction de devenir l’auteur de la dépêche. Ainsi, l’équipe de modération vous donnera le rôle d’auteur de la dépêche et vous pourrez terminer le processus de publication.

Est-ce que les textes te plaisent ?

Hello,

J'ai fait une entrée de suivi pour réduire par défaut la liste affichée aux dépêches actives dans les 3 derniers mois.

J'espère que ça permettrait de réduire le bruit pour les nouveaux rédacteurs motivés.

Une fois qu’une dépêche n’a pas été modifiée durant un certain temps (6 mois ? 1 an ?), elle serait disponible à l’adoption. Ainsi, si quelqu’un est motivé, il saura que la soumission de la dépêche dépendra de lui et pas d’un auteur qui ne passe peut-être même plus sur LinuxFR.

Je ne l'ai pas fait, mais je me dis que l'on peut déjà "adopter une dépêche": il faut aller dans la tribune de la dépêche et demander à la modération soit de démarrer la publication, soit demander la paternité de la dépêche (par exemple, si la moitié a été modifiée :-)).

Hello,

Pour moi, cette dépêche est très bien: elle parle d'un sujet autour du libre et, en plus, nous fait découvrir un petit projet très intéressant.

On découvre d'ailleurs régulièrement passer ce bandeau sur la page d'accueil:

Faites vivre LinuxFr.org

Tous les articles sont le fruit du travail de la communauté. Grâce au système de rédaction coopérative du site, on peut s’aider les uns les autres. Pas besoin d’expertise pour participer.

C'est des nouvelles faites par la communauté et pour la communauté, nous n'avons pas de vocation à faire des articles totalement objectifs et de qualité journalistique 😉

Pour plus d'informations, voire la page à propos.

Un début d'explication est donné à la fin de l'annonce à propos de la future version 1.0: un des auteurs avait eu un nouveau poste de recherche académique qui l'empêchait de mener tout projet de recherche en dehors du travail (ou en tout cas qui poserait des questions juridiques).

Hello,

Ce qui m'importe dans un IDE, c'est de pouvoir m'aider avec:

• de la complétion automatique des noms des variables, commandes… ça m'évite les fautes de frappe et ça aide à voir les arguments à passer
• la recherche rapide des fichiers par noms incomplets
• la prévention des erreurs de style en me donnant des indications à jour du linter que l'on a configuré (pour nodejs, on utilise eslint et il donne beaucoup de bons conseils)
• pouvoir avoir plusieurs fichiers ouverts et affichés en même temps (les split de vim sont très bien pour ça)
• pouvoir gérer les breakpoints et démarrer une session de debug
• une fonction rechercher/remplacer qui comprend les expressions régulières
• pouvoir naviguer dans le fichier facilement (vim est particulièrement efficace avec sa pléthore de moyen de navigations *, gd, :42, /texte, e, b…)

Je me sens déjà bien à l'aise avec ces fonctionnalités.

Après, je ne me cantonne pas à rester uniquement dans mon IDE, je n'hésite pas à ouvrir d'autres onglets dans le terminal pour utiliser des commandes extérieurs (git, grep, find, docker-compose…).

Je ne souhaiterai pas que l'IDE devienne une usine à gaz et je préfère qu'il en fasse un peu moins, mais qu'il soie réactif.

J'ai eu l'occasion de travailler avec des IDE qui ont beaucoup plus de fonctionnalités, comme Eclipse et Visual Studio Entreprise avec Resharper. J'ai eu vraiment de mauvais souvenir à cause de leur consommation excessive et constante de ressources pour que, de temps en temps, je puisse faire un refactor de malade qui va toucher une dizaine de fichiers ou trouver des références dans tout le projet (ce qui soit dit en passant peut aussi très bien être fait avec grep, find, awk et sed, c'est incroyable ces outils !).

J'ai aussi eu l'occasion de travailler avec SQL Server Management Studio, où là c'est l'inverse: ce n'est quasiment qu'un éditeur de texte avec l'arborescence de la base de donnée à côté. C'était aussi clairement pas assez pour être efficace (même si on avait 1-2 plugins pour nous aider, c'était pas assez).

Là, j'ai l'impression d'avoir atteint un juste milieu avec vim, LSP et DAP.

D'ailleurs, Visual Studio Code n'en n'est pas très loin non plus, j'ai bien aimé travailler avec aussi et je les remercie d'avoir apporté LSP et DAP, c'est vraiment pratique pour tout le monde !

Par exemple, si je veux voir la liste des fichiers actuellement modifiés dans le projet avec git status, ça permet de les garder en face de moi.

Avec les versions récentes de vim, depuis le terminal intégré, tu peux repasser aux autres window de vim avec Ctrl-W + flèches et continuer à travailler avec vim tout en gardant cette liste sous les yeux.

Un autre exemple, est de faire un git grep (mais je viens de découvrir :vimgrep que je vais essayer de privilégier) ou juste un git diff pour être sûr des modifs que j'ai actuellement fait.

Je connais aussi :! ou Ctrl-Z, mais le gros désavantage est que je perd tout ce que je suis en train de faire et ça me fait perdre du temps, parce que je dois continuellement changer de contexte, alors que là, j'ai tout sous les yeux et je peux interagir avec les deux: les fichiers en cours d'édition et le résultat de ma commande.

Ah oui, j'avais vu :make, c'est sympa.

Je viens de lire le :help make et de trouver juste en dessous :vimgrep qui est bien plus efficace que git grep, puisque la liste de résultat est interactive, merci beaucoup ! Je vois que :grep permet aussi de définir sa commande, je pense que je vais la définir avec git grep, parce que c'est assez cool le respect du fichier .gitignore.

Donc en plus de ne pas rediriger vers les définitions de méthodes, j'imagine qu'il ne peut pas non plus faire l'inverse, afficher toute les utilisations dans le projet d'une méthodes, ou d'une variable.

Ce que je voulais dire, c'était ça justement: il peut te rediriger vers les définitions (LSP sait lire les include/require et te redirige), mais il ne peut pas te donner toutes les références, tant que les fichiers n'ont pas été ouvert.

Je suppose donc aussi qu'on n'a pas de complétion ou de vérification temps réel sur les méthodes existantes ou sur les paramètres passés. Et l'import automatique ?

D'expérience, la complétion fonctionne, quand tu as fais le bon import.

L'import automatique peut fonctionner si tu as déjà ouvert le fichier dans ta session.

Là, je te parle d'expérience avec un projet en nodejs, ça dépend sûrement du language server, mais ça semble assez trivial pour C++ aussi si les include ont bien été définit et que le fichier compile_commands.json a bien été construit.

Ce qui me semble quand même des fonctions de base que j'utilise beaucoup même sur des petits projets.

Si tu veux avoir ces fonctionnalités complètes, je pense que tu es obligé de passer par un scan complet des fichiers du projet et des dépendances, de tous les parser et de faire tenir ces informations en mémoire ou dans des indexes.

Peut être qu'un plugin asynchrone (merci pour l'info barmic ;)) pour vim existe pour faire ça, mais je préfère me passer de ce genre de fonctionnalités, car je sais qu'elles seront bien trop consommatrices de ressources (CPU, mémoire et I/O disques).