Re: [fr-qa] Libreoffice 5.1.1.3 pour Windows 32 bits, plantages à répétition

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 sophie.gautier@documentfoundation.org
GSM: +33683901545
IRC: sophi
Co-founder - Release coordinator
The Document Foundation

-- 
Envoyez un mail à qa+unsubscribe@fr.libreoffice.org 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