Bonsoir,
Trop de bureaucratie pour libérer les pull requests! 
Peut être l’administrateur est débordé mais c’est très lent surtout quand il s’agit d’une release de dev je vois pas de raison!
des semaines pour voir si une contribution se met en place afin de continuer à bâtir dessus…et corriger les bugs s’il y en a… du coup c’est très décourageant de continuer!
J’imagine qu’ils sont très nombreux qu’y ont abandonné a mi-chemin… d’autres se contente de garder leurs modifications dans leurs coins pour ne pas perdre beaucoup de temps pour pouvoir avancer
pardonnez ma franchise!
à 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.
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
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.
Du coup moi j’ai pas tout compris 
