I do the same : --Automatically translated fr to en-- I do not have the first message for this subject under the eyes but if I remember well, the author was telling that the bugs met by its customers were corrected only in over versions (containing new features). However having a long time worked in context of exploitation I know very well that customers hesitate, when they have something which functions overall in a satisfactory way, to install a new version with new functionalities which can sometimes have effects edge and destabilize what was working well before (regression). On the other hand, they are petitioning so that their version is corrected when they encounter problems known and solved in the next version(s). I have held for more than 10 years a position in a team of software maintenance which was precisely created to maintain the versions in exploitation: the customers saw a clear improvement when the team of developers were separated from the team of maintenance. The team of maintenance concentrates on the correction of the bugs whereas the developers could not be prevented from making improvements besides the corrections which sometimes destabilized the code. We work in close collaboration: when a developer corrects a bug which was not highlighted in our versions yet (He yes, that happend), he warns us so that we integrate the correction. And they have the possibility of seeing all our corrections to i ntegrate or adapt them if that relates to also their version. Indeed, my English is not very precise and I probably badly expressed myself but it is not question of introducing the new functionalities into versions LTS but only the correction of bugs. And considering the time of which I lay out, I do not plan (at least initially) to correct the bugs but only to integrate the corrections made in the code of the versions higher than version LTS. I do not know yet enough the code of Dolibarr to be able to claim to be effective in the maintenance of this one.
-- moi en français (en espérant que ça sera meilleur) -- Je n'ai pas le message d'origine de ce sujet sous les yeux mais de mémoire, l'auteur évoquait le fait que les bugs rencontrés par ses clients n'étaient corrigés que dans des versions contenant des évolutions. Or ayant longtemps travaillé dans un contexte d'exploitation je sais très bien que les clients hésitent, quand ils ont quelque chose qui fonctionne globalement de façon satisfaisante, à installer une nouvelle version avec des nouvelles fonctionalités qui peuvent parfois avoir des effets de bord et déstabiliser ce qui marchait avant (régression). Par contre, ils sont demandeurs pour que leur version soit corrigée lorsqu'ils rencontrent des problèmes connus et résolus dans la/les version(s) future(s). J'occupe depuis plus de 10 ans un poste dans une équipe de maintenance logiciel qui a justement été créée pour maintenir les versions en exploitation : les clients ont vu une nette amélioration quand les équipes de développeurs ont été séparées des équipes de maintenance. L'équipe de maintenance se concentre sur la correction des bugs alors que les développeurs ne pouvaient pas s'empêcher de faire améliorations en plus des corrections qui parfois déstabilisait le code. Nous travaillons en étroite collaboration : quand un développeur corrige un bug qui n'a pas encore été mis en évidence dans nos versions (he oui, cela arrive), il nous préviens pour que nous reportions la correction. Et ils ont la possibilité de voir toutes nos corrections pour les reporter ou les adapter si cela concerne aussi leur version. Effectivement, mon anglais n'est pas très précis et je me suis probablement mal exprimé mais il n'est pas question d'introduire les nouvelles fonctionalités dans les versions LTS mais seulement les correction de bugs. Et vu le temps dont je dispose, je n'envisage pas (au moins dans un premier temps) de corriger les bugs mais seulement de reporter les corrections apportées dans le code des versions supérieures à la version LTS. Je ne connais encore pas assez le code de Dolibarr pour pouvoir prétendre être efficace dans la maintenance de celui-ci. Amicalement, Jean-Paul > Message du 31/07/12 15:08 > De : "aurelien Imhof" > A : [email protected] > Copie à : > Objet : Re: [Dolibarr-dev] Evolution des versions et patch > > --- en -- (sorry , it's google translate) Re, I see that this issue remains a > sensitive issue .. Without raised again why a "LTS" along with a support. I > agree with @ laurent on the question of a person / team that it does this > job? I am ready for my part in monitoring / bug fixes and hire me for the > duration of this release @ John Paul, it seems not to include any interesting > novelty, but only to produce a stable release with an update (FIX + security > bug) reasonable production. My disposal is random (I work alone), so if I am > not alone, this can do this .. To join @ regis, I also think the 3.2 could > see wearing it on a stand longer, and can not be two years, but let's say 1.5 > years. is ~ 4/6 non-LTS release between the two. cordially -- fr - - Re, Je > vois que cette question reste un sujet sensible.. Sans de nouveau evoqué le > pourquoi d'une "LTS" avec un support long. je rejoins @laurent quant à la > question d'une personne / equipe qui ce charge de ce travail? je suis pret > pour ma part a assurer un suivi / correction de bugs et de m'engager sur la > durée pour cette version @Jean-Paul , il me semble pas intéressant d'intégrer > une quelconque nouveauté, mais uniquement de produire une version stable avec > une mise a jour (FIX securité + bug) raisonnable en production. Ma dispo > reste aléatoire (je travail seul), donc , si je ne suis pas seul, ca peut ce > faire.. Pour rejoindre @regis, je pense aussi que la 3.2 pourrait ce voir > porter sur un support plus long , et peut être pas 2 ans, mais disons 1.5 > ans. soit ~4/6 version non LTS entre les 2. Cordialement -- Aurélien Imhof > Consultant Conseils - Maintenance - Infogérance - Audit Développement - > Programmation Sites : - http://www.oscim.fr - http://www.com-hedon.com bureau > 02 46 65 03 35 portable 06 07 60 82 37 Hébergement ( dédie - virtualisé - > mutualisé ) - backup - Cloud téléphonie VOIP Assistance technique hébergement > 08 25 59 50 80 (0.15€/min) Sites extra/perso - http://oscss.org - > http://oscim.net _______________________________________________ Dolibarr-dev > mailing list [email protected] > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net
<<attachment: smiley-wink.gif>>
_______________________________________________ Dolibarr-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
