@sdjenadi je ne suis pas du tout d'accord avec toi sur certains points.

Alors déjà, non, dans la théorie, on ne passe pas par une seule personne. Si il n'y a que moi pour décider ce qui doit être intégré ou pas, c'est juste parce qu'à priori, il n'y a que moi malheureusement qui connaisse à fond les composants de jelix, et donc qui soit en mesure de faire les reviews. Nous ne sommes pas assez de contributeurs, et à forcieri, il n'y a que très peu (voir pas du tout à ma connaissance, ou alors ils ne sont plus là), qui connaissent très bien les entrailles de tel ou tel composants.

et sinon, oui, j'exige que l'on discute des modifications apportées avant de les intégrer, pour éviter que le framework devienne une usine à gaz, et que l'on aboutisse à tout un tas d'API incohérentes. Donc oui, désolé, il faut bien au moins quelqu'un qui décide au final ce qui est bon ou pas pour le framework. Ce quelqu'un peut être moi, mais aussi d'autres membres de la core-team, quand il y en aura (il y en a eu par le passé).

"pourquoi l'ajouter" ou "pourquoi pas l'ajouter", ça revient au même. Si la solution apportée est mauvaise, le résultat sera le même : modification rejetée, à retravailler.

Plus de pouvoir aux développeurs, je n'ai jamais été contre. Mais dans ce projet, comme dans la majorité des autres projets libres, c'est la méritocratie qui règne. Montre moi, par tes patchs et contributions, que tu sais très bien par exemple comment fonctionne jDao, et alors au bout d'un certains temps, je pourrais te déléguer tout ce qui concerne jDao, tu pourras faire les reviews sur jDao etc.. Et tu seras considéré comme faisant parti de la "core-team", ceux sur qui le framework repose vraiment.

Ce que je ne veux surtout pas, c'est que Jelix devienne un fourre-tout de n'importe quoi, une usine à gaz, parce qu'on aura accepté tout et n'importe quoi comme contributions.

Toute modification nécessite réflexion. il faut vérifier que cela n'a pas d'effets de bords malencontreux, que ça reste dans la philosophie de jelix, que ce soit performant etc...

Si tu apprécie techniquement Jelix, c'est bien parce que ces principes ont été suivi depuis le début.

il faut que ca soit RAPIDE...

Pour que ce soit rapide, il faut déjà plus de contributeurs pour faire les reviews, et donc qui connaissent très bien Jelix. Mais pour ça, il faut proposer pas mal de patchs, "faire ses preuves" pour montrer que l'on maitrise parfaitement telle ou telle partie du framework. Bref, c'est une roue sans fin : tu ne proposes pas de patch -> tu ne deviens pas expert -> tu ne seras pas reviewer -> ça fait moins de reviewer -> les patchs sont plus long à reviewer -> le developpement va moins vite -> ça décourage -> on ne propose pas de patch.

Bref, comme je le demandais en début de discussion : J'ai besoin de contributeurs qui s'impliquent dans le projet. Plus on sera nombreux, plus le developpement sera actif, rapide et facile, plus on pourra accepter des patchs (mais pas n'importe quoi non plus), plus ça attirera des utilisateurs, et donc plus on aura des contributeurs etc..

Bref, j'ai besoin de vous pour amorcer la "pompe".

Et une chose est sûre, le projet n'avancera jamais aussi vite aussi bien que l'on voudrait, si on hésite à proposer des patchs ;-)

Même si le patch est rejeté, vous aurez fait avancer les choses :

• avec les commentaires qui auront été émis, vous saurez un peu plus comment fonctionne le framework, ou ce qu'il faut faire pour que vos prochains patchs soit accepté plus tard. Bref, vous avancez dans le projet, vous progressez (sur jelix, php ou autre)
• pour moi ou les autres, la proposition peut faire naître des idées d'amélioration, directement lié ou non au patch.

Encore une fois, mon but principal en ce moment, c'est de chercher à déléguer, à ne plus supporter le projet à bout de bras comme je le fais depuis 6 ans. Mais je ne déléguerais pas au détriment de la qualité du projet.

oui je comrpend tres bien. Mais au fait est-ce les patchs sont refuser ou il faut simplement les améliorer?

Ca dépendra des cas.

Un patch qui apporte quelque chose mais a des imperfections ne sera surement pas rejete, les autres le seront surement.

Coucou,

Simplement pour signaler que j'ai très très peu de temps à apporter à Jelix, mais je tâche de poser des questions dans le forum et je tente parfosi d'y répondre.

C'est un très bon framework, et je ne souhaite pas qu'il disparaisse :)

Pour la gestion de tickets, j'ai découvert, il y a peu, Candycane : équivalent de Redmine mais refait en php. On sait jamais, si ça peut aider. D'ailleurs, tout en bossant avec Jelix sur mon projet, je tâche d'aider le gars de Candycane. Et j'ai d'autres projets qui suivent. Donc, le support pour Jelix se fait un petit peu au bonheur la chance quand j'ai quelques minutes, et surtout quand j'ai des questions ;)

Bon courage, on est là en tout cas !

laurentj a dit :
La doc http://developer.jelix.org/wiki/fr/patchs est à jour. Préférer cependant la méthode "Vous êtes un contributeur actif", bref, travailler sur github directement, ça sera au final plus simple pour tout le monde.

J'aimerais contribuer plus "activement", j'essaie donc de mettre en place d'environnement de developpement qui me permettra de proposer des patchs via git. Pour ce faire, je me réfère au wiki Travailler avec les sources mais je bute sur l'étape de génération du build (PHP warning: parse_ini_file<monbuild.ini>: failed to open stream: No such file or directory in ......build\lib\jBuild.inc.php on line 86 suivi de la stack trace)...

Comment dois-je renseigner exactement la variable MAIN_TARGET_PATH dans monbuild.ini sachant que je suis sous Windows 7 ?

C'est Comme ceci par exemple.

MAIN_TARGET_PATH = C:/WEB/DOCUMENT_ROOT/www_jelix_12

Moi j'aimerai bien retrouvé l'option que m'avait fourni laurentj pour, à la fin du build de la version, faire l'update dans le dépôt.

Du temps de mercurial/bitbucket, j'avais cette option permettant de mettre à jour le dossier lib de HaveFnuBB sans avoir à faire un "sale" copier coller des fichiers

D'ailleurs si tu es habitué à Linux, pour utiliser Git sous windows ya GitBash; comme ca on garde les habitudes de la ligne de commandes !

@foxmask : pour avoir l'aide,

php build/buildjelix.php -h

C'est indiqué dans la doc ;-)

@lucky

mais je bute sur l'étape de génération du build

d'après l'erreur, il ne trouve pas le fichier ini. faut que tu lui donne le chemin du fichier ini, relatif à là où tu te trouves

Merci @foxmask et @laurentj. Je m'y remettrai ce soir après le boulot ;)