[SPIP Zone] [git.spip.net] Gestion des notifications

Archives Zone
1

Hello,

En tant que mainteneur/contributeur de plugins sur la zone, je reçois des rapports de bogues en 3 endroits différents : sur le forum du plugin sur contrib (si l'article existe), sur la zone, ou par IRC.
On n'a pas toujours le temps de s'en occuper tout de suite, et passé un certain temps c'est compliqué de les retrouver, ça se perd.

Sur gitea il y a une vraie gestion des tickets pour chaque dépôt, ça me semble l'endroit idéal pour y reporter les bogues qu'on me signale. Je ne parle pas pour l'instant d'en faire l'endroit officiel pour le rapport de bogues par les utilisateur.ices, mais bien un truc à l'initiative des dévelopeur.e.s s'ils veulent un outil pratique pour gérer les tickets de leurs plugins.

Problème : tel que configuré actuellement, *tous* les comptes utilisateurs de l'orga « plugin » reçoivent des notifications à la moindre activité sur n'importe quel dépôt. J'ai créé un ticket ce matin pour tester, quelqu'un s'est déjà plaint du bruit sur l'irc :stuck_out_tongue:
Si à un moment les tickets ou le wiki commencent à être utilisés, ça va générer beaucoup de bruit inutile pour tout le monde.

Est-ce qu'il ne serait pas possible de faire de l'opt-in, plutôt que d'abonner tout le monde à tous les dépôts par défaut ?
Les gens ne recevraient des notifs que des dépôts qui les intéressent, à leur initiative.
Je ne sais pas ce qu'il en est pour gitea, il semble possible de régler dépôt par dépôt : bouton « suivre / ne plus suivre » en haut à droite.

2

Bonjour

Le temps de trouver une solution adaptée, j'ai pour le moment fait
simple : aucun wiki, aucun ticket sur l'ensemble des projets hébergés
sur git.spip.net
Seuls le code l'organisation "SPIP" a une gestion dédiée de ticket et
de wiki via core.spip.net

Jusqu'à présent le comportement était import d'un projet de la zone
avec activation des différentes fonctionnalités dont le wiki et
tickets. Comme jusqu'à présent personne n'avait vraiment testée ces
fonctionnalités je n'avais pas constaté le problème de "spam".
Ce comportement est logique mais non pertinent du fait que toute
personne inscrite sur la forge git obtient le même niveau
d'autorisation que sur la zone. C'est à dire qu'il est possible de
contribuer en direct à n'importe quel code présent dans les
organisations plugin/contrib/galaxie.
Pour info, le comportement par défaut, on n'a qu'un droit de lecture
avec possibilité de faire de PR via un fork et seul les admins peuvent
valider les PR. Dans notre cas ces droits ont été élargis pour se
rapprocher du mode "open bar" de la zone (permettant de commiter en
direct et/ou valider les PR).

Pour le moment il n'est pas possible globalement de dissocier
l'appartenance aux organisations et aux notifications.
Je suis en train de regarder pour trouver une solution qui pourrait
permettre l'activation du wiki et ticket au cas par cas sans notifier
tout le monde. Et en évitant de demander à tout le monde de cliquer
sur le bouton « suivre / ne plus suivre » dépôt par dépôt :slight_smile:

Km

3

Hop,

Le 10/09/2019 à 12:28, cam.lafit@azerttyu.net a écrit :

Pour le moment il n'est pas possible globalement de dissocier
l'appartenance aux organisations et aux notifications.

Est-ce que cette valeur de config ne serait pas la solution ?

AUTO_WATCH_NEW_REPOS: true: Enable this to let all organisation users watch new repos when they are created

cf https://docs.gitea.io/en-us/administration/config-cheat-sheet/

Si on supprime toutes les entrées "watcher" pour les membres de l'orga "zone" et qu'on active cette option, on devrait pouvoir activer les tickets sur chaque projet de l'orga sans spammer tout le monde ?

++
b_b

4

Yop

Est-ce que cette valeur de config ne serait pas la solution ?

AUTO_WATCH_NEW_REPOS: true: Enable this to let all organisation users
watch new repos when they are created

cf https://docs.gitea.io/en-us/administration/config-cheat-sheet/

Eheheh bien vu.
J'ai activé l'option et relancer la forge, à voir lors des prochaines création.

Si on supprime toutes les entrées "watcher" pour les membres de l'orga
"zone" et qu'on active cette option, on devrait pouvoir activer les
tickets sur chaque projet de l'orga sans spammer tout le monde ?

Je viens de retirer globalement tous les observateurs. Je n'ai pas
moyen d'avoir plus de finesse (absence d'api pour ce cas de figure).
Les personnes qui avaient fait l'action manuelle se remettre
observateur, désolé.

Pour le test je viens de rétablir les fonctionnalités sur

Km

Le mar. 10 sept. 2019 à 13:55, Bruno Bergot <bruno@eliaz.fr> a écrit :

Hop,

Le 10/09/2019 à 12:28, cam.lafit@azerttyu.net a écrit :
>
> Pour le moment il n'est pas possible globalement de dissocier
> l'appartenance aux organisations et aux notifications.

Est-ce que cette valeur de config ne serait pas la solution ?

AUTO_WATCH_NEW_REPOS: true: Enable this to let all organisation users
watch new repos when they are created

cf https://docs.gitea.io/en-us/administration/config-cheat-sheet/

Si on supprime toutes les entrées "watcher" pour les membres de l'orga
"zone" et qu'on active cette option, on devrait pouvoir activer les
tickets sur chaque projet de l'orga sans spammer tout le monde ?

++
b_b

5

Le 10/09/2019 à 14:21, cam.lafit@azerttyu.net a écrit :

Je viens de retirer globalement tous les observateurs. Je n'ai pas
moyen d'avoir plus de finesse (absence d'api pour ce cas de figure).
Les personnes qui avaient fait l'action manuelle se remettre
observateur, désolé.

Pour le test je viens de rétablir les fonctionnalités sur
Connexion · GitLab

Top, j'ai vérifié sur quelques dépôts, effectivement je ne suis plus observateur sur aucun.

Par contre comme le signalait b_b sur irc, il doit rester un truc à vider : le nombre de watchers affiché n'a pas été réinitialisé, et quand on clique dessus on arrive sur une liste vide mais il y a une pagination.

Merci pour la réactivité :slight_smile:

6

Bonjour,

Si on on veut suivre un dépôt en cliquant sur "suivre" on tombe sur une erreur 500

7

Le 10/09/2019 à 11:51, Charles Razack a écrit :

Est-ce qu'il ne serait pas possible de faire de l'opt-in, plutôt que d'abonner tout le monde à tous les dépôts par défaut ?
Les gens ne recevraient des notifs que des dépôts qui les intéressent, à leur initiative.

Pour ma part, j'aimerais qu'on garde le fonctionnement actuel de la zone SVN qui permet de s'abonner à la liste de diffusion (et à son miroir newsgroup) de tous les commits de tous les plugins.
Ça me parait indispensable.

--
nicod_

8

Bonjour

Le 10/09/2019 à 11:51, Charles Razack a écrit :
> Est-ce qu'il ne serait pas possible de faire de l'opt-in, plutôt que
> d'abonner tout le monde à tous les dépôts par défaut ?
> Les gens ne recevraient des notifs que des dépôts qui les intéressent, à
> leur initiative.

Pour ma part, j'aimerais qu'on garde le fonctionnement actuel de la zone
SVN qui permet de s'abonner à la liste de diffusion (et à son miroir
newsgroup) de tous les commits de tous les plugins.
Ça me parait indispensable.

Pour le moment pas de changement sur ce point. C'est svn qui gère
cette partie là (IRC , liste de diffusion sont notifiés dès que le
commit est importé).
La question pourra se poser si on décide à un moment de couper le svn.
De prime abord, je vois plusieurs solutions dont la création d'un
utilisateur "liste de diffusion" qu'on abonnerait à tous les dépôts ou
bien un hook déployé sur tous les dépôts (dans le même esprit que pour
le svn, c'est une histoire de passage à l'échelle). Je dois dire que
je n'ai pas regardé en détail.

Km

9

Le 10/09/2019 à 18:43, cam.lafit@azerttyu.net a écrit :

Pour ma part, j'aimerais qu'on garde le fonctionnement actuel de la zone
SVN qui permet de s'abonner à la liste de diffusion (et à son miroir
newsgroup) de tous les commits de tous les plugins.
Ça me parait indispensable.

Pour le moment pas de changement sur ce point. C'est svn qui gère
cette partie là (IRC , liste de diffusion sont notifiés dès que le
commit est importé).

Je pensais aussi à des plugins qui pourraient n'être QUE en git, d'un seul côté donc.
Mais tu fais peut être la synchro vers svn dans ce cas là aussi ?
D'ailleurs, cette synchro git <-> svn, elle est totalement bidirectionnelle et automatique ?

--
nicod_

10

Bonjour

Si on on veut suivre un dépôt en cliquant sur "suivre" on tombe sur une
erreur 500

C'est corrigé. On peut se mettre observateur.

Par contre comme le signalait b_b sur irc, il doit rester un truc à
vider : le nombre de watchers affiché n'a pas été réinitialisé, et quand
on clique dessus on arrive sur une liste vide mais il y a une pagination.

Le cache a été purgé le compte devrait être bon maintenant.

Km

11

Salut

Le 10/09/2019 à 18:43, cam.lafit@azerttyu.net a écrit :
>> Pour ma part, j'aimerais qu'on garde le fonctionnement actuel de la zone
>> SVN qui permet de s'abonner à la liste de diffusion (et à son miroir
>> newsgroup) de tous les commits de tous les plugins.
>> Ça me parait indispensable.
>
> Pour le moment pas de changement sur ce point. C'est svn qui gère
> cette partie là (IRC , liste de diffusion sont notifiés dès que le
> commit est importé).

Je pensais aussi à des plugins qui pourraient n'être QUE en git, d'un
seul côté donc.

Ce cas n'est pas (encore) traité

Mais tu fais peut être la synchro vers svn dans ce cas là aussi ?

Oui pour le moment la création d'un projet communautaire depuis
git.spip.net implique la traduction vers le svn.
C'est le cas par exemple des codes que j'ai déposé sur

D'ailleurs, cette synchro git <-> svn, elle est totalement
bidirectionnelle et automatique ?

Oui.
Pour plus de détail :

1/ Pour les organisations communautaires (contrib/galaxie/plugin/...) :
Si c'est un plugin qui vient de la zone svn, pour être présent il doit
être importé via le script ImportOneRepository.sh (dans
Connexion · GitLab)
L'import est manuel et la synchronisation est ensuite transparente et
bidirectionnelle.
A noter que pour le moment c'est le dépôt svn qui fait référence.

Si c'est un plugin qui vient de git, pour être traduit vers le svn ,
il doit être traité via ExportToSvn.sh ((dans
Connexion · GitLab). Les commits seront
d'abord exportés vers la zone puis la synchronisation sera activée.

Dans les 2 cas, s'il y a une divergence (incident réseau, plantage
divers et varié, ....) de commits, par défaut c'est la zone qui
l'emporte.
Si pour un projet il y a une préférence git je conseille de l'indiquer
explicitement dans un LISEZ.MOI comme j'ai pu le faire sur

Enfin l'automatisme est différents selon le sens :
* svn > git c'est un cron qui effectue le report des commits (ce n'est
pas instantannée)
* git > svn c'est au git push que la synchronisation est effectuée
pour chaque commit.
Remarque : Avant de pousser les commits vers le svn, il y a contrôlet
et import du svn. On a alors un classique local git pull --rebase ,
comme si un autre utilisateur avait commité entre temps du code)

2/ Pour les forks et projets personnels
Ce sont des dépôts git standards. Il ne seront pas traduits en svn ni
dans un sens ni dans l'autre.

Km

12

On 10/09/2019 19:10, cam.lafit@azerttyu.net wrote:

Bonjour

Si on on veut suivre un dépôt en cliquant sur "suivre" on tombe sur une
erreur 500

C'est corrigé. On peut se mettre observateur.

Merci