Cloturer Les Pull Requests sur Github

Hello,
Appel aux auteurs des PR sur github! un peu de ménage (Garbage collector!!)
Un PR qui date de 3ans ou même 2mois est obsolète et n’aura aucune chance d’être publier!
Commencez par clôturer, puis pensez à refaire les modifications sur une nouvelle version (pour éviter les conflits) et republier!

Ou bien, et à mon avis c’est plus constrictive, c’est que eldy ferait une pause et se focalise sur la validation des PR existantes, cela inciterait les autres contributeurs de proposer des nouvelles améliorations et fonctionnalités…

J’insiste sur le fait de ne plus laisser les PR en attente pour longtemps par eldy avant leurs publication car j’ai remarqué que beaucoup de contributeur ont délaissé le projet pour ces raisons!
par exemple @rdoursenaud était très impliqué et depuis fin 2016 a abandonné! et par hasard ça coince avec son PR qui date de 2016 pas encore publié! maintenant avec 11 fichiers en conflits c’est impossible à corriger et publier! dommage!

https://github.com/Dolibarr/dolibarr/pull/4432

Hello,

Le tri sera fait prochainement mais l’exemple au dessus est mauvais car avec un WIP dans le titre, c’est sur qu’il ne sera pas intégré. Raphaël est partie vers d’autres horizons, c’est son choix, c’est parce que un PR n’est pas intégré qu’il faut pleurer.

La meilleure solution pour faire signe et de clôturer un PR et de le recouvrir s’il date vraiment mais même moi j’en ai qui traîne et je les clôture au bout d’un certain temps pour alléger la base. Et des fois, c’est juste une question de point de vue.

Bonne soirée

Hello,
un autre exemple qui fait rire :laugh: https://github.com/Dolibarr/dolibarr/pull/11093
4 mois pour un « a space missing… » bon à ce rythme là …
Heureusement que Elon Musk n’utilise pas travis dans ses entreprises car sinon spacex n’a pas vu le jour encore! :whistle:

Slt

On cherche des modos
www.dolibarr.fr/forum/t/recrutement-equipe-moderateurs-traducteurs/30335/8

Si tu est motivé
un modo connaissant github et pouvant faire le lien avec le forum serait bien

@pm17

vu le ton qu’emploi wdammak, ça n’est pas vraiment une bonne idée…

Slt
@Arre
Je vois pas le souci
Il a un point de vue il le defend c tout

et vu qu on a a besoin de monde et que ca se bouscule pas :whistle:
toute personne motivée est tjrs bonne a prendre

Autre exemple qui date depuis avril! https://github.com/Dolibarr/dolibarr/pull/10997

@Arre : yes t’as raison :happy:

Sinon, mon point de vue c’est que eldy peut être est débordé mais j’ai l’impression qu’il ne fait pas confiance à la communauté et à d’autres fantastiques contributeurs! (peut être je me trompe!)

Sinon j’invite les contributeurs de faire une pause et faire le ménage des anciens PR! Car j’ai vu des cas sur github où 3 dev travaillent indépendamment sur la même fonctionnalité… perte de temps et d’énergie…

Bon! as u like!

@wdammak : Les critiques constructives sont prises en compte et appréciées. J’ai par exemple mis en place avec Eldy SticklerCI pour avoir une vérification du code style plus simple et des résolutions automatiques lorsque c’est possible. De façon plus importante, le fait d’utiliser Stickler CI fait que les vérifications sur le Code Style sont maintenant effectuées uniquement sur les fichiers modifiés de la PR (et non plus sur tous les fichiers de la branche ce qui était le cas auparavent). Cette étape ayant été supprimée de TravisCI vu qu’elle est maintenant menée par SticklerCI permet de gagner du temps d’exécution sur le TravisCI.

Personnellement, je ne le perçois pas comme ça mais ce n’est pas toujours évident de savoir à qui on peut se fier. La confiance est une chose fragile qui se gagne progressivement. Et, oui, c’est certain que Eldy a beaucoup de choses à gérer.

Dans ces cas là, peux tu ajouter un commentaire sur les PR GitHub concernées en liant les autres PR en ajoutant leur numéro précédé d’un # ? Cela aidera tout le monde et permettra au moins aux différents dév de savoir qu’il y a peut-être un travail en cours en double (ou triple).

Le triage des issues et des PR va être amélioré. C’est un processus en cours et il faut garder à l’esprit que l’ensemble des contributeurs ont des occupations autre que Dolibarr :wink: Je vais par exemple essayer de voir pour fermer les très anciennes PR (on est d’accord que garder des reliques de cet ancien temps ouvertes n’a pas beaucoup de sens … surtout quand plusieurs versions majeures ont été publiées depuis).

Je tiens cependant à dire que pour avoir moi même proposé plusieurs PR, elles ont toujours été traitées relativement rapidement. A partir du moment où le développeur soumettant la PR est présent, accepte la critique constructive et réponds ou corrige les éventuelles choses remontées par la personne effectuant la revue de code (Eldy), les choses sont assez fluides et fonctionnent bien.

Slt a tous

@jtraulle
Je propose que @wdammak fasse ici de temps une liste des PR a probleme
afin que tu jette un oeil
Serait tu ok ?

Le plus simple, vu que @wdammak a déjà un compte sur GitHub, c’est encore qu’il commente sur les PR qu’il juge problématiques et/ou obsolète (il peut me mentionner sur GitHub (@jtraulle) si besoin de fermer une PR également) :wink:

Comme cela, ça évitera les allez retour.

D’abord voici quelques PR qui pourrait être publier :


















Merci, j’ai passé en revue cette liste et réassigné les PR aux bonnes personnes :wink:

2 « J'aime »

fait pour ma part :wink:

1 « J'aime »

Merci à vous deux
@jtraulle je suggère d’ajouter d’autres tags/label comme:
Improvement
TBS (To Be Specified)
To Do
waiting for author (Status: Waiting for Author Feedback)
waiting for dev (Status: Waiting for dev Feedback)
CO (Core)
Performance
Regression
Modules
Themes
Products
Invoices
Order
Stock
Inventory
Accounting
Multi company
MBR
Combinations
website
Translations
Import
Export

Bonjour :happy:
A mon avis trop de labels ça embrouille un peu

+1

Pas d interet de label pour savoir a quel module correspond le code
ya le titre pour ca non ?

mais c que mon avis
propose ton idee a @eldy si tu pense que c est utile

1 « J'aime »

J’avais demandé à Eldy pour trier par module mais pour lui, ça ne sert à rien car ce regroupement n’apporterait aucune plus value.
Pour le reste, les suggestions de tags doivent être vues directement avec Eldy (je peux juste trier = ajouter, enlever des tags sur les issues et PR, assigner des personnes mais pas gérer les tags en eux même = en ajouter/modifier/supprimer).

Pour un dev avoir toutes les PR en relation avec Accounting ça lui permet d’avoir une idée sur le stade des dev en cours par un simple clique sur le label et ça lui évite de travailler et proposer la même chose

Un ERP est un pack très vaste de multi-applications/modules, le triage est important pour plusieurs besoins… je peux être intéressé par la gestion de stock mais jamais de la comptabilité ou la gestion des comptes bancaires…

Parcourir toutes les pages et lire toutes les titres pour comprendre de quoi il s’agit c’est fatiguant!

Pour l’administrateur du projet ça lui permet d’organiser les priorités…

Mais bon! à vous de voir!

Avec environ 80 modules natifs
ca va faire une sacré liste :silly:
A mon avis si tu veux « vendre » cette idee a eldy
il vaudrait mieux se limiter aux « familles »
Ex Produit/service/stock…