Oui mon pc est devenu une usine à gaz juste pour faire tourner 2,3 truc à peu près correctement 
Perd pas espoir
Apparament meme les « anciens » devs comme aspangaro/eldy/…
ne passe pas tjrs le travis
@jtraulle
tu sais que ton pseudo c est presque « je trolle » ?
Bon pour travis …
je dirais plutot une page dedié « Verifier /valider son code » ou dora explore travis 
ca risque de rendre la page un peu lourde a lire sinon
bonne idée (comme d hab ) que tu crée une page sur docker/dolibarr
@pm17
Je perd pas espoir mais je délaisse car je ne suis plus dans le dev à 100%, juste de temps en temps question d’entrainer ma mémoire… pour cela j’utilise notepad++ (largement suffisant pour développer proprement… sans utiliser les IDE qui généralement polluent les performances des applications…)
@jtraulle
Oui et non!
A mon avis, faut mieux se passer de Travis en mode dev et se contenter juste de Hound puis avant la publication d’une nouvelle version/branch/release faire ces tests de Travis(maquillage) sur l’ensemble!
Cela va libérer plus rapidement les PR et le projet dans son ensemble!
J’ai remarqué que des fois un PR traine deux ou 3mois et hop! les conflits se multiple … le développeur perd espoir et abondonne…
à noter qu’il y a encore des PR très constructive qui date de 2 et 3ans, si ces PR étaient déjà libérés d’autres contributions auraient le jour…
1 « J'aime »
@wdammak Je respecte ton point de vue mais je ne le partage pas.
Je ne voit pas en quoi un IDE pollue les performances des applications. IDE ou éditeur de texte sont simplement des outils à la disposition des développeurs qui les utilisent pour produire des logiciels. La qualité ou la performance du code en sortie dépend du développeur qui le tape, pas de l’outil qu’il utilise pour taper
Quand à se passer de l’intégration continue pendant toute la période de développement jusqu’à la release effective d’une nouvelle version, ce n’est juste pas réalisable. Chaque développeur qui souhaite introduire des changements dans le code est « responsable » de la qualité des changements apportés et l’intégration continue permet de garantir cela selon des exigences définies collégialement. En admettant qu’on fasse comme tu dis, qui est responsable de nettoyer les écuries et corriger tout ce qui est en erreur lors de la release effective ? Le mainteneur ? Pas très gratifiant et surtout, pas bien réparti …
Par contre, je trouve que l’intégration continue ne devrait pas retourner d’erreur sur des fichiers autres que ceux touchés par la PR en question (cela suppose que aucune PR ne soit fusionnée si l’intégration continue est en erreur et que personne ne pousse en direct dans les branches principales même la core team mais utilise des branches de feature ou fix qui seront ensuite fusionnées via PR dans la branche develop ou les branches de versions).
