J'ai comme l'impression qu'il y a des mauvaises vibrations :-\
Je pense qu'il serait temps de refaire une session de Hackweeks
cela permettrait de mettre à plat certains problèmes, discuter de la roadmap, diffuser certaines méthodes de codage etc...
Nous avons financièrement les moyens de faire quelque chose de bien.
Let's talk about it !
@+
Philippe
Le 02/12/2012 11:19, Régis Houssin a
écrit :
sinon je regardais le détail du dev sur les taxes Florian avait commencé un module permettant de définir des taux de tva plus finement, il aurait été bon de voir avec lui pour travailler sur son module... il y a une manie dans l'équipe qui consiste à réinventer la roue même si cette dernière est sous nos yeux. ou alors c'est un manque de communication ? j'ai l'impression, et ça ne date pas d'aujourd'hui, que chacun travaille dans son coin sans se soucier de l'autre. C'est très démotivant et je ne suis pas le seul. c'est comme ça qu'un projet stagne et tombe dans l'oubli. openerp, lundi matin business ou autres évoluent dans le sens des critiques qu'on leurs à faite, mais Dolibarr reste cantonné sur ces postions. Un jour ou l'autre ça va se retourner contre nous. autre point aussi très important, j'ai énormément de clients qui me disent que nous devons avoir un discours non limitatif au niveau de la taille des entreprises susceptible d'utiliser Dolibarr. On se dit ERP mais on limite le discours au association et au tpe de moins 50 employés. Quelle crédibilité avons nous face à des société plus grande ? J'ai des clients qui ont 4000 employés, et il se servent de Dolibarr soit pour fournir des services, soit en interne ! je penses qu'il faut radicalement changer de discours, ou faire effectivement un fork avec plus d'ambition. (ce qui est d'ailleurs en train de se faire) Sur ce, bon dimanche, sous vos applaudissements... Le 02/12/12 10:12, Christophe Battarel a écrit :Bonjour Laurent, Je te joins l'archive des fichiers impactés par le pull request 500. Un point que j'ai essayé de soulever plusieurs fois avec Régis en lui demandant simplement "pourquoi ?" quand il m'envoyait un commentaire du style "merge couldnt be done automatically" est le fait que (à mon humble avis) c'est à toi et à Régis d'analyser pourquoi les commits ne se font pas automatiquement, et ensuite soit de résoudre les conflits, soit d'expliciter le problème à celui qui a posté le pull request. Dans 99% des cas, cela provient d'une modif qui a été faite sur le repo de base entre le moment où le "pull requester" a mis à jour son fork et le moment où on a voulu intégré la pull request (il peut s'écouler parfois plusieurs jours). Dans le fonctionnement actuel, il revient au contributeur de remettre les choses dans l'ordre et de refaire une pull request, qui peut être à nouveau rejetée suite à d'autres modifs intervenues entre temps ! Ce travail est fastidieux, peu motivant, voire dangereux car le contributeur n'est pas forcément un grand spécialiste de git même s'il maitrise les pull et les push. J'avoue que c'est parfois également énervant de devoir faire tout ce travail (il m'est arrivé de le faire 3 ou 4 fois sur des petits commits) alors que le problème provient d'une ou deux lignes ajoutées ou enlevées entre temps sur le script de référence par un des contributeurs principaux, qui au lieu de rejeter la pull-request, aurait pu faire un diff sur le script incriminé et gérer simplement le problème. Github permet de tenter des merge automatique, mais ce n'est pas une raison pour laisser les contributeurs gérer les conflits; à mon avis, c'est le rôle du ou des chefs de projet. Cela nous permettrait à tous de gagner du temps et d'éviter le type de problème qu'on vient de rencontrer. Ce n'est pas une critique personnelle envers Régis et toi, mais une proposition pour améliorer le fonctionnement actuel. Je mets Régis en copie car cela le concerne aussi. Très cordialement, ChristopheCordialement,
--
 |
Philippe GRAND 265 rue de la vallée 45160 Olivet 02 38 63 90 20 address@hidden |