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.
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.
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 !
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.
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 !
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 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.
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