[SPIP Zone] github et pull-request en attente

Bonjour,

Une question se pose lorsqu'un plugin SPIP est hébergé sur github et que
le proprio du dépot ne répond pas aux pulls request

exemple :

https://github.com/cahri/spip-logo-svg/pulls

2 pulls request sont en attente et l'auteur ne répond pas. J'ai essayé
de le contacter via le forum du plugin dans contrib.

Quelle solution apporter :

- On le fork sur la zone ?

- On le fork dans son coin (bof bof bof et encore bof)

- Autre idée ?

--
A bientôt,
tofulm

Le 06.06.17 à 15:43, tofulm a écrit :

Bonjour,

Une question se pose lorsqu'un plugin SPIP est hébergé sur github et que
le proprio du dépot ne répond pas aux pulls request

exemple :

Pull requests · julienmru/spip-logo-svg · GitHub

2 pulls request sont en attente et l'auteur ne répond pas. J'ai essayé
de le contacter via le forum du plugin dans contrib.

Quelle solution apporter :

- On le fork sur la zone ?

- On le fork dans son coin (bof bof bof et encore bof)

- Autre idée ?

tu as contact uniquement via github ou tu as essayé un mail direct?
je dirais que forker sur le futur dépôt git de la zone pourrait être pas mal. On gardera ainsi la possibilité de récuperer les pull request.

--
Maïeul

Je l'ai contacté aussi via spip contrib

Le 06/06/2017 à 15:49, Maïeul a écrit :

Le 06.06.17 à 15:43, tofulm a écrit :

Bonjour,

Une question se pose lorsqu'un plugin SPIP est hébergé sur github et que
le proprio du dépot ne répond pas aux pulls request

exemple :

Pull requests · julienmru/spip-logo-svg · GitHub

2 pulls request sont en attente et l'auteur ne répond pas. J'ai essayé
de le contacter via le forum du plugin dans contrib.

Quelle solution apporter :

- On le fork sur la zone ?

- On le fork dans son coin (bof bof bof et encore bof)

- Autre idée ?

tu as contact uniquement via github ou tu as essayé un mail direct?
je dirais que forker sur le futur dépôt git de la zone pourrait être
pas mal. On gardera ainsi la possibilité de récuperer les pull request.

--
A bientôt,
tofulm

Tu le forkes sur github.

git est fait pour forker facilement. Profites-en, c’est dans sa nature !

C’est ce que j’ai fait, mais dans ce cas, la communauté SPIP ne profite pas des modifs, et surtout si ces modifs impactent d’autres plugins.

Le 07/06/2017 à 17:37, tofulm a écrit :

C'est ce que j'ai fait, mais dans ce cas, la communauté SPIP ne profite pas des modifs, et surtout si ces modifs > impactent d'autres plugins.

Les forks git forment un brouillard de versions
L'infrastructure spip doit elle référencer chaque gouttelette de ce brouillard
en considérant que chaque fork est un plugin différent ?
Doit elle seulement référencer les versions les plus intéressantes de ce nuage de forks,
en les considérant chacune comme un plugin différent ?
Ou bien en les considérant, via un nouveau formalisme déclaratif,
comme des versions différentes d'un même plugin ?

Ou bien faudrait il qu'il y ait UN repo git géré par la communauté,
qui serve de hub ou plateforme intermédiaire et centralisatrice
pour merger les best approved push requests en provenance des différents forks et repos
afin de les proposer, recommandés par défaut, à tous les SPIP ?

JL

Le 07/06/2017 à 17:34, Gilles Vincent a écrit :

Tu le forkes sur github.
git est fait pour forker facilement. Profites-en, c'est dans sa nature !

2017-06-06 15:43 GMT+02:00 tofulm <tofulm@gmail.com <mailto:tofulm@gmail.com>>:

    Bonjour,

    Une question se pose lorsqu'un plugin SPIP est hébergé sur github et que
    le proprio du dépot ne répond pas aux pulls request

    exemple :

    Pull requests · julienmru/spip-logo-svg · GitHub

    2 pulls request sont en attente et l'auteur ne répond pas. J'ai essayé
    de le contacter via le forum du plugin dans contrib.

    Quelle solution apporter :

    - On le fork sur la zone ?

    - On le fork dans son coin (bof bof bof et encore bof)

    - Autre idée ?

    --
    A bientôt,
    tofulm

    ----
    spip-zone@rezo.net <mailto:spip-zone@rezo.net> - http://listes.rezo.net/mailman/listinfo/spip-zone
    <http://listes.rezo.net/mailman/listinfo/spip-zone&gt;

--
A bientôt,
tofulm

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Salut

Pour la partie git vers svn, le fonctionnement sera grosso modo :
* fork ou mirroir du projet d'origine vers le dépôt git spip (partie _plugins_)
* detection du nouveau depot
* création du nouveau repertoire dans le svn
* import

Il n'y aura qu'un plugin reférent, peu importe quel fork, mais un seul
pourra être géré pour la zone.

Km

2017-06-07 18:00 GMT+02:00 JLuc <jluc@no-log.org>:

Le 07/06/2017 à 17:37, tofulm a écrit :

C'est ce que j'ai fait, mais dans ce cas, la communauté SPIP ne profite
pas des modifs, et surtout si ces modifs > impactent d'autres plugins.

Les forks git forment un brouillard de versions

Je ne suis pas d'accord.
Chacun devrait être capable d'aller chercher un fork plus à jour qu'un
plugin non maintenu sur la zone.

L'infrastructure spip doit elle référencer chaque gouttelette de ce
brouillard

D'accord là-dessus, la zone sert de référent.

en considérant que chaque fork est un plugin différent ?
Doit elle seulement référencer les versions les plus intéressantes de ce
nuage de forks,
en les considérant chacune comme un plugin différent ?

Non

Ou bien en les considérant, via un nouveau formalisme déclaratif,
comme des versions différentes d'un même plugin ?

Ou bien faudrait il qu'il y ait UN repo git géré par la communauté,
qui serve de hub ou plateforme intermédiaire et centralisatrice
pour merger les best approved push requests en provenance des différents
forks et repos
afin de les proposer, recommandés par défaut, à tous les SPIP ?

Je ne vois pas l'intérêt de centraliser des déclinaisons.
Par contre, c'est aux mainteneurs des plugins d'accepter ou non les push
request (voire d'intégrer ce qu'ils considèrent de cool dans les forks de
leur plugin)

.Gilles

JL

Le 07/06/2017 à 17:34, Gilles Vincent a écrit :

Tu le forkes sur github.
git est fait pour forker facilement. Profites-en, c'est dans sa nature !

2017-06-06 15:43 GMT+02:00 tofulm <tofulm@gmail.com <mailto:
tofulm@gmail.com>>:

    Bonjour,

    Une question se pose lorsqu'un plugin SPIP est hébergé sur github et
que
    le proprio du dépot ne répond pas aux pulls request

    exemple :

    Pull requests · julienmru/spip-logo-svg · GitHub <
https://github.com/cahri/spip-logo-svg/pulls&gt;

    2 pulls request sont en attente et l'auteur ne répond pas. J'ai
essayé
    de le contacter via le forum du plugin dans contrib.

    Quelle solution apporter :

    - On le fork sur la zone ?

    - On le fork dans son coin (bof bof bof et encore bof)

    - Autre idée ?

    --
    A bientôt,
    tofulm

    ----
    spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
http://listes.rezo.net/mailman/listinfo/spip-zone
    <http://listes.rezo.net/mailman/listinfo/spip-zone&gt;

--
A bientôt,
tofulm

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

Le 08/06/2017 à 12:32, Gilles Vincent a écrit :

Je ne suis pas d'accord.
Chacun devrait être capable d'aller chercher un fork plus à jour qu'un plugin non maintenu sur la zone.

1000 fois pas d'accord, c'est une idéologie individualiste du chacun dans son coin. Et d'autant plus que c'est pas aux pauvres gens de savoir fouiller et trouver le fork caché plus à jour que la version qui était celle de référence. On n'a pas à leur demander ça et personne n'a le temps pour ça, ça embête tout le monde.

Depuis le début dans SPIP, on a une idéologie qui est de partager et de travailler en commun. En commun. En se parlant, en débattant. En maintenant ensemble des biens communs sans doublonner partout parce que untel ou unetelle a fait un caca nerveux ou son jeu perso.

Le fork ou doublon peut arriver comme partout quand il y a trop de grosses différences, mais ça devrait être un événement exceptionnel. Pas la norme.

--
RastaPopoulos

Le 08.06.17 à 17:59, RastaPopoulos a écrit :

Le 08/06/2017 à 12:32, Gilles Vincent a écrit :

Je ne suis pas d'accord.
Chacun devrait être capable d'aller chercher un fork plus à jour qu'un
plugin non maintenu sur la zone.

1000 fois pas d'accord, c'est une idéologie individualiste du chacun
dans son coin. Et d'autant plus que c'est pas aux pauvres gens de savoir
fouiller et trouver le fork caché plus à jour que la version qui était
celle de référence. On n'a pas à leur demander ça et personne n'a le
temps pour ça, ça embête tout le monde.

Depuis le début dans SPIP, on a une idéologie qui est de partager et de
travailler en commun. En commun. En se parlant, en débattant. En
maintenant ensemble des biens communs sans doublonner partout parce que
untel ou unetelle a fait un caca nerveux ou son jeu perso.

Le fork ou doublon peut arriver comme partout quand il y a trop de
grosses différences, mais ça devrait être un événement exceptionnel. Pas
la norme.

je rejoins Rastapopoulos et JLuc pour le coup. Il faut que nous ayions des points de références communautaires.
C'est justement le problème de github, de fonctionner par individu et pas par projets. Du coup quand une personne n'est plus dispo (pour x raison) comme dans le cas au début -> cela coince.

Maintenant, concrètement on fait quoi?

--
Maïeul

Le 08/06/2017 à 17:59, RastaPopoulos a écrit :

Le fork ou doublon peut arriver comme partout quand il y a trop de grosses différences, mais ça devrait être un événement exceptionnel. Pas la norme.

+1

déjà que certains plugins doublonne alors que si il fusionner on aurait des trucs de Ouf
mais bon c'est un vieux débat
et de plus on est pas DREDI donc ...

--
@micalement
----
"Réussir sa vie, plutôt que de vivre sa réussite"
----
http://stephanepoupard.free.fr/
----
SPIP 3.2.0-alpha-1 [23482] + écran de sécurité 1.3.0 + Escal 3.86.34 - stable