Piwigo.org

acp · 2007-06-26 23:18:43

Bonsoir,

je ne sais pas si c'est la catégorie idéale du forum pour cette discussion, mais je n'ai pas trouvé plus adéquat... Au vu des avancées faites au système de plugins avec l'arrivée de la 1.7, je pense que le nombre de greffons se verra augmenté et leur adoption sera de plus en plus fréquente chez les utilisateurs de PHPWG.

Je voulais juste vous proposer de se pencher sur un système plus poussé de votre hébergement d'extensions. L'interface actuelle mise à disposition des développeurs est certes efficace, mais on peut toujours faire mieux :). Je ne sais absolument pas quelles sont vos capacités en termes de de serveurs (matériels et logiciels j'entends), donc c'est peut-être tout simplement pas possible...

Il serait donc à mon avis intéressant de proposer aux développeurs de greffons une interface de gestion de projets qui comprend :
_ un système de gestion de version (subversion à tout hasard)
_ un système de gestion de bugs/wishlist (en gros, les utilisateurs inscrits sur votre site, donc sur le forum en fait, peuvent faire part des problèmes/bugs qu'ils rencontrent, ou d'un élément qu'ils aimeraient voir)
_ les release (pas grand chose à reprocher à la façon dont c'est géré actuellement, mis à part le fait que c'est entièrement manuel ; on pourrait voir un système automatique, qui en fonction de l'état des respositories svn ou autre, créera automatiquement des releases, un tel système étant par exemple utilisé pour les modules de drupal)

Comme je l'ai dis précédemment, je pense que l'argument majeur contre une telle démarche serait les capacités de votre hébergeur. Ceci dit, vous proposez déjà un système de release, et les bugs/wishlist se font pour l'instant via le forum (avec d'ailleurs un certain nombre de doublons, comme vous le savez très probablement mieux que moi :) ).

Après, en ce qui concerne la main d'oeuvre, je peux me charger de la mise en place de tout ça, déjà en local pour vous proposer quelque chose de complet, puis après.... et bien on verra si besoin en est.

Une autre idée, serait de créer un nouveau projet, de type PHPWG-extensions (par exemple) hébergé chez gna.org ou équivalent, qui proposent déjà tous les services ci-dessus, le seul inconvénient étant que, à moins que je me trompe, l'accès aux sources ne peut être restreint parmi les membres de l'équipe de développement, c'est-à-dire le dev X1 du projet P1, peut modifier le projet P2 du dev X2. Mais il me semble que ceci n'est pas forcément un gros problème, et qu'on peut apprendre à vivre avec.

Voilà, j'aimerai avoir votre avis là-dessus.

Sur ce, bonne soirée à tous,
acp

VDigital · 2007-06-27 07:06:08

Je vais réactiver un peu notre ami Pierrick...
En sachant que le moment n'est pas idéal, ses dispos sont très réduites.
8-)

flipflip · 2007-06-27 08:35:25

Salut, je m'intègre à cette discution.
Je ne pense pas que ce soit à l'équipe de PhpWebGallery de gérer ces choses. C'est au developpeur du/des plugins à le faire. Il existe sur le net un tas de forge (sourceforge, gna, CodingTeam). Perso j'ai choisi http://www.codingteam.net la semaine dernière. C'est un nouveau projet d'une équipe française, l'interface me plait, il n'y a pas de condition particulière à l'inscription (pour le moment). Sinon à un moment j'utilisais TuxFamily.

un système de gestion de version (subversion à tout hasard)

Pour l'avoir installé au boulot, c'est beaucoup d'effort, la monopilisation d'une machine (pour le cas de PhpWebGallery il faudrait un serveur dédié).

La mise en place d'une forge, même dédié à un seul projet demande du temps de mise en place, un coups d'achat ou location d'un serveur dédié, une suivie pour l'administration et le support.

Ma devise, d'autres l'ont fait, pourquoi reinventer la roue ?

acp · 2007-06-27 09:45:21

Bonjour,

le problème en fait de l'option gna, sourceforget, etc., c'est qu'il ne s'agit pas vraiment d'y placer des projets à part entière. Les extensions sont souvent assez petites, que ce soit en terme de lignes de code ou de développeurs impliqués. De plus, l'intérêt d'une solution centralisée est que, et bien, tout est centralisé justement. Le fait que vous proposiez une interface de gestion de la mise à disposition des extensions en témoigne.

Après, ce n'est pas forcément à l'équipe de PHPWG de gérer tout celà, on pourrait imaginer un projet parallèle (mais du coup proche à PHPWG) qui serait administré par d'autres personnes, les devs des plugins justement.

Par contre, je pense que ma dernière proposition dans mon premier message te conviendrait plus alors flipflip, à savoir partager un compte sur un des forge donc, parmi tous les dev de plugins (enfin, faudra voir, à mon avis un système d'acceptation de nouveaux sera mis en place pour éviter tout débordement).

J'avais oublié un avantage également, c'est qu'on pourrait alors proposer des docs pour les plugins, ou du moins une présentation plus détaillée. Dans le cas de la 1.7, on pourrait peut-être même proposer une démo (ça par contre, je pense que ça risque d'être difficile, m'enfin on perd rien à le mettre dans la liste, on verra par la suite).

Dernière modification par acp (2007-06-27 09:46:16)

flipflip · 2007-06-27 13:50:48

Après, ce n'est pas forcément à l'équipe de PHPWG de gérer tout celà, on pourrait imaginer un projet parallèle (mais du coup proche à PHPWG) qui serait administré par d'autres personnes, les devs des plugins justement.

Personnellement je n'ai pas le temps d'administrer une forge, c'est pour ça que je passe par d'autres qui le font.

J'avais oublié un avantage également, c'est qu'on pourrait alors proposer des docs pour les plugins, ou du moins une présentation plus détaillée. Dans le cas de la 1.7, on pourrait peut-être même proposer une démo (ça par contre, je pense que ça risque d'être difficile, m'enfin on perd rien à le mettre dans la liste, on verra par la suite).

Le wiki est bien pour y mettre la doc.

mathiasm · 2007-07-02 22:46:23

Pour résumer ce qui a été dit et mon avis par-dessus:
» Les devs de plugins se gèrent leurs sources tout seuls, comme des grands :-) (en local autonome, il y a aussi RCS)
» Les docs pour les plugins: en français dans le wiki sur fr:plugins:<nom_du_plugin>, en anglais sur en:plugins:<plugin_name>
» Le moteur de gestion des extensions. Pierrick travaille à le rendre plus générique, il est déjà en projet sur GNA (chercher PEM). Pas d'interface prévue avec un outil de version, trop lourd à gérer.
» Pour les remontées concernant les greffons, le forum extensions est déjà là. Les doublons sont tout aussi présents sur un outil structuré (vécu sur sourceforge, par ex.), et l'interface de discussion est plus agréable sur un outil de type forum.

Ça permet à tout le monde de développer dans son coin sans se poser de questions sur les interactions possibles.

acp · 2007-07-02 23:15:17

Je me sens un peu seul de mon côté, donc je ne vais pas élaborer tant que ça ma réponse. Je vais juste répondre à un des points cités ci-dessus, l'usage du forum pour la remontée de bugs.

Les doublons ne sont pas vraiment le plus gros des problèmes. Certes il y en a comme partout mais à mon avis, le forum, de par sa nature, ne favorise pas à les éviter. La recherche, dans ce cadre d'utilisation précis, n'est pas vraiment adaptée (même si on peut s'en sortir, je ne dis pas le contraire). Cependant, là où c'est vraiment un inconvénient, c'est que le développeur n'est pas averti, à moins qu'il jette un coup d'oeil tous les X jours en parcourant le forum pour voir s'il y a mention d'un problème avec un de ses plugins. Qui plus est (rencontré fréquemment ici même), les discussions peuvent traiter de plusieurs plugins en même temps, ce qui rend le retour d'information encore plus difficile.

Après, je ne dis pas que c'est la catastrophe. Ça marche très bien comme ça, on s'en sort. Ceci dit, je pense qu'une approche différente, comme proposée dans le premier post par exemple, pourrait donner un boost dans le développement d'extensions pour PHPWG, surtout avec l'arrivée de la 1.7.

En gros, je ne dis pas que c'est pas possible de faire avec ce qu'il y a, la preuve ça marche depuis un certain temps déjà. Mais ce n'est pas une raison pour ne pas essayer de voir les alternatives. Si le problème de l'hébergement n'est plus de mise (utilisation de gna, sf ou autre faisant l'affaire), la question serait du coup de savoir si la mise en place d'une telle plateforme serait utilisée et si elle profiterait à PHPWG. A lire les commentaires jusqu'à présent, j'aurai tendance à répondre non et non :).

P.S:

Ça permet à tout le monde de développer dans son coin sans se poser de questions sur les interactions possibles.

En ce qui me concerne, ça constitute plus un inconvénient qu'un atout...

Dernière modification par acp (2007-07-02 23:16:35)

VDigital · 2007-07-03 07:38:06

acp a écrit:
Je me sens un peu seul de mon côté.

Le forum est le lieu de débat d'idées.
D'abord, actuellement z0rglub n'a pas "forgé" son avis, il serait bon de l'avoir.
Et dans tous les cas, même si une idée n'aboutie pas dans un premier temps, elle fait son chemin.
Il y a des tas d'idées qui ont été jugées farfelues au début qui sont des grands progrès reconnus aujourd'hui,
et l'histoire est un éternel recommencement, ne dit-on pas?

8-)

plg · 2007-07-03 16:27:28

Dans mon esprit, PEM le gestionnaire d'extension installé sur phpwebgallery.net/ext n'a pas pour vocation de devenir une forge. C'est beaucoup plus proche d'un freshmeat, c'est à dire la publication des news sur les nouvelles releases.

Cela dit, c'est vrai qu'en parallèle, la mise à disposition d'une forge pourrait être pratique pour les développeurs en herbe. Mais c'est vraiment lourd à gérer, c'est un métier à part entière. A mon avis, l'idée évoquée de créer un projet PWG-extensions (le nom va changer très bientôt) sur un Gna! ou un CodingTeam, me semble être la bonne solution à court et moyen terme. On ne pourra pas restreindre un développeur à un sous-répertoire, mais il suffit de se faire confiance.

En tout cas, ça me fait chaud au coeur :-) et ça me ferait bien plaisir qu'un tel projet voit le jour. acp, si tu t'en sens la responsabilité, tu peux créer un projet sur une forge et inviter d'autres développeurs.

Sous Subversion, je conseille 1 répertoire par extension puis un répertoire trunk et branches.

Code:

extension-1
extension-1/trunk
extension-1/branches
extension-1/branches/branch-1
extension-1/branches/branch-2
extension-2
extension-2/trunk

(avec des noms d'extension plus explicite bien sûr)

acp · 2007-07-06 07:35:43

Bonjour,

je n'ai malheureusement pas le temps de répondre avant la mi-juillet (faute de manque d'accès au net).

Donc à bientôt...

acp

acp · 2007-07-19 21:07:55

Bonsoir,

je repousse ca à mi-août. J'aimerai bien me pencher sur le problème, voir les solutions d'hébergement disponibles, les outils qu'elles proposent, ce qu'on peut en faire, les besoins, etc.

Je présenterai une solution complète plus tard. Fin août, début septembre j'espère. N'hésitez pas à me relancer si vous y pensez ;).

Par contre, à priori je suis bien tenté par entreprendre la tâche puis à poser les bases pour ce projet. Après, je ferai bien de la maintenance, mais pas tout seul, je compte un peu sur l'aide d'autres développeurs de plugins motivés.

A bientôt donc, avec plus d'infos. Sur ce, je vous souhaite un bon été puis de bonnes vacances à tous ceux qui ont la chance d'en prendre...

acp

acp · 2007-08-08 14:52:29

De retour, enfin pas vraiment, mais disons que j'ai à présent le temps de me pencher petit à petit sur la question. J'ai aujourd'hui approfondis un peu ma recherche de plateforme d'hébergement pour faire un premier tri rapide. Donc oui, déjà, je me dois de préciser que j'entreprends la démarche un peu à l'envers pour l'instant, donc je regarde ce qu'il y a comme services disponibles avant de définir précisement les besoins, mais à priori ça tient la route.

Je vais donner un petit résumé ici de ce que j'en ai déduit, dans l'espoir d'avoir un retour de votre part ;) :

1) Sourceforge
------------------

Nul besoin de présenter je pense, c'est connu, ca fonctionne bien, on a le choix entre CVS et SVN (bien qu'à mon avis le 2e s'imposera, ou sera imposé), de l'espace web (100 Mo), PHP/Perl/Python/MySQL puis une forge qui tourne bien.
Quelques défauts néanmoins, enfin du moins à mon avis comme par exemple l'interface du projet est un peu austère pour des utilisateurs non-habitués à ce genre d'outils (ex : pour l'ajout d'un bug, les forums sont d'une simplicité parfois ridicule, etc.).

2) Berlios
-----------

Moins connu que le précédent, mais une autre référence en matière de plateformes d'hébergements de projets. Là aussi, on retrouve CVS et SVN, 100 Mo d'espace web (peuvent être étendus en cas de besoin), PHP/MySQL, cron (ca pourrait s'avérer bien utile), wiki, etc.
Les critiques faites à sf.net sont valables aussi pour berlios puisque la forge semble être la même.

3) Tuxfamily
--------------

Ici, ca change tout de même un peu puisqu'il semblerait qu'on ne propose pas de forge. On a donc les autres outils (SVN, 100 Mo d'espace, PHP/MySQL, mailing-lists, etc.) mais pas de forge. On peut pallier ca en installant les outils nécessaires, l'intérêt étant que nous avons un contrôle plus fin sur la gestion du projet (il ne faut pas oublier que c'est un projet de sous-projets que nous envisageons, ce qui complique un brin les choses, par exemple pour soumettre un bug, il faudra toujours préciser le plugin concerné, etc. ; rien de bien grave certes, mais bon, il faut le préciser) et que l'on peut choisir du coup les logiciels qui répondent au mieux à nos besoins. L'inconvénient, bien évidemment, c'est qu'il faut tout faire, puis tout maintenir...

4) CodingTeam
-----------------

Je ne connaissais pas, vous m'en avez parlé. J'ai jeté un coup d'oeil, ca a l'air tout à fait intéressant. J'avoue que l'intégration de Jabber me tente beaucoup, je trouve ca super, mais c'est un détail. C'est un jeune projet qui avance apparemment assez vite (et bien), donc ce pourrait être une bonne solution. Seul bémol pour l'instant, c'est l'absence d'espace web (pour la présentation des plug-ins, un éventuel forum si besoin en est, la doc, etc.). Il y a un wiki éventuellement, mais je ne suis pas grand fan pour avoir tout un site sous wiki, ou sinon on peut toujours créer un hébergement chez free que l'on utilisera pour vitrine.

Personnellement, je n'ai pas encore longtemps réfléchis sur la question, mais là si je devais donner une préférence, je dirai que je pencherai plus pour les deux derniers. Je ne sais pas trop pourquoi, puisqu'en tèrmes de services ils sont plus démunis, mais c'est ainsi. L'absence de forge sur Tuxfamily m'inquiète aussi, quand à la charge de travail que sera la mise en place et le maintient du site, mais je me dis que si une bonne raison pousse vers ce choix, on trouvera bien les moyens de s'en sortir...

Toute information/expérience personnelle sur les sites sus-cités (ou autres, les oublis ca arrive :) ) sera la bienvenue. Entre temps, je vais commencer à réfléchir sur comment mettre en place tout ca, de quoi nous avons besoin concrètement, etc.

A bientôt,
acp

P.S : Avant de créer un compte quelconque chez l'hébergeur qui sera choisit (c'est pas pour tout de suite, mais je préfère m'y prendre à l'avance pour une fois), serait-il possible d'en savoir plus sur le changement de nom ? Il serait préférable à mon avis que les deux projets aient un nommage plus ou moins voisins pour bien souligner le lien entre eux.

P.S2 : Je pensais également que ce serait bien de prendre en compte tout type d'extension et non pas seulement les plug-ins du coup. Thèmes, plug-ins, traductions seraient donc les bienvenus... Peut-être même créer un projet de documentation. Mais bon, ce sera pour bien plus tard, puis il semblerait que vous voulez mettre le wiki en avant pour cela...

Dernière modification par acp (2007-08-08 14:56:56)

plg · 2009-06-09 22:42:55

Réactivation de ce topic, suite à [Forum, post 113171 by acp in topic 15628] [SecureImages] Mise à jour pour piwigo

J'avais complètement oublié ce topic. Désolé acp. Et bien ce que tu proposes ici, c'est ce qui est en train de se monter actuellement. Comme le décrit le [Forum, topic 15503] Hébergez votre extension sur le dépôt Subversion de Piwigo

J'ai migré le dépôt SVN de Gna vers notre propre serveur piwigo.org. Cela nous permet de gérer les utilisateurs et des droits répertoire par répertoire. Reste à définir un répertoire correspondant à une extension et voilà. Les extensions sont visibles de tous, mais chaque développeur a sa liste d'extensions. On peut donner les droits à plusieurs développeurs sur la même extension, donc travail collaboratif. A cela s'ajoute une fonctionnalité dans le gestionnaire d'extensions qui permet de co-gérer une extensions (plusieurs auteurs peuvent ajouter des revisions).

Pour la partie bugs/features, j'ai prévu d'utiliser Trac. C'est "en cours". Je pourrais utiliser Mantis plutôt (que je maîtrise très bien), mais l'étude d'autres projets comme wordpress.org m'incite à plutôt utiliser Trac pour le suivi des tickets. Si tu as un avis sur le sujet, je suis intéressé.

acp · 2009-06-10 07:41:18

Bonjour! Moi aussi j'avais complètement oublié ce post... Je me souvenai juste que j'avais visité pas mal de forges, mais je pensais que c'était pour des besoins personnels.

Bref, comme je l'avais dis à l'époque, c'est une très bonne initiative qui va beaucoup aider le projet (extensions/plugins inclus).

En ce qui concerne donc le bugtracker, je me suis très récemment penché sur le sujet dans le cadre de mon travail, mais pour des besoins un brin particuliers. Et bien j'avais justement choisi Trac! J'avais très vite exclus Mantis, si je ne me trompe pas c'était parce qu'il ne répondait pas à mes besoins spéciaux. En ce qui concerne Piwigo, ca pourrait être un bon choix, mais malheureusement avec quelques défauts qui me dérangent un peu:
_ système d'authentification un brin particulier (on peut trouver ce que l'on cherche avec les plugins mais je ne raffole pas du résultat final)
_ structure de la base de données vraiment trop simpliste, avec des clés primaires un peu particulières. sans réelles références entre tables (par exemple on recopie le nom d'utilisateur un peu partout plutôt que de faire référence à un id numérique vers la table des utilisateurs).
_ gestion des droits vraiment trop légère: le seul plugin qui pourrait peut-être aider est un système de droits AuthnzPolicy (je me trompe peut-être sur le nom là) mais qui demande pas mal d'efforts administratifs

A mon avis ca reste une bonne solution mais qui pour être parfaite demandera un développement supplémentaire. La centralisation des utilisateurs devrait peut-être être envisagée (même utilisateur/mdp pour svn, le gestionnaire d'extensions, trac, etc.).

On pourrait d'ailleurs utilisé peut-être le champ "component" pour les extensions. (Au pire, il est toujours possible d'avoir un champ personnalisé, mais une fois de plus il faut le gérer à la main, ou le mettre à jour régulièrement via script).

D'autres solutions, comme Bugzilla par exemple, on déjà été testées?

++

Piwigo.org

Annonce

#1 2007-06-26 23:18:43

Gestion des extensions

#2 2007-06-27 07:06:08

Re: Gestion des extensions

#3 2007-06-27 08:35:25

Re: Gestion des extensions

#4 2007-06-27 09:45:21

Re: Gestion des extensions

#5 2007-06-27 13:50:48

Re: Gestion des extensions

#6 2007-07-02 22:46:23

Re: Gestion des extensions

#7 2007-07-02 23:15:17

Re: Gestion des extensions

#8 2007-07-03 07:38:06

Re: Gestion des extensions

acp a écrit:

#9 2007-07-03 16:27:28

Re: Gestion des extensions

Code:

#10 2007-07-06 07:35:43

Re: Gestion des extensions

#11 2007-07-19 21:07:55

Re: Gestion des extensions

#12 2007-08-08 14:52:29

Re: Gestion des extensions

#13 2009-06-09 22:42:55

Re: Gestion des extensions

#14 2009-06-10 07:41:18

Re: Gestion des extensions

Pied de page des forums