à titre d’info, j’ai des pr qui datent de 2 ans…
Bonjour,
A défaut de valider rapidement des requêtes de tirage (PR), il serait intéressant d’expliquer le mode de fonctionnement et ce qui s’oppose éventuellement aux modifications suggérées, soit de manière générique, soit de manière spécifique.
J’ai aussi juste une requête en attente depuis un mois. J’ai dû la modifier déjà un fois parce d’autres modifications intervenues entretemps interféraient avec ma proposition.
J’ai consulté la liste des développeurs. Il y a relativement peu de messages, et rien en relation avec les règles de fonctionnement ou la feuille de route.
:On m’a répondu.
La version de développement est passée en mode Béta, ce qui fait que les nouvelles fonctionnalités ne sont plus acceptées. Seules les corrections de bogues sont acceptées.
Bonjour 
Du coup moi j’ai pas tout compris 
Ca veux dire que faut attendre pour faire des autres PR? Quand j’en fait je le fait que sur la branche developp (d’ailleurs j’ai pas vu de branche beta).
Cà dépend de la nature de la PR (pull request).
Si c’est une correction de bogue, elle doit passer.
Si elle contient une évolution de fonctionnalité, elle sera retenue. En théorie, ça n’empêche pas de la faire. Le problème est que comme plusieurs développeurs peuvent travailler sur une même partie de code de manière indépendante, il faudra certainement gérer des conflits de fusion.
[Edit et PS] : je n’ai rien vu d’écrit sur le sujet hormis un commentaire dans une PR.
Je ne pense pas qu’il y aurait une branche béta, mais plutôt v8.0, qui existe d’ailleurs.
1 « J'aime »
Bonjour
quelqu’un à des news sur les PR qui datent.
Sinon c’est bon signe nos chers dev sont au bord de la mer 
et prennent efin des vacances 
Bonjour
Maintenant que l’on est passé à la version 8 pourquoi les pr ne sont toujours pas acceptées ou refusées ?
Bonjour
Je relance le post pour savoir :
qui sur github a le droit de « merge »
Le bureau de l’asso dolibarr à priori si vous regardez bien.
Merci
Tu trouves ou la liste des personnes ?
Bonjour
Perso quand mes pull-requests prennent de l’âge… je les ferme…
Fred
Bonjour
Merci !
Je laisse tomber…en fait je trouve ca fatiguant à la longue je sais que les admin du projet on grave du boulot mais bon je corrige le PR c’est Ok et j’attends quelques semaines il repasse en « This branch has conflicts that must be resolved » je recorrige attends bref
le truc un peu agacant c’est de n’avoir aucun retour des admin : a corriger, refusé, pas de label rien etc…depuis le mois de juin je jongle…
je sais que je suis pas un expert en programmation et que mes lignes sont loin d’etre parfaites mais un petit message d’un admin (les utilisateurs eux participent activement à la discussion et conseillent bcp un peu comme ici d’ailleurs) aurait été sympa
Bonjour
J’essaye aussi de donner mon avis sur les pull-requests, mais ce n’est qu’un avis, ce n’est pas forcément à suivre.
Concernant le code, vous pourrez lire sur le wiki qu’on essaye de se conformer à PSR2 (à deux ou trois règles près), donc évitez de changer le style du code inutilement…, cela évite les conflits (de code).
Fred
1 « J'aime »
J’avais bien vu que tu es actif sur github également
Bonjour
youpi la barre des 5 mois sans réponse d’admin est passée:
https://github.com/Dolibarr/dolibarr/pull/8953
Bonjour,
Lisez bien le wiki sur le fonctionnement du développement communautaire. Il n’y a pas « d’admin » sur GitHub, mais un lead coder qui est eldy et qui valide ou non les PR. Il met en général des commentaires / labels sur les PR. Il y a actuellement 100 PR, et il ne passe pas en revue chaque jour tous les messages laissés par les contributeurs…
2 choses a retenir :
Lorsqu’une phase beta est lancée, plus de PR NEW ne sont mergée, uniquement les FIX, et les NEW sont tagguées en « postponed », jusqu’à la création de la branche qui sera la future version.
Le nombre de contributeurs est en forte augmentation, donc le nombre de PR aussi. Le risque de conflit tout autant, donc le nombre de revue de code à faire pour chaque contributeur.
Actuellement edly garantit la stabilité et les évolutions du logiciel en ne mergeant pas toutes les PR sans regarder le détail. Et les priorités de développement de trouvent dans les issues (tag top priorities).
Vous avez d’ailleurs déjà eu + de 40 PR mergées, donc prenez votre mal en patience
A bientôt !
1 « J'aime »
Bonjour
Je sais très bien que c’est un énorme boulot que de gérer un projet comme doli, je ne peux que féliciter la team du boulot qu’elle réalise.
Bonjour,
Les patas-monkey n’assurerons plus les monté de version de leur modules à chaque évolution du core.
Pour être plus précise, l’ensemble de nos modules ne seront plus testé avec les versions paires de dolibarr (celles qui sortent durant les grandes vacances sans prévenir…).
Nous conseillons donc à nos clients et nos partenaires de ne plus déployer nos modules sur ses versions ou à leur risque et péril.
Je précise enfin que nous réalisons toujours des évolutions régulières de nos modules et les tests seront toujours réalisé sur la dernière version de dolibarr (impair comprise), sachant que nous assurons 3 versions de compatibilité descendante.
Merci de votre compréhension
