Le 06/04/2016 17:42, Pierre Choffardet a écrit : > Le 06/04/2016 13:34, Sophie a écrit : >>>>> L'attentrectifs. Mais je pense que le DSI le sait :) >>> Sur le reste, je ne vois pas de démonstrations, ni dans les fils >>> précédents, mais des affirmations. La seule démonstration qui vaille >>> serait de faire évoluer deux projets de LibreOffice en parallèle et de >>> voir celui qui emporterait l’adhésion. Impossible >> Ça a pourtant été le cas avec Apache OpenOffice et LibreOffice. >> Démonstration faite. Ensuite, tu peux faire une recherche sur "time base >> release" sur le web, tu verras que la plupart des projets open source >> (qui ont le même modèle de gouvernance que la fondation, à savoir qui ne >> payent pas les développeurs) ont adopté ce modèle de fonctionnement. > > C'est peut-être aller un peu vite des faits à la conclusion. > AOpenOffice est moribond, c'est vrai, mais il bouge encoure. Même s'il > était mort, c'est aller un peu vite en besogne que de dire que c'est le > mode de développement de LibreOffice qui l'a tuer (ici j'ai fait exprès > de faire une faute;-) pas ailleurs dans le texte:-[ )
C'est exactement ce pourquoi la fondation a été créée, pour en finir avec le mode de développement et de gouvernance d'OpenOffice.org. Ce n'est pas le mode de développement de LibreOffice qui a tué Apache OpenOffice, mais c'est celui-ci qui a permis à LibreOffice d'avoir son dynamisme d'aujourd'hui ainsi que son mode de gouvernance. > >> From Wikipedia, the free encyclopedia >> >> Release early, release often (also: time-based releases, sometimes >> abbreviated RERO) is a software development philosophy that emphasizes >> the importance of early and frequent releases in creating a tight >> feedback loop between developers and testers or users, contrary to a >> feature-based release strategy. *Advocates argue* that this allows the >> software development to progress faster, enables the user to help >> define what the software will become, *better conforms to the users' >> requirements for the software*,[1] and *ultimately results in higher >> quality software*.[2] The development philosophy attempts to eliminate >> the *risk of creating software that no one will use*.[3] >> >> This philosophy was popularized by Eric S. Raymond in his 1997 essay >> The Cathedral and the Bazaar, where Raymond stated "Release early. >> Release often. *And listen to your customers*".[4] >> >> This philosophy was originally applied to the development of the Linux >> kernel and other open-source software, but has also been applied to >> closed source, commercial software development. >> >> The alternative to the release early, release often philosophy is >> aiming to provide only polished, bug-free releases.[5] Advocates of >> RERO question that this would in fact result in higher-quality >> releases.[4] > Je ne vois aucune démonstration ici, mais une philosophie, un modèle de > développement. des arguments, contestables et contestés. Je ne vois pas > non plus que cela implique une augmentation continuelle des régressions. Le fait de faire des versions à date fixe fait que quelque soit l'état de la version, elle est livrée (ce qui n'est pas toujours vrai, on fait parfois des versions contenant un bug-fix). L'augmentation continuelle des régressions ne vient pas du développement mais de l'assurance qualité -> i.e. à nouveau le rôle des utilisateurs est essentiel ici. les stats des régressions de cette semaine sont: + 763(-10) bugs open of 4802(+4) total 26(-2) high prio. monitorées toutes les semaines, il n'y a pas plus et plutôt moins que pour les précédentes versions. > > J'utilise Firefox, qui a adopté ce modèle de développement, mais je peux > continuer à utiliser Firefox tous les jours sans avoir à supporter de > nombreuses régressions. Ce n'est pas le même modèle, Firefox est développé par les développeurs de Mozilla Corp, ce n'est pas l'écosystème qui gère le développement. > > >>> Après tout quelle qu’en soit l'issue, il sera toujours bon d’affirmer >>> qu'il n'y avait pas d'autre solution non ? >> Non, la veille et la prospective font partie du projet, d'où les >> réunions avec l'Advisory Board tous les trois mois, dont la présentation >> est distribuée aux membres de TDF. Et pour avoir assisté à toutes les >> réunions, je n'ai pas entendu un des membres de l'AB remettre en cause >> le modèle de release adopté par TDF. > > Je ne suis pas certain que l'on se comprenne. Il ne s'agit pas de > contester le rythme des publications, mais leur qualité, et > éventuellement leur affichage (version de test, fortement buggée) C'est complètement lié. Si tu as suffisemment de monde pour faire de la QA en amont (les bug hunting sessions ou on se retrouve à trois pélerins, toujours les mêmes du vendredi au dimanche, ça en dit long...) et en aval des versions, et après assez de développeurs derrière, ça fonctionne, mais il faut que tout le monde joue le jeu. Quand nos ministères utilisent une version maison qui apporte des bugs pour les autres et qu'ils s'en moquent parce que pas concernés, c'est exactement ce qui nuit à la qualité de LibreOffice. Quand des grands groupes utilisent LibreOffice et ne reversent pas les patches qu'ils font développer, c'est exactement ce qui nuit à la qualité de LibreOffice. Six mois devraient amplement suffire à repérer et corriger les régressions (rythme de sortie d'une nouvelle version de LO) >>> En tous cas, moi, je suis largement lassé par tous ces bugs, et je >>> préfère m'en tenir à quelque chose qui fonctionne à peu près >>> correctement. Je vois autour de moi, que je ne suis pas le seul. >>> >>> Si ce comportement est marginal, ça me concerne, si ce comportement se >>> généralise, je pense que ça concerne TDF et son écosystème. Mais là >>> aussi je peux me tromper >> Cela concerne tout le monde, mais attendre que cela se passe ne fera pas >> avancer quoi que ce soit au contraire. Et là encore je ne te vise pas, >> nous sommes sur la liste QA où tu participes activement. > Je n'ai pas le choix que de faire autre chose que d'attendre. > A partir du moment, ou l'on me dit que la qualité de la suite n'est pas > une priorité, que les régressions provoquent plus de soucis que les > améliorations du logiciel, il est normal de passer en mode "standby" C'est une priorité pour ceux qui en font une. Si tu lis les minutes de la dernière réunion ESC, tu verras qu'il y est question de qualité tout du long : amélioration du code, suivi de coverity, jenkins, lcov, stats de QA, MAB, etc. Just un regard à devcentral (http://devcentral.libreoffice.org/) et il y manque MozTrap, ou perf (http://perf.libreoffice.org/) montre que le monitoring et les tests sont faits. Jan essaye de repérer systématiquement les heasyhacks pour en faire des portes d'entrées accessibles à tous les développeurs débutants. Mais au risque d'être lassante, tant que les utilisateurs ne prennent pas leurs responsabilités vis à vis du produit, rien ne s'améliorera, au contraire. TDF ne paye pas le développement, uniquement les outils, c'est aux utilisateurs de partager les coûts d'entretien de leur outil de travail. À bientôt Sophie -- Sophie Gautier [email protected] GSM: +33683901545 IRC: sophi Co-founder - Release coordinator The Document Foundation -- Envoyez un mail à [email protected] pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/qa/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
