dolibarr-foundation-board
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dolibarr-foundation-board] Pb de merge


From: Destailleur Laurent
Subject: Re: [Dolibarr-foundation-board] Pb de merge
Date: Sun, 2 Dec 2012 16:08:33 +0100

Salut Christophe.

Il est difficile de demander à un développeur autre que le contributeur de gérer les gestions des conflits. En effet, pour gérer un conflit, il faut savoir ce que l'on veut obtenir avec le nouveau code. Hors seul, ce dernier à cette connaissance. Bien plus que le développeur lui même.
Il n'y a malheureusement pas de solution miracle. Quand il y a un conflit, fréquent sur un projet aussi actif que Dolibarr, il faut regarder pourquoi et acter ce qu'on garde du travail de l'autre et ce qu'on jete. Le mieux placé étant celui qui soumet, et les valideurs de commit ne pouvant tout connaitre ou comprendre, c'est logiquement que c'est la personne qui soumet, qui est la mieux placer pour faire cela. Bien sur, il est toujours possible que ce soit un autre qui fasse ce travail, mais la question de "qui est l'autre" reste alors ouverte. Qui est volontaire pour faire des merges à longueur de journée, qui plus est sur des évol dont il ne connait rien. Je ne suis pas convaincu que ce soit le rôle du chef de projet de finaliser le travail de chaque développeur, même si dans la pratique, c'est ce qui se passe souvent. Il peut le faire, il le fait d'ailleurs, mais je ne suis pas sur que ce soit une bonne chose d'orienter le discours en disant que les développeurs n'ont pas à assurer ler merge.

Actuellement, les 2 modes sont possibles (github avec gestion des conflits par le développeur, ou soumission fichiers modifiés pour un merge manuel par le chef de projet), mais plus le développeur en fait, plus les probabilités que son travail soit intégrés, et vite, sont forte, car quand c'est le chef de projet qui doit faire le travail en manuel sur un sujet qu'il maitrise forcément moins que le soumetteur, cela peut passer à la trappe.
C'est certes un dilemne, mais c'est hélas un problème inhérent à tout sujet où le travail est décentralisé. Les outils n'offrent qu'une demi solution. Le travail restent nécessaire pour gérer l'autre moitié, et pour moi ce travail n'est pas nécessairement de la responsabilité du chef de projet, mais partagés de chaque côté. Je partage donc ton point de vue sur le fait que c'est parfois compliqué pour le développeur qui ne maitrise pas nécessairement git. C'était plus simple avec svn, mais on ne peut mixer 2 outils de gestion de sources. Pour répondre à cette problématique, un tutorial simple a été fait page suivante:
http://wiki.dolibarr.org/index.php/FAQ_Get,update_GIT_project_sources
Par contre quand à la responsabilité des merges, je ne partage pas ton point de vue de dire qu'elle revient systématiquement au chef de projet. Valider et développer sont 2 choses différentes. Si le valideur devait aussi faire tous les merges, cela représenterait un goulot d'étrangelement et une source de démotivation pour ces valideurs, de nombreux merge ne seraient surement pas fait. Même si la plupart du temps c'est le chef de projet qui assure ce travail, comme pour ton cas quand je te proposais de m'envoyer les fichiers afin de faire le merge moi même, ou pour de nombreux autres cas, je préfère tout de même penser que cette responsabilité est partagée valideur/développeur.

Tu trouveras aussi sur la page suivante, la configuration d'Eclipse à mettre pour réduire la probabilité de conflit:
http://wiki.dolibarr.org/index.php/Outils_de_d%C3%A9veloppement#Installation_d.27Eclipse




Le 2 décembre 2012 11:19, Régis Houssin <address@hidden> 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,
> Christophe
>

Cordialement,
--
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------



reply via email to

[Prev in Thread] Current Thread [Next in Thread]