est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
Le 26 oct. 2017 à 10:37, Pierre KUHN <pierrekuhn82@gmail.com> a écrit :
Bonjour à tous,
Le cron fonctionne, je l'ai surveiller dernièrement avec le rajout de la 3.2, il faut peut être traité plus de plugins ou bien géré des dates.
Quel plugins n'est pas à jour sur contrib ?
Le 26 octobre 2017 à 10:18, Maïeul <maieul@maieul.net> a écrit :
Salut à toutes et tous,
Connexion · GitLab
est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
Je pense qu'il faudrait amélioré Connexion · GitLab
A ton besoin de garder la synchro sur les version 2.0 et 2.1 ?
On pourrait pas mettre un tri sur la compatibilité inversé ? Avoir en premier les 3.2 avec la date en tri aussi ?
a mon avis il faut raisonner par date de mise à jour, pas par numero de version. Car raisonner par numéro de version nous obligerait à penser à faires des modifis à chaque nouvelle version majeure.
De plus cela ne résoudrait pas le problème des informations pas mis à jour à cause du tirage au sort
est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
++
Autre point, j'ai l'impression qu'en ce qui concerne les zip, cela bug.
cela m'a ajouté un document 14517 au lieu de mettre à jour le 11852 (que j'ai supprimé depuis)
Ou tout simplement que dans le code on a pas défini l'id_mot qui correspond à la compta 3.2 ?
Cédric
Le 4 nov. 2017 à 11:36, Maïeul <maieul@maieul.net> a écrit :
Le 26.10.17 à 10:18, Maïeul a écrit :
Salut à toutes et tous, Connexion · GitLab est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
++
Autre point, j'ai l'impression qu'en ce qui concerne les zip, cela bug.
(et cela marche parfois, donc c’est bien le bon idée, et c’est bien up sur contrib)
Le 4 nov. 2017 à 12:13, Cédric Morin <cedric@yterium.com> a écrit :
Ou tout simplement que dans le code on a pas défini l'id_mot qui correspond à la compta 3.2 ?
Cédric
Le 4 nov. 2017 à 11:36, Maïeul <maieul@maieul.net> a écrit :
Le 26.10.17 à 10:18, Maïeul a écrit :
Salut à toutes et tous, Connexion · GitLab est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
++
Autre point, j'ai l'impression qu'en ce qui concerne les zip, cela bug.
Hello
Pour le problème de compatibilité, je sais pas !
Par contre, concernant le zip qui à été ajouter plutôt que de mettre à jour celui existant, il y a de grande chance que le zip était en .org et ce qui ce passe, c'est que le robot les refait en .net sans supprimer les anciens.
Donc, je fais le ménage, mais je suis tombé sur un bug
Franck
-----Message d'origine-----
De : Maïeul Rouquette [mailto:maieul@maieul.net]
Envoyé : samedi 4 novembre 2017 12:16
À : Cédric Morin <cedric@yterium.com>
Cc : spip-zone@rezo.net
Objet : Re: [SPIP Zone] Mise à jour automatique des informations sur les plugins dans contrib
Nop
(et cela marche parfois, donc c’est bien le bon idée, et c’est bien up sur contrib)
Le 4 nov. 2017 à 12:13, Cédric Morin <cedric@yterium.com> a écrit :
Ou tout simplement que dans le code on a pas défini l'id_mot qui correspond à la compta 3.2 ?
Cédric
Le 4 nov. 2017 à 11:36, Maïeul <maieul@maieul.net> a écrit :
Le 26.10.17 à 10:18, Maïeul a écrit :
Salut à toutes et tous, Connexion · GitLab est censé mettre à jour automatiquement les informations sur les plugins (version, compatibilités) sur contrib.
Mais c'est la deuxième fois en deux semaines que je recois un courriel d'utilisateur·trice qui pense que le plugin n'est pas compatible 3.2 alors qu'il l'est.
Je vois plusieurs explications possible à ce bug:
- le genie n'est pas appelée
- le genie ne fonctionne pas car contrib n'arrive pas à récupérer l'url distante (https?)
- le fait qu'on tire les au hasard les plugins mis à jour est pas terrible car on a trop de plugins par rapport au nombre qu'on met à jour.
Dans ce cas il y a trois solutions possibles:
- augmenter encore le nombre de plugin mis à jour à chaque round
- ne pas tirer aux hasard les plugins mais les prendre suivant un certain ordre (par ex alphabetique) en se rappellant d'une fois sur l'autre où on s'était arrêté
- modifier le json https://contrib.spip.net/ pour qu'il renvoie pour chaque plugins le date de dernière mis à jour et modifier uniquement les plugins mis à jour depuis le dernier cron.
Avant de se pencher sur la dernière option, est-ce qu'un webmestre de contrib pourrait regarder les logs de contrib pour voir ce qu'il en est des 2 premières possibilités?
++
Autre point, j'ai l'impression qu'en ce qui concerne les zip, cela bug.
