Why Linux isn't yet ready for synchronized release cycles
Un article de Framalang Wiki.
Cet article fait référence aux propos de Mark Shuttleworth, le boss d'Ubuntu, disant qu'il serait bien que tous les projets se synchronisent pour des sorties à peu près simultanées.
Article original sur arstechnica.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Olivier | OLV | Traduction | Terminé |
| Daria | DAR | Relecture | Terminé |
| aKa | Validation | Terminé |
Article en ligne à l'adresse : http://www.framablog.org/index.php/post/2008/06/19/linux-synchronisation-distributions
Sommaire |
Titre
Why Linux isn't yet ready for synchronized release cycles
Pourquoi Linux n'est pas encore prêt pour des cycles de parution synchronisés
Intro / Introduction
Intro - Paragraphe 1
Ubuntu founder Mark Shuttleworth has again called for the developers of major open-source software programs and Linux distributions to synchronize their development and release cycles. He argues that consistent and universal adherence to a specific time-based release model would promote more collaboration between projects, ensure that users have access to the latest improvements to popular applications, and make the Linux platform a more steady and predictable target for commercial software vendors.
Le fondateur d'Ubuntu, Mark Shuttleworth a répété son appel aux développeurs des principaux programmes open-source et des distributions Linux pour une synchronisation des développements et des cycles de publication. Il avance que l'adhésion fidèle et universelle à un modèle de parution régulier encouragerait la collaboration entre les projets, assurerait aux utilisateurs l'accès aux dernières nouveautés des applications populaires et ferait de la plateforme Linux une cible plus stable et prévisible pour les vendeurs de logiciels.
Intro - Paragraphe 2
Shuttleworth wants to organize major releases into three separate "waves" which would each include different components of the desktop stack. The first wave would include fundamental components like the Linux kernel, the GCC compiler, graphical toolkits like GTK+, and development platforms like Python and Java. The second wave would include the desktop environments and desktop applications, while the third wave would be the distributions.
Shuttleworth souhaite organiser les principales sorties en trois vagues distinctes, chacune comprenant un ensemble cohérent de composants du bureau. La première vague concernerait les composants fondamentaux comme le noyau Linux, le compileur GCC, les boîtes à outils graphiques comme GTK+ et les plateformes de développement comme Python et Java. La deuxième vague apporterait les environnements de bureau et les applications du bureau tandis que la troisième vague serait composée des distributions.
Intro - Paragraphe 3
Although a unified release cycle would reduce much of the complexity associated with building a Linux distribution, the concept poses significant challenges and offers few rewards for software developers. Achieving synchronization on the scale that Shuttleworth desires would require some open-source software projects to radically change their current development models and adopt a new approach that isn't going to be viable for many projects.
Bien qu'un cycle de sortie unifié rendrait plus aisée la création d'une distribution Linux, ce concept apporte d'importantes difficultés et n'est que peu gratifiant pour les développeurs de logiciels. Pour parvenir à une synchronisation à grande échelle comme Shuttleworth le désire, certains projets open-source devraient radicalement changer leur modèle de développement actuel et adopter une nouvelle approche qui ne sera pas viable pour nombreux d'entre eux.
--daria 12 juin 2008 à 18:42 (CEST):
A la fin de ce paragrahe, "pour nombre d'entre eux" plutôt que "pour nombreux d'entre eux" ?
Partie 1
Understanding time-based release cycles
Comprendre les cycles de sorties réguliers
Partie 1 - Paragraphe 1
A time-based release cycle implies issuing releases consistently at a specified interval. The development process for projects that employ this model generally involves establishing a roadmap of planned features and then implementing as many as possible until the project reaches the code-freeze stage near the end of the interval, at which point the features that haven't been finished get deferred. The focus shifts to debugging and quality assurance until the end of the interval, when the software is officially released.
Un cycle de sorties régulier nécessite de sortir de nouvelles versions à une fréquence donnée. Le processus de développement pour les projets qui emploient ce modèle implique général une planification des fonctionnalités prévues et ensuite en implémenter autant que possible jusqu'à ce que le projet gèle le code lorsque l'échéance approche, à ce moment, les fonctionnalités qui ne sont pas terminées sont reportées. On se concentre alors sur la correction des bogues et sur l'assurance qualité jusqu'à la date butoir, quand le logiciel est officiellement sorti.
Partie 1 - Paragraphe 2
This model works well for many projects, particularly the GNOME desktop environment. One consequence of this model, however, is that it forces developers to work incrementally, and it discourages large-scale modifications that would exceed the time constraints of the cycle. Sometimes that window just isn't large enough to merge and test major architectural changes that were incubated in parallel outside of the main code tree.
Ce modèle fonctionne bien pour de nombreux projets, en particulier pour l'environnement GNOME. Mais, une conséquence de ce modèle est que les développeurs doivent travailler par incrémentation et il décourage les modifications de grande ampleur, celles qui nécessiteraient plus de temps que n'en offre le cycle. Parfois cet intervalle n'est simplement pas suffisant pour ajouter au code principal et tester des changements d'architecture importants qui sont incubés en parallèle en dehors de l'arbre principal du code.
Partie 1 - Paragraphe 3
When that happens, developers have to ask themselves whether the benefits of the new features outweigh the detrimental impact of the regressions (like with the GVFS adoption in GNOME 2.22, for example). Sometimes they have to decide to pull out features at the last minute or push back the release date to allow for more debugging. These are hard choices, and, as Shuttleworth himself notes, making those choices requires a lot of discipline.
Quand cela se produit, les développeurs devraient se demander si les avantages de la nouvelle fonctionnalité compensent les effets néfastes de la régression (comme avec l'adoption de GVFS dans GNOME 2.22 par exemple). Ils doivent parfois décider de retirer des fonctionnalités à la dernière minute ou de repousser la date de sortie pour améliorer la stabilité. Ce sont des choix difficiles à prendre et, comme le reconnaît Shuttleworth lui-même, faire ces choix demande beaucoup de discipline.
Partie 1 - Paragraphe 4
Although time-based cycles can work well for some projects, attempting to force all projects to adopt this approach and then correlate these universally could seriously degrade the development process. If projects begin to depend on synchronization, then delays at any level of the stack would cause disruption to every other layer. This could put enormous pressure on individual projects to stick to the plan, even if doing so would be detrimental to the program and to its end users.
Même si des cycles réguliers peuvent bien convenir pour certains projets, tenter d'imposer l'adoption de cette approche à tous les projets et ensuite les faire correspondre universellement pourrait gravement endommager le processus de développement. Si les projets deviennent dépendants de la synchronisation, alors un retard à n'importe quelle étape aurait des conséquences sur toutes les autres étapes. Chaque projet subirait alors une pression énorme pour tenir les délais et ce serait néfaste pour le programme et ses utilisateurs finaux.
Partie 2
Using branching to simplify time-based releases
L'utilisation des branches pour faciliter des sorties régulières
Partie 2 - Paragraphe 1
Shuttleworth argues that proper tools—particularly version control systems with strong branching and merging capabilities—can make this problem obsolete. He specifically refers to Bazaar, which is a version control system designed by Canonical that integrates with the company's Launchpad development platform. I've been testing Bazaar extensively over the past two weeks while researching distributed version control technologies, and I can certainly appreciate Shuttleworth's argument.
D'après Shuttleworth, les bons outils, en particulier des systèmes de contrôle de version possédant de bonnes capacités de création de branches et de fusion, peuvent rendre ce problème obsolète. Il se réfère spécifiquement à Bazaar, un système de contrôle de version mis au point par Canonical qui s'intègre à la plateforme de développement Launchpad de l'entreprise. J'ai beaucoup testé Bazaar durant ces deux dernières semaines en cherchant des technologies de contrôle de version distribuées et je ne peux qu'être d'accord avec l'argument de Shuttleworth.
Partie 2 - Paragraphe 2
Bazaar makes it very easy to bring the steady stream of minor changes from trunk back into branches where major features are being developed so that those features can be seamlessly merged into trunk when they are finished. Using this approach—where most of the actual development is happening in branches—is naturally conducive to a situation where the code in trunk is consistently more robust than it would be otherwise. Shuttleworth takes this idea a step further and theorizes that when this approach is used in conjunction with automated unit testing, the code in trunk will be perpetually ready for release at any given time.
Bazaar rend très facile le portage du flot continue de petits changements du tronc vers les branches où les fonctionnalités importantes sont développées afin que ces fonctionnalités puissent être fusionnées sans accroc dans la branche principale quand elles sont achevées. En utilisant cette approche, où la majeure partie du développement est faite dans des branches, le code dans le tronc est naturellement et systématiquement plus robuste qu'il ne le serait autrement. Shuttleworth va même plus loin encore et théorise que lorsque cette approche est employée en parallèle à des tests automatisés le code dans le tronc est toujours prêt à être sorti à n'importe quel moment.
Partie 2 - Paragraphe 3
"A comprehensive test suite [...] lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change," Shuttleworth wrote in a blog entry yesterday.
"Un ensemble de tests complet [...] vous permet d'être plus ouvert aux gros ajouts au tronc parce que les tests assurent les fonctionnalités que les gens ont avant l'ajout. Un ensemble de tests agit comme un champ de force, il protège l'intégrité du code dont le comportement était connu le jour précédent face au changement perpétuel." écrivait Shuttleworth dans un article sur son blog hier.
--daria 12 juin 2008 à 18:50 (CEST):
"Un ensemble de tests complet ou un ensemble de tests complets ?
Partie 2 - Paragraphe 4
"Most of the projects I'm funding now have adopted a tests-before-landings approach, where landings [in] trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can't argue with the robot! The beauty of this is that your trunk is 'always releasable'. That's not *entirely* true; you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always."
"La plupart des projets que je finance maintenant ont adopté une politique de tests avant ajout, les ajouts au tronc sont gérés par un robot qui refuse de valider l'ajout s'il ne satisfait pas à tous les tests. Vous ne pouvez pas discuter avec un robot ! Ce que je trouve beau là-dedans est que le tronc est toujours dans un état publiable. Ce n'est pas complètement vrai ; on peut toujours faire un peu plus de Questions-Réponses avant de sortir quelque chose, mais vous avez cette formidable assurance que l'ensemble de tests est toujours satisfait. Toujours."
Partie 2 - Paragraphe 5
Test suites and really good version control systems can simplify development and improve the quality of code, but they are not a panacea. Shuttleworth vastly overstates the capacity of these tools to mitigate the problems associated with time-based release cycles. Bugs will always crop up when major new features are merged into existing code and sometimes those bugs require pushing back on release dates. When developers can't or won't do that, the quality of the release will obviously suffer.
Les ensembles de tests et les très bons systèmes de contrôle de version peuvent simplifier le développement et améliorer la qualité du code, mais ils ne sont pas la panacée. Shuttleworth surestime largement la capacité de ces outils à pallier aux problèmes associés aux sorties régulières. Des bogues surgiront toujours quand de grosses nouveautés sont fusionnées au code existant et parfois ces bogues nécessitent un report de la date de sortie. Si les développeurs ne peuvent ou ne veulent pas faire ça, la qualité du logiciel s'en retrouvera forcément affectée.
Partie 3
Ubuntu 8.04 demonstrates why strict schedules are undesirable
Ubuntu 8.04 est le parfait exemple de la voie à ne pas suivre
Partie 3 - Paragraphe 1
To witness the decline in quality that results from an uncompromising commitment to a time-based release cycle, one need look no further than the latest version of Ubuntu. Shuttleworth touts Ubuntu 8.04 as an example of smarter release management and argues that it demonstrates the Ubuntu developers' ability to adhere to a strict schedule.
Pas besoin de chercher très loin pour constater la baisse de qualité résultante d'un engagement sans compromis à un cycle de sorties régulières, prenez l'exemple de la dernière version d'Ubuntu. Shuttleworth vente Ubuntu 8.04 comme l'exemple d'une gestion plus intelligente des sorties et soutient qu'il démontre la capacité des développeurs à s'en tenir à un programme strict.
Partie 3 - Paragraphe 2
"8.04 LTS represented a very significant step forward in our release management thinking. To the best of my knowledge there has never been an 'enterprise platform' release delivered exactly on schedule, to the day, in any proprietary or Linux OS," wrote Shuttleworth in a blog entry. "Not only did it prove that we could execute an LTS release in the standard six-month timeframe, but it showed that we could commit to such an LTS the cycle beforehand. Kudos to the technical decision-makers, the release managers, and the whole community who aligned our efforts with that goal."
"8.04 LTS représente pour nous un grand pas en avant dans notre conception de la gestion d'une sortie. Pour autant que je sache, jamais une sortie de cette envergure ne s'est faite exactement le jour prévu jusqu'à maintenant, dans le monde des OS propriétaires ou des OS libres." commente Shuttleworth sur son blog. "Nous avons non seulement démontré que l'on peut préparer une version LTS dans les 6 mois impartis, mais cela prouve également que l'on peut s'engager par anticipation sur un tel cycle LTS. Félicitations aux preneurs de décisions techniques, aux responsables version et à toute la communauté qui a calqué nos efforts sur le but fixé."
--Olivier 6 juin 2008 à 16:04 (CEST):
La fin de l'avant dernière phrase est bizarre, autres propositions de traduction bienvenues !
Partie 3 - Paragraphe 3
Ubuntu 8.04, which was released last month, is a long-term support (LTS) release, which means that it will be supported on the desktop for three years and on the server for five years. From the start, Shuttleworth told users that quality and robustness would be the big focus for 8.04 and that it would be built to last. Unfortunately, it fell short of those expectations and shipped with a few serious bugs. The most frustrating problem that we noted in our review of Ubuntu 8.04 is the broken PulseAudio configuration, which harms both audio and video functionality.
Ubuntu 8.04, qui est parue le mois dernier, est une version avec support à long terme (LTS pour Long Terme Support), ce qui signifie qu'elle sera maintenue trois ans pour la version Desktop et 5 ans pour la version serveur. Depuis le début, Shuttleworth affirmait aux utilisateurs que la qualité et la fiabilité seraient les mots d'ordre pour la 8.04 et qu'elle serait faite pour durer. Malheureusement, la version n'a pas atteint ces objectifs et est sortie avec quelques bogues importants. Le problème le plus frustrant que nous avons relevé dans notre test d'Ubuntu 8.04 est la configuration de PulseAudio défective, qui affecte à la fois les fonctionnalités audio et vidéo.
Partie 3 - Paragraphe 4
A short delay would have made it possible to resolve problems of that nature before the release, but that never happened—perhaps because the commitment to releasing on time trumped the commitment to quality. Some might argue that a weak release is not a problem because bugs can be fixed in minor point updates after the initial release.
Un léger retard aurait permis de résoudre les problèmes de ce genre avant la sortie, mais ce n'est jamais arrivé, peut-être parce que l'engagement de faire la sortie à temps l'a emporté sur l'engagement sur la qualité. Certains diront qu'une version défaillante n'est pas un problème parce que les bogues peuvent être réparés par des petites mises à jour après sa sortie.
Partie 3 - Paragraphe 5
"Large deployments will wait for the first point release or two in any event," Shuttleworth points out in response to a comment on his blog. I suspect that I'm not the only one who thought of Microsoft's service packs after seeing that remark. But isn't the value of an official release that it provides some kind of quality guarantee? If releases are based on an arbitrary line in the chronological sand rather than completeness, they cease to have any meaning or relevance to end users.
"Les grands déploiements attendent la première ou la deuxième version consolidée de toute façon" fait noter Shuttleworth en réponse à un commentaire sur ton blog [NdT : La sortie de Ubuntu 8.04.1 est prevue pour le [3 juillet]. Je me doute que je ne suis pas seul à avoir penser aux Service Packs de Microsoft en voyant cette remarque. Mais une version officielle n'est-elle pas censée être un gage de qualité ? Si les sorties sont basées sur des jalons arbitraires posés sur une chronologie plutôt que sur l'avancement alors elles perdent leur sens ou leur pertinence pour les utilisateurs finaux.
Partie 4
Other approaches
D'autres approches
Partie 4 - Paragraphe 1
Release cycles should be flexible, and developers should be able to adjust the duration as needed to fit their activity. Different projects have very different development cultures and goals, which necessarily implies the need for different release management strategies. Shuttleworth's call for synchronization reflects an inability to recognize the value and scope of diversity in the open source software community. Distributions that aim for different audiences and have different priorities might not fit into the same patterns as mainstream desktop distributions like Ubuntu. There are also many large cross-platform open source software applications—like the Firefox web browser, for instance—that have large audiences on other operating systems and may have more important release considerations to account for than Linux distribution release cycles.
Les cycles de sortie devraient être flexibles et les développeurs devraient pouvoir en ajuster la durée pour qu'ils collent à leur activité. Selon les projets, la culture de développement et les buts peuvent être très différents, les stratégies de publication sont par conséquent différentes. L'appel de Shuttleworth en faveur d'une synchronisation reflète une inhabilité à reconnaître la valeur et la profondeur de la diversité dans la communauté des logiciels open source. Des distributions qui visent des publics différents et qui ont des priorités différentes pourraient ne pas rentrer dans le même moule que les distributions généralistes comme Ubuntu. On retrouve également des logiciels open source multi-plateformes, comme le navigateur Web Firefox par exemple, qui réunissent beaucoup d'utilisateurs sur d'autres systèmes d'exploitation et qui peuvent avoir d'autres priorités que la fréquence de sortie des distributions Linux.
Partie 4 - Paragraphe 2
I should note here that I am not categorically rejecting all of Shuttleworth's arguments. Although I strongly oppose a top-down, central planning approach to release synchronization, there could still be value in closer scheduling alignment between a few major desktop distributions that already have similar goals, technologies, and methodologies.
Je tiens à dire quand même que je ne rejette pas catégoriquement les idées de Shuttleworth. Même si je suis vraiment contre une approche descendante et centralisée de la planification des sorties synchronisées je pense qu'il y pourrait y avoir des bénéfices à tirer d'un meilleur alignement du calendrier de quelques distributions principales qui partagent déjà des buts, une technologie et une méthodologie similaires.
Partie 4 - Paragraphe 3
A certain level of release attunement already exists (Fedora 9, Ubuntu 8.04, and OpenSolaris 2008.05 were all released within weeks of each other) and I'm convinced that the best results can be achieved by allowing this trend to grow organically. Encouraging too much interdependence, however, creates serious risks, and this seems clearly like an area where careful planning and set-in-stone scheduling will do more harm than good.
La simultanéité des sorties est déjà à l'ordre du jour (Fedora 9, Ubuntu 8.04 et OpenSolaris 2008.05 ont toutes vu le jour à quelques semaines d'intervalle) et je suis convaincu que de meilleurs résultats sont atteignables si on laisse cette tendance se développer d'elle-même. Encourager trop d'interdépendance créerait des risques sévères, on parle d'un domaine où une planification consciencieuse et un calendrier gravé dans la roche seraient à l'origine de plus de problèmes qu'ils n'en résolvent.
Partie 4 - Paragraphe 4
KDE developer Aaron Seigo is one of several critics who have expressed cogent and insightful concerns about Shuttleworth's proposal. Seigo points out repeatedly that the kind of synchronization that Shuttleworth wants increases integration efficiency at the cost of developer efficiency—a tradeoff that he argues is ultimately counterproductive because development is where value in software originates.
Aaron Seigo, développeur KDE, est l'un des détracteurs ayant exprimé des inquiétudes convaincantes et perspicaces au sujet de la proposition de Shuttleworth. Seigo met à plusieurs reprises en avant que le genre de synchronisation que souhaite Shuttleworth améliore l'efficacité d'intégration au dépend de l'efficacité des développeurs, une concession qu'il décrit comme contre-productive car c'est dans le développement que se trouve le richesse des logiciels.
Partie 4 - Paragraphe 5
"Mark talked about lean processes, but only from the integration point of view; there are lean process in development as well, and defining the development cycle by the release cycle, particularly the wrong one, erodes the leanness of the development process," Seigo wrote in a blog entry. "Remember that it is the development process that delivers nearly all the value in a Linux distribution. The distributions make that value accessible to the masses and create new kinds of value on top of it (support, marketing, etc) but it is the development not the integration that is primary source of the value. It should then be obvious that the development process is not something you screw with lightly."
"Mark parle de processus en flux tendu, mais seulement du point de vue de l'intégration ; il existe aussi des processus en flux tendu dans le développement et définir le cycle de développement à l'aune du cycle de sorties, surtout s'il n'est pas bon, érode la fluidité du flux de développement", écrit Seigo dans un article. "Il ne faut pas oublier que c'est le processus de développement qui fait toute la valeur d'une distribution Linux. La distribution rend cette valeur accessible à grande échelle et crée un autre type de valeur ajoutée par-dessus (le support, le marketing, etc.) mais c'est le développement, pas l'intégration, qui est la source primaire de valeur. Il devrait alors être évident que le processus de développement n'est pas quelque chose qu'on peut prendre comme ça à la légère."
Partie 4 - Paragraphe 6
Seigo proposes an alternative that would facilitate synchronized downstream releases without requiring synchronization or disruption upstream. The distributions, he says, should manage the releases themselves by creating their own branches within the constraints of their own predetermined timelines.
Seigo propose une altérnative qui faciliterait la synchronisation en aval sans nécessiter de synchronisation ou de chamboulement en amont. D'après lui, les distributions devraient gérer par elle-mêmes les sorties en créant leurs propres branches en tenant compte des contraintes de leurs propres cycles.
Partie 4 - Paragraphe 7
"Given that there is a hunger for synchronized release cycles for downstream... why doesn't downstream take on producing releases? Why not cease waiting for tarballs to be delivered to your doorstep and start working on a release engineering service!" Seigo suggests. "Why not have the system integration community (mostly the OSVs, really) come together and branch things for release at a certain point in time, defined by them, and work with upstream on stabilization of that branch? Instead of hoping that upstream does what they want, why don't they rally a bunch of cohorts from Novell, Red Hat, Debian, Mandriva, the MacOS and Windows communities, Canonical and whomever else wishes to engage and start offering a real, serious release process for upstream development to filter into?"
"Puisqu'il y a cet appétit en aval pour des cycles de parution synchronisés... pourquoi est-ce que l'aval ne prendrait pas en charge les sorties ? Pourquoi pas arrêter d'attendre que les tarballs soient livrées devant leur porte et mettre en place une équipe de publication !" suggère Seigo. "Pourquoi ne pas demander à la communauté d'intégration (les vendeurs de systèmes d'exploitation en gros) de coordonner leur efforts pour créer une branche en vue d'une sortie à un moment donné, moment qu'ils définissent eux-mêmes, et travailler avec l'amont pour la stabilisation de cette branche ? Plutôt que d'espérer que l'amont fasse ce qu'ils désirent, pourquoi ne peuvent-ils pas regrouper un tas de gars des communautés de chez Novell, Red Hat, Debian, Mandriva, MacOS et Microsoft, de chez Canonical ou encore de chez n'importe qui qui voudrait s'impliquer et offrir un vrai processus sérieux de sortie par lequel l'amont pourrait s'intégrer naturellement ?"
Partie 4 - Paragraphe 8
Segio's suggestion is more viable than Shuttleworth's proposal. It would enable individual Linux distributions to gain many of the practical advantages of synchronization that benefit end users without having to disrupt or synchronize upstream development cycles. It would, however, create some additional costs and challenges for distributors and shift most of the burden of release management over to them. Seigo argues that if the distributors really want synchronized downstream releases badly enough, then they will accept those burdens and come up with a clear plan for making it happen.
Les suggestions de Seigo sont plus viables que les propositions de Shuttleworth. Elles permettraient aux distributions Linux d'obtenir une majorité des avantages pratiques de la synchronisation dont bénéficieraient les utilisateurs finaux sans avoir à bouleverser ou synchroniser le développement en amont. Cela engendrerait cependant un coût additionnel et un défi nouveau pour les distributeurs et leur ferait porter le poids de la gestion des sorties. Seigo assure que si les distributeurs veulent vraiment des sorties synchronisées en aval autant que ça ils seront prêts à accepter cette charge supplémentaire et trouveront un bon moyen pour y parvenir.
Partie 4 - Paragraphe 9
This discussion is likely to continue for some time as the major stakeholders articulate their various perspectives. Communication has already moved the debate forward in many ways and brought to the surface some compelling alternatives and variations on the initial proposal. The final outcome could have some broad implications for how open-source software programs and distributions handle release management, but right now none of the proposed ideas are mature enough for widespread implementation.
Il est bien probable que cette discussion dure pendant encore quelques temps à mesure que les acteurs principaux pèsent le pour et le contre. La communication a déjà fait avancer le débat de bien des manières et a déjà fait émerger des alternatives attirantes et des variations de la proposition initiale. Le résultat final pourrait avoir des implications importantes sur la gestion des sorties par les logiciels open-source et les distributions, mais pour l'instant aucune des idées proposées n'est suffisamment mature pour être appliquée à grande échelle.
