URL: https://linuxfr.org/news/libreoffice-de-5-0-a-5-2-un-an-apres
Title: LibreOffice : de 5.0 à 5.2, un an après
Authors: ff9097
Yves Bourguignon, Olivier, Davy Defaud, BAud, jibecfed, Nils Ratusznik, palm123, Crao, Lucas, windu.2b, Axone, Space_e_man, khivapia, bentix, Benoît Sibaud, Christophe, Xavier Combelle, ariasuni et Jehan
Date: 2016年08月03日T14:52:44+02:00
License: CC By-SA
Tags: libreoffice et bureautique
Score: 81
LibreOffice 5.2 est publié depuis le 3 août 2016. Cette nouvelle version est destinée aux utilisateurs expérimentés — les autres, comme les entreprises et les administrations, sont invités à utiliser LibreOffice 5.1.6
[Michael Meeks](https://en.wikipedia.org/wiki/Michael_Meeks_%28software_developer%29) est un développeur qui travaille sur la suite bureautique LibreOffice pour l’éditeur Collabora.
Il vient de publier sur son _blog_ une longue description du travail de refactorisation et de nettoyage qui a eu lieu lors de cette année de développement menant de la version 5.0 à la version 5.2 de LibreOffice. Cette dépêche est une traduction de son article initialement publié dans le domaine public ou licence CC0, comme indiqué au bas de l’article.
----
[Article original](https://people.gnome.org/~michael/blog/2016-08-03-under-the-hood-5-2.html)
[Notes de version 5.2](https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr)
[Dépêche de la précédente version (5.1)](http://linuxfr.org/news/libreoffice-5-1-version-majeure)
----
Aujourd’hui nous publions LibreOffice 5.2.0, la dernière étape de notre voyage, qui sera la base de la toujours plus stable série 5.2._x_. Il y a une belle série de nouveautés, faites par des super‐développeurs, qui plairont aux utilisateurs [finals](https://fr.wiktionary.org/wiki/finals) (vous pouvez lire les [notes de version](https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr) pour vous réjouir), mais, comme toujours, il y a beaucoup de contributeurs dont le travail se fait principalement dans les coulisses et dont les œuvres concernent surtout la technique plutôt que ce qui est visible des utilisateurs.
Il y a quelque temps, l’ESC (_Engineering Steering Comittee_, le comité de pilotage d’ingénierie) a décidé d’ajouter quelques pages wiki à propos du travail fait sous le capot, pour que les gens puissent ajouter leurs propres crédits. Je vous encourage à lire les pages [5.1](https://wiki.documentfoundation.org/UnderTheHood/5.1) et [5.2](https://wiki.documentfoundation.org/UnderTheHood/5.2). Il y a beaucoup de bonnes choses et ça m’évite de devoir lire et résumer les ≃ 10 000 _commits_ de chaque version, même si, là encore, ça peut être drôle. Ceci est ma très rapide tentative pour parler de l’année écoulée au travers des 17 734 _commits_ (ce qui donne environ 50 _commits_ par jour) depuis `libreoffice-5-0-branch-point` jusqu’à `libreoffice-5-2-branch-point`.
Centre développeurs
=================
Une excellente initiative de Norbert Thiebaud a été de collecter et centraliser la plupart des infrastructures et leur point d’entrée disponibles au sein de TDF (_The Document Foundation_) dans une jolie liste afin d’aider les nouveaux arrivants à trouver et utiliser nos outils et services. Jetez‐y un œil : .
La fin de Vigra
===============
LibreOffice a été en mesure de fonctionner en mode _headless_ (sans écran ni clavier), en faisant sa propre et longue chasse aux pixels, ce qui est utilisé de manière intensive à la fois par LibreOffice en ligne et aussi par le portage de GTK3/Linux. Ça a été, pour moi‐même et pour d’autres, une source d’étonnement sans fin que le code (illisible) du modèle de Vigra produise un code aussi peu performant dans toutes sortes de cas. Une des grandes joies avec LibreOffice 5.2, c’est la mort définitive de Vigra et du répertoire `basebmp` et l’utilisation de Cairo en natif (accéléré par l’assembleur) pour la chasse aux pixels. Merci à Caolan McNamara (Red Hat) pour tout ça.
Améliorations de l’accélération matérielle
==========================================
Pendant cette période, un grand nombre d’améliorations a été apporté à OpenGL et OpenCL :
- Le modèle de rendu d’OpenGL a été fortement simplifié — en effectuant tous les rendus par une texture en _back‐buffer_ à double mise en tampon, puis en les affichant à l’écran à un moment inactif après une requête de rafraîchissement. Il s’agit de la suite des travaux réalisés pour Mac OS X et désormais GTK 3. Combiné avec quelques ajustements dynamiques dans les priorités des rendus, cela donne un rafraîchissement et des redimensionnements doux sans traces. Ce travail a également fortement simplifié la gestion et le cycle de vie des contextes GL.
- Protection contre les crashs d’OpenGL et CL — en raison du grand nombre de problèmes dans la qualité des pilotes — nous avons mis en place une surveillance de chaque appel à GL ou CL — de façon à ce que notre gestionnaire de crashs puisse détecter un plantage lié à ceux‐ci et, dans ce cas, désactiver la fonctionnalité au redémarrage.
- Vérification du comportement d’OpenCL et OpenGL avant leur utilisation réelle, notamment pour éviter des problèmes fonctionnels, en particulier de mauvais calculs dans le tableur.
Ainsi, à chaque changement de version du pilote CL ou de LibreOffice, nous recalculons une feuille de test au lancement et en vérifions les résultats, afin de détecter un mauvais comportement des implémentations CL et pour désactiver, si besoin, l’accélération CL. De même, pour OpenGL, nous compilons par lots et mettons en cache tous nos _shaders_ pour nous assurer qu’il n’y a pas d’erreurs de compilation qui pourraient causer des problèmes plus tard.
- Améliorations de la mise en liste noire d’OpenGL et CL, avec de jolis fichiers `cache/opengl_device.log` contenant des détails de vos pilotes. Après beaucoup de travail, nous avons découvert que les pilotes GL d’Intel sous Windows 7 étaient incroyablement loufoques et donc ont été mis en liste noire.
- Les performances ont beaucoup été améliorées en combinant les _shaders_. Il est intéressant de noter que la charge pour passer d’un _shader_ à un autre, ainsi que pour les changements d’état des programmes associés, est très significative. Ce qui fait que l’utilisation d’un seul, et assez compliqué, _shader_ qui gère de nombreux cas est plus rapide que plusieurs _shaders_ très simples (un par cas). C’est pourquoi nous avons fusionné toutes nos routines de dessin texturé et non texturé dans deux gros _shaders_ combinés, qui contiennent un `switch()`.
- En combinaison avec ça, le travail de groupement et de mise en file pour agréger de nombreuses opérations de dessin en une seule invocation de GL/programme nous confère un avantage indéniable. Combiné avec les améliorations de l’atlas textuel [N. D. T. : ???], ceci nous permet de déférer le dessin d’un grand nombre de glyphes en un seul appel GL.
- D’autres accélérations GL incluant l’utilisation d’un _shader_ pour calculer les [CRC](https://fr.wikipedia.org/wiki/Contr%C3%B4le_de_redondance_cyclique "Contrôle de redondance cyclique") 64 bits des images (à des fins de comparaison), la mise en cache de nos matrices MVP, et la coordination des transformations spatiales sur le processeur graphique, ainsi que la conversion des dégradés de gris et le rendu des (poly)lignes basées sur les _shaders_.
- L’absence d’une bonne API pour le rendu matériel des polices de caractères sur Windows nous a poussés à implémenter la prise en charge de _DirectWrite_ pour le rendu du texte. Merci à Tim Eves (SIL) et Martin Hosken (SIL).
- Il y a aussi de nombreuses améliorations et corrections diverses : l’implémentation de « _invert_ », l’amélioration de l’[anticrénelage](https://fr.wikipedia.org/wiki/Anticr%C3%A9nelage), le rendu XOR, la subdivision des polygones basés sur des angles, l’amélioration et l’accélération du [_clipping_](https://fr.wikipedia.org/wiki/Clipping_%28infographie%29) [N. D. T. : _je crois qu’il s’agit de la découpe du rendu par petits cadres à la façon de Google Map, ça sert surtout pour l’affichage Web_], de meilleurs chemins de tests pour _vcldemo_, l’amélioration du rendu des _widgets_ natifs. Il y a aussi des petits bouts d’amélioration sur les bogues du cycle de vie et du nettoyage fait sur la fermeture, ainsi que de nombreuses corrections de bogues.
Merci donc à tous ceux ayant fait plus de cinq _commits_ dans `vcl/opengl`, `opencl/` et `sc/source/core/opencl` : Tomaž Vajngerl (Collabora), Tor Lillqvist (Collabora), Noel Grandin (Peralex), Stephan Bergmann (Red Hat), Caolán McNamara (Red Hat), Markus Mohrhard et Marco Cecchetti (Collabora).
Améliorations des performances
========================
Les améliorations des performances sont difficiles à montrer mais sont malgré tout importantes. Nous maintenons des tests de régression de performance (qui tournent sous Valgrind) à l’adresse [http://perf.libreoffice.org](http://perf.libreoffice.org), ce qui aide vraiment à localiser avec précision les problèmes lorsqu’ils apparaissent.
Une belle victoire dans les travaux sur la 5.2 que celle d’Armin Le Grand (CIB) pour améliorer notre gestion des _threads_ et s’en servir pour accélérer le rendu 3D logiciel — ce qui donne une accélération particulièrement notable du rendu des graphiques en 3D.
Rapports de crashs
===============
Markus Mohrhard a fait un travail tout simplement excellent sur les rapports de crashs — pour nous aider à trouver les plantages les plus fréquents sur Windows. Alors que de nombreuses distributions GNU/Linux ont des outils similaires déployés depuis des années, couvrir Windows était également important. L’implémentation réutilise [Breakpad](https://chromium.googlesource.com/breakpad/breakpad/) de Google pour créer des mini‐vidages de mémoire qui sont analysés côté serveur et joliment tracés sur .
Markus aimerait l’aide de quelqu’un ayant des compétences en développement Web pour l’aider à améliorer l’interface, et l’analyse, l’interrogation et la présentation des données. Merci de vous signaler sur la liste des développeurs _libreoffice@lists.freedesktop.org_.
Ce travail a déjà permis plusieurs correctifs vitaux pour les crashs les plus récurrents, en utilisant les données adéquates pour remédier aux plus gros problèmes de qualité. Merci à Markus Mohrhard, Caolán McNamara (Red Hat) et Miklos Vajna (Collabora) dont les _commits_ référencent les adresses URL de rapports de crash.
Travail en cours sur la qualité du code
=========================
Il y a du travail en cours sur la qualité du code dans de nombreuses zones, avec au moins 196 correctifs issus de `cppcheck`. Merci à Caolán McNamara (Red Hat), Julien Nabet, Jochen Nitschke, Noel Grandin (Peralex), Michael Weghorn, Takeshi Abe, Giuseppe Castagno et aux autres.
Caolán et les gars de Red Hat font en sorte de garder le compte d’erreurs de l’analyse de Coverity et le nombre de _crash‐tests_ (charger et sauvegarder ≃ 91 000 documents en plein de formats) à près de zéro tout le temps, en faisant également des tests aléatoires ([_fuzzing_](https://fr.wikipedia.org/wiki/Fuzzing "test à données aléatoires")) et d’autres corrections.
Améliorations du cycle de vie
======================
En poursuivant la refonte du VclPtr [N. D. T. : pointeur sur les objets du _toolkit_ graphique], où nous avons ajouté un robuste cycle de vie référencé à tous nos _widgets_, Dipankar Niranjan (rapport de bogue TDF no [96888](https://bugs.documentfoundation.org/show_bug.cgi?id=96888)) a nettoyé entièrement le vieil et horrible outil de référencement qui essayait de gérer le cycle de vie correctement à l’intérieur de VCL, en utilisant des références beaucoup plus propres.
Plus récemment, Yurtoglu, Melike Ayse et Noel Grandin ont œuvré à abstraire la _VclReferenceBase_ et à appliquer ça aux menus, afin de s’assurer que leur cycle de vie soit correctement géré. Merci aussi à Jocken Nitschke pour avoir internalisé le _DeletionListener_ (bogue TDF no [97525](https://bugs.documentfoundation.org/show_bug.cgi?id=97525)) qui devrait être supprimé quand un jour nous référencerons et compterons les ressources du _back‐end_ `sal/` [N. D. T. : « _sal_ » ou « _system abstraction layer_ »].
Il y a un autre travail formidable : avoir exorcisé le comptage de références manuel. Grâce à Thomas Arnhold, Daniel Robertson, Noel Grandin, Aleksas Pantechovskis et surtout Xisco Fauli pour les travaux sur les bogues TDF no [96525](https://bugs.documentfoundation.org/show_bug.cgi?id=96525) et no [89329](https://bugs.documentfoundation.org/show_bug.cgi?id=89329), qui ont converti de nombreux comptages de référence manuels ou des structures _copy‐on‐write_ pour utiliser l’excellent modèle _cow_wrapper_. Ils ont aussi converti des pointeurs _pIpml_ pour utiliser `std::unique_ptr` [N. D. T. : _modernisation du code C++_]. Ceci réduit l’étendue des erreurs de programmation et des cas particuliers et nous permet de faire des « _copy‐on‐write ref‐counting thread‐safe_ » si nécessaire. Il y a 140 cas corrigés et encore à peu près 68 instances de comptage de références qui ont besoin qu’on s’occupe d’elles.
Tests unitaires
============
Nous avons continué d’ajouter des tests unitaires critiques cette année. Chacun d’eux permet d’empêcher à jamais la réapparition de régressions. Un `grep` sur les macros _TEST_ et _ASSERT_ montre que le nombre continue d’augmenter :
Notre rêve est que chaque bogue corrigé soit accompagné d’un test unitaire pour l’empêcher de revenir. Avec environ 1 800 _commits_ (20 % en plus par rapport à l’année dernière) et plus de cent contributeurs durant cette période, c’est difficile de lister tout le monde impliqué ici, mes excuses pour cela ; ce qui suit est une liste triée de ceux avec plus de vingt _commits_ dans `core.git` et `online.git` : Miklos Vajna (Collabora), Caolán McNamara (Red Hat), Stephan Bergmann (Red Hat), Ashod Nakashian (Collabora), Noel Grandin (Peralex), Markus Mohrhard, Tor Lillqvist (Collabora), Eike Rathke (Red Hat), Michael Stahl (Red Hat), Henry Castro (Collabora), Chris Sherlock, Varun, Andrea Gelmini, Jan Holesovsky (Collabora), Takeshi Abe, Łukasz Hryniuk, Xisco Faulí, Mike Kaganski (Collabora) et ceux avec plus de 10 _commits_ ont aussi droit à une mention honorable — les tests unitaires sont importants ! David Tardon (Red Hat), Katarina Behrens (CIB), Marco Cecchetti (Collabora), Tomaž Vajngerl (Collabora), Oliver Specht (CIB), Zdeněk Crhonek, Mark Hung, Justin Luth, Julien Nabet, Aleksas Pantechovskis, Pranav Kant (Collabora).
Améliorations de LibreOfficeKit
===========================
L’API LibreOfficeKit est le fondement de l’application Android, _GNOME Documents_ et le travail en cours sur _LibreOffice Online_, et beaucoup de choses ont changé l’année dernière. Les deux principaux blocs de construction de l’API LOK sont les méthodes des objets exposés et les types de rappels. Depuis la version 5.0, les nouvelles méthodes suivantes ont été ajoutées :
- `lok::Office::getFilterTypes()` permet d’obtenir une liste à jour de noms filtrés — paire de types MIME, ajouté pour GNOME documents ;
- `lok::Office::setOptionalFeatures()` et `lok::Office::setDocumentPassword()` permet d’ouvrir un document protégé par mot de passe ;
- `lok::Office::freeError()` permet de libérer une chaîne de caractères d’erreur allouée par l’API ;
- `lok::Document::getPartPageRectangles()` permet d’obtenir la taille et la position des pages d’un document Writer ;
- `lok::Document::getTileMode()`permet aux clients qui écrivent de travailler avec le nouveau (Cairo) et l’ancien (Vigra) _backend headless_ (voir plus haut) ;
- `lok::Document::initializeForRendering()` a été étendu pour accepter une option clef‐valeur durant l’initialisation, comme le mode « espaces cachés » de Writer ;
- `lok::Document::postMouseEvent()` a été étendu pour manipuler les clics et les modificateurs ;
- `lok::Document::postUnoCommand()` a été étendu pour obtenir un rappel lorsque le résultat d’une commande UNO est prête ;
- `lok::Document::getTextSelection()` et `lok::Document::paste()` ont été ajoutés pour manipuler le copier‐coller ;
- `lok::Document::getCommandValues()` a été ajouté pour pourvoir effectuer des requêtes sur les valeurs possibles pour les commandes UNO (police et nom de style, détails des en‐têtes de lignes et de colonnes de Calc, curseur de cellules Calc) ;
- `lok::Document::setVisibleArea()`a été ajouté pour pouvoir pour avancer ou reculer d’une page correctement ;
- `lok::Document::createView()`, `lok::Document::destroyView()`, `lok::Document::setView()`, `lok::Document::getView()` et `lok::Document::getViews()` ont été ajoutés pour un début de prise en charge de l’édition collaborative ;
- `lok::Document::renderFont()` a été ajouté pour aider à la prévisualisation des polices ;
- `lok::Document::getPartHash()` a été ajouté pour aider les clients à suivre la réorganisation des diapos ;
- `lok::Document::paintPartTile()` a été ajouté pour permettre un rendu sans état de différentes parties d’un document.
Et les nouveaux rappels suivants sont disponibles :
- `LOK_CALLBACK_DOCUMENT_SIZE_CHANGED` : la taille du document a changé ;
- `LOK_CALLBACK_SET_PART` : le numéro de la partie courante est modifié ;
- `LOK_CALLBACK_SEARCH_RESULT_SELECTION` : les rectangles de sélection des résultats quand on utilise la fonctionnalité « Tout rechercher » ;
- `LOK_CALLBACK_UNO_COMMAND_RESULT` : le résultat de l’exécution d’une commande UNO ;
- `LOK_CALLBACK_CELL_CURSOR` : la taille et/ou la position d’un curseur de cellule a changé ;
- `LOK_CALLBACK_MOUSE_POINTER` : le style courant du pointeur de souris ;
- `LOK_CALLBACK_CELL_FORMULA` : le contenu textuel de la barre de formule dans Calc ;
- `LOK_CALLBACK_CONTEXT_MENU` : la structure du menu contextuel (après un clic droit).
Merci à Andrzej Hunt (Collabora), Ashod Nakashian (Collabora), Henry Castro (Collabora), Jan Holesovsky (Collabora), Michael Stahl (Red Hat), Mihai Varga (Collabora), Miklos Vajna (Collabora), Oliver Specht (CIB) et Pranav Kant (Collabora) pour cela.
Divers
======
Un des apports réalisés lors de notre [Hackfest turque](https://wiki.documentfoundation.org/Hackfest/Ankara2016) à Ankara fut la découverte que LibreOffice ne se compile même pas avec les paramètres régionaux `tr_TR.UTF-8`. Il est intéressant de constater que dans cette langue, `toupper('i') != 'I'` ; amusant (_cf._ Bogue TDF no [99589](https://bugs.documentfoundation.org/show_bug.cgi?id=99589)). Merci à Krishna Keshav, Gökhan Gurbetoğlu et Apurva Priyadarshi pour les corrections.
Un grand nombre de défauts de l’expérience utilisateur ont été corrigés et améliorés, comme les raccourcis clavier, les problèmes de cohérence de l’affichage, les contrôles mal placés et mal dimensionnés, ainsi que quelques régressions concernant la conversion des fichiers d’interface. Merci à Caolán McNamara (Red Hat), Akshay Deep, Regina Henschel, Maxim Monastirsky, Jürgen Funk (CIB), Bubli Behrens (CIB), Samuel Mehrbrodt (CIB) et Jay Philipps.
QA / bugzilla
=============
Une métrique que nous regardons lors des conférences ESC, c’est qui est dans le top 10 du [résumé hebdomadaire de _freedesktop.org_](https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html). Voici une liste de personnes qui sont apparues plus de dix fois parmi ceux clôturant le plus de bogues. Dans l’ordre de fréquence d’apparition : Stuart Foote, Adolfo Jayme, Cor Nouws, Maxim Monastirsky, Eike Rathke (Red Hat), _raal_, _m.a.riosv_, Julien Nabet, Caolán McNamara (Red Hat), Miklos Vajna (Collabora), Beluga, Alex Thurgood, Michael Meeks (Collabora), Buovjaga, Yousuf (Jay) Philips, Joel Madero, Samuel Mehrbrodt (CIB), Markus Mohrhard, Timur, Jean‐Baptiste Faure, Xisco Faulí, Aron Budea, _tommy27_, Michael Stahl (Red Hat), Heiko Tietze, David Tardon, Laurent BP. Avec beaucoup de remerciements pour tous les autres qui ont aidé à clôturer et trier un tel nombre de bogues pour cette version.
Jenkins / CI
============
Principalement grâce à Norbert Thiebaud, nous disposons désormais, non seulement d’une infrastructure d’intégration continue sous Jenkins, associée à Gerrit, mais aussi d’une ferme de compilation agrandie disposant d’un matériel plus fiable, ce qui encourage les utilisateurs à utiliser Jenkins pour vérifier leur travail avant l’envoi de leur code. Cela se concrétise par une qualité et une fiabilité renforcées de la branche principale. Cette année, nous avons constaté les bénéfices engendrés par notre suite de vérification des tests unitaires sur nos compilations de débogage sous GNU/Linux.
Le travail accompli par Jenkins simplement sur la branche principale pour les six mois de route vers la branche 5.2 : nous avons 34 124 compilations sur Tinderbox couvrant sept configurations sous GNU/Linux, Mac OS X et Windows. Avec 27 737 compilations couvrant ces trois plates‐formes testées sur notre infrastructure Gerrit. Ça, c’est pour le matériel d’intégration continue, il y a de nombreux autres volontaires qui lancent des [_Tinderbox builders_](http://tinderbox.libreoffice.org/MASTER/status.html). Ceci est extrêmement utile pour maintenir la branche _master_ compilable et utilisable, rendant l’arrivée des nouveaux plus facile. Avec 60 000 compilations pour 8 000 _commits_, nous faisons beaucoup de tests en boucle et de validation du code de LibreOffice au rythme de l’intégration continue.
Réduction des commentaires en allemand
============================
Parmi mes héros préférés, il y a ceux qui clarifient le code pour que les autres puissent travailler dessus. L’une des tâches clefs est la traduction des commentaires en allemand restants ([_liste_](https://people.gnome.org/~michael/data/2016-08-01-german-comments.txt)). Les dernières 4 000 lignes semblent défier toute tentative de traduction — je n’ai aucune idée des raisons pour lesquelles ce graphe s’aplatit de la sorte. Tous les correctifs provenant de personnes parlant allemand aimant finir le travail seront grandement appréciés. Un grand merci à ceux qui sont dessus, avec plus de deux _commits_ ; dans l’ordre du nombre de _commits_ : Albert Thuswaldner, Phillip Sz, Thomas Klausner, Chris Sherlock, Philipp Weissenbacher et Matteo Casalin. Il ne reste plus que sept modules à traduire : _include_, _reportdesign_, _sc_, _sfx2_, _stoc_, _svx_ et _sw_.
Windows XP
==========
La série 5.2.x tourne bien sur Windows XP, mais nous ne pouvons pas savoir combien de temps nos outils continueront à prendre en charge cette plate‐forme. Notre gouvernance n’a pas de plans concrets visant à supprimer la prise en charge de Windows XP, nous allons le marquer _obsolète_ après la série 5.2._x_ — ce qui signifie qu’avoir pour base un compilateur C++ moderne et un système d’exploitation Windows moderne est une plus grande priorité. Cela signifie qu’à l’avenir il est possible que les futures versions majeures de LibreOffice ne tournent pas sur Windows XP ; vous êtes prévenus. Pour l’instant, pas de changement à ce niveau.
Contribuer
==========
J’espère que vous comprendrez que de plus en plus de développeurs arrivent et se sentent comme chez eux parmi nous. Nous travaillons ensemble pour réaliser des travaux importants à la fois sous le capot et sur la carrosserie. Si vous voulez vous impliquer, il y a plein de gens compétents à rencontrer et avec qui œuvrer. Comme vous pouvez le constater, les indépendants ont un impact significatif sur la diversité de LibreOffice (la légende des couleurs se lit de gauche à droite, de haut en bas, ce qui représente les couleurs de haut en bas dans le graphique. [N. D. T. : _les indépendants, c’est le gros morceau vert au sommet_]).
Il manque à ces graphiques, générés tôt ce mois, quelques individus et _commits_ mis en attente dans Gerrit pour une revue, d’où le nombre faible en juillet. En termes de diversité, nous adorons voir la quantité de contributions de volontaires non affiliés, bien que le volume et l’équilibre varie selon la saison, le cycle de version, les vacances des volontaires et les _business‐plans_.
Naturellement, nous maintenons une liste de petites ou minuscules tâches sur notre page [_Easy Hacks_](https://wiki.documentfoundation.org/Development/EasyHacks), dont vous pouvez vous emparer pour vous impliquer dans ce projet, avec des [instructions simples d’installation ou de compilation](http://www.libreoffice.org/community/developers/). C’est extrêmement facile de compiler LibreOffice. Chaque « _easy hack_ » indique où aller dans le code et représente une tâche simple à résoudre dans un cadre bien restreint. De plus, certaines de ces tâches sont des fonctionnalités vraiment utiles ou des améliorations de performance. S’il vous plaît, envisagez de vous impliquer sur quelque chose.
Autre chose qui aide vraiment : lancer les [préversions](http://www.libreoffice.org/download/pre-releases/) et rapporter les bogues. Il suffit de télécharger et d’installer une préversion et vous êtes prêt pour contribuer avec l’équipe de développement.
Conclusion
==========
LibreOffice 5.2 est génial, fait par un groupe de développeurs qui travaillent ensemble avec plaisir à construire une suite bureautique libre de plus en plus belle et attirante. J’espère que vous l’apprécierez. Merci pour la lecture. Et n’oubliez pas de vérifier la page des [fonctionnalités visibles](https://wiki.documentfoundation.org/ReleaseNotes/5.2/fr) et merci de soutenir LibreOffice.
Si j’ai raté votre bon travail (car ceci n’est qu’une vue incomplète basée sur quelques heures d’analyse), merci de vous ajouter vous‐même sur la page wiki correspondante et envoyez‐moi un _diff_ de cette page. Merci !
Les [données brutes](http://people.gnome.org/~michael/data/2016-08-01-data.ods) et les [statistiques de _commits_](http://people.gnome.org/~michael/data/2016-08-01-commit-stats.ods) générées via notre [_gitdm-config_](https://cgit.freedesktop.org/libreoffice/contrib/gitdm-config/) sont disponibles pour la plupart des graphiques ci‐dessus.