Payer ou ne pas payer: Leçons d'Ubuntu et de Debian

Benjamin Mako Hill <mako@atdot.cc>

15 mai 2005; Révisé le 7 août 2005

Traduction française par Avice Robitaille. [Texte original en anglais/Original text in English.]

La première version de cet article a été écrite à une conférence acceptée donnée à Linuxtag 2005 donnée à Karlsruhe, en Allemagne.

Introduction

La croissance explosive des logiciels libres et open source au cours de la dernière décennie a été reflétée par une croissance tout aussi explosive de l'ambition des projets de logiciels libres dans le choix et la résolution des problèmes. Le mouvement du logiciel libre aborde ces grands problèmes avec plus de code et avec des communautés plus vastes qu'on ne le pensait il y a dix ans. Des exemples de ces projets massifs incluent des environnements de bureau—comme GNOME et KDE—et des distributions comme Debian, RedHat et Gentoo.

Ces projets s'appuient sur le travail de milliers de programmeurs—bénévoles et payés—et produisent des millions de lignes de code. Leur logiciel est utilisé par des millions d'utilisateurs ayant des besoins divers. Cet article se concentre sur deux effets majeurs de cette situation:

Pris ensemble, ces faits impliquent une communauté de logiciel libre de plus en plus réalisée dans laquelle les programmeurs dérivent souvent, mais où le forking traditionnel est souvent intenable. Les fourchettes, telles qu'elles sont traditionnellement définies, doivent être améliorées. Les communautés autour de grands projets de logiciels libres doivent être plus intelligentes dans le processus de dérivation qu'elles ne l'ont été dans le passé.

Nous voyons déjà cela avec les distributions GNU / Linux. Les nouvelles distributions sont rarement construites à partir de zéro aujourd'hui. Au lieu de cela, ils ont adapté et construit sur le travail des projets existants. À mesure que les projets et les bases d'utilisateurs se développent, ces distributions dérivées sont de plus en plus courantes. La plupart de ce que je décris dans cet essai sont des outils et des expériences de distributions dérivées.

Les concepteurs de logiciels doivent poursuivre l'idée d'un écosystème de projets de logiciels libres et de produits qui ont fourchu mais qui maintiennent une relation étroite au fur et à mesure qu'ils se développent parallèlement et en symbiose. Pour ce faire, les développeurs doivent:

Ce document est une première analyse de cet ensemble de problèmes. En tant que tel, il est fortement axé sur l'expérience du projet Ubuntu et son existence en tant que distribution dérivée de Debian. Il tire également de mon expérience avec Debian-NP et la communauté CDD (Custom Debian Distribution). Depuis que je participe aux projets Ubuntu et CDD, ce sont des domaines que je peux discuter avec un certain degré de connaissances et d'expérience.

"Fork" est un mot de quatre lettres

Le fait de prendre le code d'un projet de logiciel libre et de le bifurquer pour créer un nouveau projet s'appelle "forking". Il y a eu un certain nombre de célèbres forks dans l'histoire du logiciel libre. L'un des plus célèbres était le schisme qui a conduit au développement parallèle de deux versions de l'éditeur de texte Emacs: GNU Emacs et XEmacs. Ce schisme persiste jusqu'à ce jour.

Certaines fourches, comme Emacs et XEmacs, sont permanentes. D'autres sont relativement de courte durée. Un exemple de ceci est le projet GCC qui a vu deux fourchettes—EGCS et PGCC—qui ont finalement fusionné dans GCC. Forking peut arriver pour un certain nombre de raisons. Souvent, les développeurs d'un projet développent des différences politiques ou personnelles qui les empêchent de continuer à travailler ensemble. Dans certains cas, les mainteneurs ne répondent plus et d'autres développeurs bifurquent pour maintenir le logiciel en vie.

En fin de compte cependant, la plupart des fourchettes se produisent parce que les gens ne sont pas d'accord sur les caractéristiques, les mécanismes ou la technologie au cœur d'un projet. Les gens ont des objectifs différents, des problèmes différents et veulent des outils différents. Souvent, ces objectifs, problèmes et outils sont similaires jusqu'à un certain point avant que le besoin de se séparer devienne essentiel.

Une fourchette se produit au niveau du code mais une fourchette n'est pas simplement—ou même principalement—technique. De nombreux projets créent des "branches". Les branches sont des versions alternatives d'un logiciel utilisé pour expérimenter des fonctionnalités et des correctifs intrusifs ou instables. Les fourchettes se distinguent des succursales en ce qu'elles sont souvent des départs plus importants d'un point de vue technique (c.-à-d. Que plus de lignes de code ont été modifiées et / ou que les changements sont plus invasifs ou représentent une refonte plus fondamentale du problème). sont des bifurcations définies en termes sociaux et politiques. Les branches impliquent un seul développeur ou une communauté de développeurs—même si elle se résume à des sous-groupes distincts au sein d'une communauté—tandis que les forks sont des projets distincts.

La fourchette a toujours été considérée comme une mauvaise chose dans les communautés de logiciels libres: on pense qu'elles découlent de l'incapacité des gens à travailler ensemble et ont abouti à la reproduction du travail.Quand j'ai publié la première version du HOWTO de gestion de projet de logiciel libre il y a plus de quatre ans, j'ai inclus une petite section sur le forking qui décrivait le concept aux futurs chefs de projet de logiciel libre avec ce texte:

La version courte de la section fourche est, ne les faites pas. Forks oblige les développeurs à choisir un projet avec lequel travailler, provoquer de mauvaises divisions politiques et redondance du travail.

Dans les meilleures situations, une fourchette signifie que deux groupes de personnes doivent continuer à développer des fonctionnalités et à effectuer le travail qu'ils font habituellement en plus de suivre le projet forké et de devoir sélectionner et appliquer des fonctionnalités et des correctifs à leur propre base de code. . Ce niveau de surveillance et de comparaison constante peut être extrêmement difficile et fastidieux. La situation n'est pas aidée de manière significative par les outils de contrôle de sources traditionnels tels que diff, patch, CVS et Subversion qui ne sont pas optimisés pour cette tâche. La situation pire (et beaucoup plus commun) se produit lorsque deux groupes font leur travail ignorant ou partiellement ignorant du code étant coupé de l'autre côté de la fourche. Les fonctions et les correctifs importants sont implémentés deux fois, différemment et de manière incompatible.

Le côté positif le plus important de ces inconvénients est que les problèmes associés au forking sont si graves et si notoires que, dans la plupart des cas, la menace d'une fourchette suffit à forcer les responsables à trouver des solutions qui empêchent la fourche de se produire. .

Enfin, il vaut la peine de souligner que la fourchette est quelque chose d'un terme contesté. Parce que les définitions des fourchettes impliquent, à un degré ou à un autre, des déclarations sur les distinctions politiques, organisationnelles et techniques entre les projets, les bifurcations que beaucoup appellent des branches ou des arbres parallèles sont décrites par d'autres comme des fourchettes. Récemment, alimenté par l'avènement des systèmes de contrôle de version distribués, la définition de ce qui est et n'est pas une fourchette est devenue de plus en plus floue. En partie à cause des mêmes systèmes, les avantages et les inconvénients de ce que l'on appelle de plus en plus un problème de forking sont également discutables.

Étude de cas

Dans mon introduction, j'ai décrit comment la portée croissante des projets de logiciels libres et la communauté de plus en plus grande et la diversité des communautés d'utilisateurs conduisent à la nécessité d'un nouveau type de dérivation qui évite autant que possible les inconvénients du forking. Nulle part cela n'est plus évident que dans les plus grands projets avec la portée la plus large: un petit groupe de projets qui inclut des distributions de système d'exploitation.

Le projet Debian

Le projet Debian est de loin la plus grande distribution de logiciels libres en termes de code. C'est aussi, sans doute, le plus grand projet de logiciel libre en termes de nombre de volontaires. Debian comprend plus de 15 000 paquets et le travail de plus de 1 000 bénévoles officiels et de nombreux autres contributeurs sans adhésion officielle. Les projets sans la base de volontaires massive de Debian ne peuvent pas reproduire ce que Debian a accompli; ils peuvent rarement espérer même maintenir ce que Debian a produit.

Au moment où ce document a été écrit, Distrowatch répertorie 129 distributions basées sur Debian [1]—la plupart d'entre elles sont actuellement actives à des degrés divers. Chaque distribution représente au moins une personne—et dans la plupart des cas une communauté de personnes—qui était en désaccord assez fort avec la vision ou la direction de Debian pour vouloir créer une nouvelle distribution et qui avait la capacité technique pour atteindre cet objectif. Malgré le slogan de longue date de Debian—«le système d'exploitation universel»—le fait que le projet Debian soit devenu le système d'exploitation le plus dynamique tout en engendrant tant de dérivés témoigne du fait que, en ce qui concerne les logiciels, une taille ne peut pass'adapter à tous. [2]

Sur le plan organisationnel, les déribeurs Debian sont situés à l'intérieur et à l'extérieur du projet Debian. Un groupe de dépositaires travaillant au sein du projet Debian s'est fait baptiser "Custom Debian Distributions" et a créé près d'une douzaine de projets personnalisés et dérivés de Debian pour des groupes spécifiques d'utilisateurs, notamment la communauté médicale, les avocats, les enfants et bien d'autres. . [3] Ces projets s'appuient sur la distribution Debian et les archives canoniques à l' intérieur des limites organisationnelles et politiques du projet Debian et cherchent constamment à minimiser le delta en se concentrant sur des changements moins invasifs et en avançant des moyens créatifs la base de code Debian par le biais de procédures établies et conformes à la politique.

Un deuxième groupe de personnalisateurs Debian comprend ceux qui travaillent en dehors du projet Debian sur le plan organisationnel. Notons parmi cette liste (par ordre alphabétique) Knoppix, Libranet, Linspire (anciennement Lindows), Progeny, MEPIS, Ubuntu, Userlinux et Xandros.Avec sa base technologique solide, une excellente gestion des paquets, une large sélection de paquets à choisir, et un fort engagement envers la liberté logicielle qui assure la dérivabilité, Debian fournit un point idéal à partir duquel créer une distribution GNU / Linux.

Ubuntu

Le projet Ubuntu a été lancé par Mark Shuttleworth en avril 2004 et la première version a été construite presque entièrement par un petit groupe de développeurs Debian employés par la société Canonical Limited de Shuttleworth. [4] Il a été libéré au monde vers la fin de 2004. La deuxième version a été libérée six mois plus tard en avril 2005. Les buts d'Ubuntu sont de fournir une distribution basée sur un sous-ensemble de Debian avec:

Le projet Ubuntu fournit un exemple intéressant d'un projet qui vise à dériver de Debian dans une large mesure. Ubuntu a apporté des modifications au niveau du code à près de 1300 paquets dans Debian au moment où ce document a été écrit et la vitesse des changements ne décélère pas avec le temps; le nombre total de changements et la taille totale du delta vont augmenter. [5] Les changements apportés par Ubuntu sont principalement les plus intrusifs—des changements au code lui-même.

Cela dit, le projet Ubuntu est explicite sur le fait qu'il ne pourrait pas exister sans le travail effectué par le projet Debian. [6] Plus important encore, Ubuntu explique qu'il ne peut pas continuer à fournir l'ensemble complet de paquets dont ses utilisateurs dépendent sans le travail en cours par le projet Debian. Même si Ubuntu a apporté des modifications aux paquets de près de 1300, cela représente moins de dix pour cent du total des paquets expédiés sous Ubuntu et tirés de Debian.

Scott James Remnant, un développeur Debian proéminent et un hacker sur Ubuntu qui travaille pour Canonical Ltd., a décrit la situation de cette façon sur son web pour présenter la méthodologie de développement d'Ubuntu dans la semaine suivant la première annonce publique de Canonical et Ubuntu: ]

Je ne pense pas qu'Ubuntu soit une "fourchette" de Debian, du moins pas dans le sens traditionnel. Une fourchette suggère qu'à un moment donné, nous nous séparons de Debian et que, de temps en temps, nous fusionnons dans les changements alors que nous poursuivons notre propre chemin.

Notre modèle est assez différent. Tous les six mois, nous prenons un instantané de la distribution instable de Debian, nous appliquons tous les correctifs en suspens de notre dernière version et nous passons quelques mois à les tester et à les corriger.

Une chose qui devrait être évidente à partir de ceci est que notre travail est beaucoup plus facile si Debian prend tous nos changements. Le modèle nous encourage réellement à redonner à Debian.

C'est pourquoi, dès le premier jour où nous avons commencé à corriger les bogues, nous avons commencé à envoyer les correctifsà Debian via le BTS. Non seulement cela rendra notre travail tellement plus facile quand nous aurons à geler pour "hoary", notre prochaine version, mais c'est exactement ce que tout dérivé devrait faire en premier lieu.

Il y a un débat sur la mesure dans laquelle les développeurs d'Ubuntu ont réussi à atteindre les objectifs fixés par Remnant. Ubuntu a déposé des centaines de correctifs dans le système de suivi des bogues, mais il a également eu des problèmes pour décider de ce qui devrait être renvoyé à Debian. De nombreux changements ne sont tout simplement pas pertinents pour les développeurs Debian. Par exemple, ils peuvent inclure des modifications apportées à un paquet en réponse à une autre modification effectuée dans un autre paquet dans Ubuntu qui ne sera pas ou n'a pas été prise par Debian. Dans de nombreux autres cas, la meilleure action en ce qui concerne un changement particulier, un package particulier et un développeur Debian particulier en amont est tout simplement floue.

Le bilan du projet Ubuntu en travaillant de manière constructive avec Debian est, pour le moment, mitigé. Tandis qu'un nombre croissant de développeurs Debian maintiennent activement leurs paquets dans les deux projets, beaucoup dans Debian et Ubuntu pensent qu'Ubuntu a du travail à faire pour atteindre son propre objectif de créer une relation productive avec Debian.

Cela dit, l'importance des objectifs décrits par Remnant dans le contexte du modèle de développement d'Ubuntu ne peut pas être surestimée. Chaque ligne de delta entre Debian et Ubuntu a un coût pour les développeurs Ubuntu. La technologie, les pratiques sociales et les choix judicieux peuvent réduire ce coût mais ne peuvent l'éliminer. Les ressources qu'Ubuntu peut utiliser pour résoudre le problème de la construction d'une distribution sont limitées—beaucoup plus limitées que celles de Debian. En conséquence, il y a une limite à la façon dont Ubuntu peut diverger; il est toujours avantageux pour Ubuntu de minimiser le delta dans la mesure du possible.

Applicabilité

Ubuntu et Debian sont des distributions et, en tant que telles, fonctionnent à une échelle différente de la grande majorité des projets de logiciels libres. Ils comprennent plus de code et plus de personnes. Par conséquent, on se demande si les expériences et les leçons tirées de ces projets sont particulièrement applicables à l'expérience des petits projets de logiciels libres.

De toute évidence, en raison des difficultés associées au fait de devoir énoncer une quantité massive de code et des problèmes associés à la duplication du travail de grandes bases de volontaires, les distributions sont obligées de trouver un moyen d'équilibrer les avantages et les inconvénients du forking. Cependant, alors que le besoin est plus fort et plus immédiat dans les grands projets, les avantages de leurs solutions seront souvent entièrement transférables.

Il est clair que la modification du logiciel libre pour mieux répondre aux besoins de ses utilisateurs est au cœur du succès du mouvement du logiciel libre. Cependant, alors que la modification se présente généralement sous la forme d'une collaboration sur une seule base de code, elle est fonction des limites des méthodologies et des outils de développement logiciel plutôt que de la meilleure réponse aux besoins ou aux désirs des utilisateurs ou des développeurs.

Je crois que l'avantage fondamental du logiciel libre dans la prochaine décennie sera dans la capacité croissante d'un seul projet de logiciel libre d'être multiple pour plusieurs utilisateurs simultanément. Cela se traduira par le fait que, dans les dix prochaines années, la technologie et les processus sociaux évolueront, de sorte que le forking est de moins en moins une mauvaise chose. La méthodologie de développement de logiciels libres deviendra moins dépendante d'un seul projet et commencera à mettre l'accent sur le développement parallèle au sein d'un écosystème de projets connexes. Le résultat est que les projets de logiciels libres obtiendront un avantage concurrentiel par rapport aux projets logiciels propriétaires grâce à leur capacité à mieux répondre aux besoins de plus en plus diversifiés de bases d'utilisateurs de plus en plus grandes et de plus en plus diversifiées.Bien que cela semble paradoxal aujourd'hui, plus de projets dériveront et moins de code redondant sera écrit.

Les projets plus limités en termes de code et de portée peuvent utiliser les outils et méthodes décrits dans le reste de ce document dans des combinaisons différentes, de différentes manières et à des degrés différents de ceux des distributions présentées ici. Différents projets avec des besoins différents trouveront que certaines solutions fonctionnent mieux que d'autres. Parce que les communautés de la taille de Debian sont difficiles à bifurquer d'une manière bénéfique pour n'importe quel parti, c'est dans ces communautés que les technologies et les méthodologies de développement commencent à émerger. Avec le temps, ces stratégies et outils seront utilisés de manière productive dans une grande variété de projets avec un large éventail de tailles, de besoins, d'étendues et de descriptions.

Équilibrer la fourchette avec la collaboration

Dérivation et analyse de problèmes

L'étape la plus facile dans la création d'un projet de logiciel dérivé productif est de décomposer les problèmes de dérivations en une série de différentes classes de modification. Certains types de modifications sont plus faciles à réaliser et sont intrinsèquement plus faciles à maintenir.

Dans le contexte des distributions, le problème de la dérivation peut être décomposé en les types de changements suivants (classés en fonction de l'intrusion inhérente à la résolution du problème et de la gravité des problèmes de maintenabilité à long terme qu'ils introduisent):

  1. Sélection de pièces individuelles de logiciels;

  2. Modifications de la façon dont les paquets sont installés ou exécutés (par exemple, dans un environnement de type Live CD ou en utilisant un programme d'installation différent);

  3. Configuration de différents logiciels

  4. Modifications apportées au progiciel (effectuées au niveau des modifications apportées au code des progiciels)

En décomposant le problème de cette manière, les déri- veurs de Debian ont pu approcher la dérivation d'une manière qui concentre d'abord l'énergie sur les problèmes les moins intrusifs.

Le premier domaine sur lequel Ubuntu se concentrait était de sélectionner un sous-ensemble de paquets qu'Ubuntu prendrait en charge. Ubuntu sélectionné et prend en charge environ 2.000 paquets. Ceux-ci sont devenus le composant principal d'Ubuntu. D'autres paquets dans Debian ont été inclus dans une section séparée de l'archive Ubuntu appelée univers, mais il n'était pas garanti qu'ils soient pris en charge avec des corrections de bogues ou de sécurité. En se concentrant sur un petit sous-ensemble de paquets, l'équipe d'Ubuntu a été en mesure de sélectionner une sous-section maintenable de l'archive Debian qu'ils pourraient conserver au fil du temps.

Les distributions dérivées les plus simples—travaillant souvent dans le projet Debian en tant que CDD mais incluant des projets comme Userlinux - sont simplement des listes de paquets et ne font rien en dehors de la sélection des paquets. L'installation de listes de paquets et la maintenance de ces listes au fil du temps peuvent être facilitées par la création de ce qu'on appelle des méta -paquets: des paquets vides avec de longues listes de "dépendances".

Le deuxième élément, les changements de configuration, a également un impact relativement faible. Mettre l'accent sur le fait de déplacer autant de changements que possible dans le domaine des changements de configuration est une stratégie durable qui permet aux concepteurs du projet Debian de travailler activement sur une base de code unique. Leur idée est que plutôt que de forcer un morceau de code en raison d'un désaccord sur la façon dont le programme devrait fonctionner, ils peuvent laisser le code intact mais ajouter la capacité de travailler différemment du logiciel. Cette fonctionnalité alternative est rendue modifiable grâce à un changement de configuration de la même manière que les applications sont configurées à travers les questions posées lors de l'installation. Puisque le projet Debian a un cadre de configuration de paquet unifié appelé Debconf, les concepteurs sont capables de configurer un système entier de manière très centralisée. [8]Ce n'est pas sans rappeler le Kickstart de RedHat bien que l'accent soit mis sur le maintien de ces changements de configuration au cours de la vie et de l'évolution du paquet; Kickstart se concentre uniquement sur l'installation du paquet.

Un troisième type de configuration est limité aux changements dans l'environnement à travers lequel un système est exécuté ou installé. Un exemple est l'installateur Debian de Progeny basé sur Anaconda qui fournit un autre programme d'installation mais aboutit à un système identique. Un autre exemple est le projet Knoppix qui est célèbre pour ses environnements "Live CD". Alors que Knoppix propose un large éventail de modifications invasives couvrant tous les éléments de ma liste ci-dessus, d'autres projets Live CD, dont le projet "Casper" d'Ubuntu, sont beaucoup plus proches d'un autre shell utilisant le même code.

Comme ces trois méthodes sont relativement non invasives, elles constituent des stratégies raisonnables pour les petites équipes et les personnes travaillant à la création d'une distribution dérivée. Cependant, de nombreux changements souhaitables—et dans le cas de certaines distributions dérivées, les changements les plus souhaitables—nécessitent des techniques plus invasives. Le type de changement final et le plus invasif—les changements au code - est le plus difficile mais aussi le plus prometteur et le plus puissant s'il peut être fait durablement. Les changements de ce type impliquent des bifurcations de la base de code et seront le sujet du reste de cet article.

Contrôle de source distribué

Une méthode prometteuse de maintenance des deltas dans les projets fourchus ou ramifiés réside dans les systèmes de contrôle de version distribués (VCS). Les systèmes VCS traditionnels fonctionnent de manière très centralisée. CVS, l'archétype du logiciel libre VCS et la base de beaucoup d'autres, est basé sur le modèle d'un serveur centralisé unique. Toute personne qui souhaite s'engager dans un projet doit s'engager dans le référentiel centralisé. Alors que CVS permet aux utilisateurs de créer des branches, toute personne ayant des droits de validation a accès à l'ensemble du référentiel. Les outils de branchement et de fusion dans le temps ne sont pas particulièrement bons.

Le modèle de branchement est principalement orienté vers un système où le développement est bifurqué, puis la branche est complètement fusionnée dans l'arbre principal. L'utilisation normale d'une branche peut inclure la création d'une branche de développement, la réalisation d'une série de versions de développement tout en conservant et corrigeant les bogues importants dans la branche primaire stable, puis en remplaçant la version stable par la version de développement. Le modèle CVS n'est pas orienté vers un système où un delta arbitraire, ou des ensembles de deltas, sont maintenus dans le temps.

Le contrôle de version distribuée vise à résoudre un certain nombre de problèmes introduits par CVS et mentionnés ci-dessus par:

En fin de compte, cela nécessite des outils qui permettent de mieux fusionner les changements et de ne pas fusionner certains changements lorsque c'est le comportement souhaité. Cela conduit également à des outils capables de fusionner avec l'histoire.

Le passage le plus célèbre à un modèle VCS distribué à partir d'un modèle VCS centralisé a été le déplacement par la communauté de développement du noyau Linux vers le système de contrôle de version distribuée propriétaire BitKeeper. Dans sa récente annonce de la décision de se séparer de BitKeeper, Linus Torvalds a déclaré:

En fait, l'un des impacts de BK est de nous amener fondamentalement (et moi en particulier) à changer notre manière de faire les choses. Cela va du suivi des modifications minutieuses à la façon dont j'ai fini par faire confiance aux sous-responsables avec des choses bien plus importantes, et ne pas avoir à travailler patch par patch. [9]

Au moment du changement, les outils de contrôle de version distribués gratuits étaient moins avancés qu'ils ne le sont aujourd'hui. Actuellement, une liste incomplète d'outils libres VCS inclut GNU Arch, Bazar, Bazaar-NG, Darcs, Monotone, SVK (basé sur Subversion), GIT (un système développé par Linus Torvalds en remplacement de BitKeeper) et d'autres.

Chacun de ces outils, au moins après avoir atteint un certain niveau de maturité, permet ou permettra aux utilisateurs de développer des logiciels de manière distribuée et, au fil du temps, de comparer leurs logiciels et de tirer des changements beaucoup plus facilement qu'ils ne le feraient autrement.L'idée de développement parallèle est au cœur du modèle. Les outils permettant de fusionner et de résoudre les conflits au fil du temps, et la capacité de sélectionner certains correctifs ou changements d'un développeur parallèle rendent chaque type de développement beaucoup plus utile que par le passé.

Les VCS fonctionnent entièrement au niveau du code. En raison de la nature des types de modifications que le projet Ubuntu apporte au code de Debian, Ubuntu s'est principalement concentré sur ce modèle et Canonical finance actuellement deux principaux produits de contrôle distribué—les projets Bazaar et Bazaar-NG.

À bien des égards, l'utilisation efficace du contrôle de version distribué est un problème beaucoup plus facile à résoudre pour les petits projets de développement de logiciels libres plus traditionnels que pour les distributions GNU / Linux. Comme les problèmes associés au maintien du développement parallèle d'un seul logiciel dans un ensemble de référentiels distribués connexes constituent le principal cas d'utilisation des systèmes de contrôle de version distribués, le VCS distribué peut être une solution technique pour certains types de développement parallèle. À mesure que les outils et les processus sociaux des VCS distribués évoluent, ils deviendront des outils de plus en plus importants dans le développement des logiciels libres.

Parce que les problèmes d'échelle associés à la construction d'une distribution dérivée complète sont plus compliqués que ceux associés au travail avec un seul projet "en amont", le contrôle de version distribuée est seulement maintenant activement déployé dans le projet Ubuntu. Ce faisant, le projet se concentre sur l'intégration de ceux-ci dans des outils spécifiques aux problèmes construits au-dessus du contrôle de version distribué.

Outils spécifiques au problème

Une autre technique expérimentée par Canonical Ltd. est la création d'outils de haut niveau basés sur des outils de contrôle de version distribués spécialement conçus pour maintenir la différence entre les paquets. Parce que les paquets sont généralement distribués comme un fichier source avec une collection d'un ou plusieurs patches, ceci introduit la possibilité unique de créer un système VCS de haut niveau basé sur ce fait.

Dans le cas d'Ubuntu et de Debian, l'outil idéal crée une branche par patch ou fonctionnalité et utilise des heuristiques pour analyser les fichiers de correctifs et créer ces branches intelligemment. La section du système de construction du paquet du patch total peut également être conservée comme une branche séparée. L'outil de Canonical, appelé Hypothetical Changeset Tool (HCT) (bien que n'étant plus hypothétique), est un moyen expérimental de créer une interface très simple et très simplifiée pour traiter un type particulier de source créé et distribué d'une manière particulière avec un type particulier de changement.

Alors que HCT promet d'être très utile pour les personnes qui font des distributions dérivées basées sur Debian, son application en dehors des distributeurs sera, selon toute vraisemblance, limitée. Cela dit, il fournit un exemple de la façon dont les outils spécifiques aux problèmes et au contexte peuvent jouer un rôle essentiel dans la maintenance du code dérivé de façon plus générale.

Solutions sociales

Il a été dit que c'est une folie commune d'un technophile de tenter d'employer des solutions techniques pour résoudre des problèmes sociaux.Le problème de la dérivation de logiciels est à la fois un problème technique et social et la résolution adéquate des problèmes plus vastes nécessite des approches qui prennent en considération les deux types de solutions.

Scott James Remnant compare la relation entre les distributions et les distributions dérivées comme étant similaire à la relation entre les distributions et les mainteneurs en amont:

Je ne pense pas que ce soit très différent de la façon dont les mainteneurs Debian interagissent avec leurs amont. En tant que responsables Debian, nous prenons et emballons les logiciels en amont, puis nous agissons comme une passerelle pour les bogues et les problèmes. Très souvent, nous corrigeons nous-mêmes les bogues et appliquons le correctif au paquet et l'envoyons en amont. Parfois, l'amont n'incorpore pas ce patch et nous devons nous assurer que nous ne le lâcherons pas accidentellement chaque fois que nous le lâcherons, nous le préférons de beaucoup s'ils le prennent, mais nous ne nous mettons pas en colère s'ils ne le font pas.

C'est ainsi que je vois la relation entre Debian et Ubuntu, nous ne sommes pas plus une bifurcation de Debian qu'un paquet Debian est un fork de son amont.

Scott fait allusion au fait que, au moins dans le monde des distributions, le développement parallèle est déjà une façon de voir le mode opératoire des distributions GNU / Linux existantes. La relation entre un dériver et un dérive sur le niveau de distribution reflète la relation entre la distribution et les auteurs «en amont» des paquets qui composent la distribution. Ces relations sont rarement basées sur des outils technologiques mais sont entièrement dans le domaine des solutions sociales.

Ubuntu a poursuivi un certain nombre d'initiatives différentes dans ce sens.La première a consisté à régulièrement déposer des bogues dans le système de suivi des bogues de Debian lorsque les bogues qui existent dans Debian sont corrigés dans Ubuntu. Bien que cela puisse être partiellement automatisé, le choix d'automatiser cela et la façon dont il est mis en place est purement social.

Cependant, comme je l'ai mentionné plus haut, Ubuntu est toujours confronté à des questions concernant les modifications apportées aux paquets qui ne corrigent pas nécessairement les bogues ou qui corrigent des bogues qui n'existent pas dans Debian mais pourraient le faire dans le futur.Certains développeurs de Debian veulent connaître toute l'étendue des changements apportés à leur logiciel sous Ubuntu, alors que d'autres ne veulent pas être dérangés. Ubuntu devrait continuer à travailler avec Debian pour trouver des moyens de permettre aux développeurs de rester synchronisés.

Il y a aussi plusieurs initiatives de développeurs dans Debian, Ubuntu et dans d'autres dérivations pour créer une relation plus forte entre le projet Debian et son écosystème de dériveurs et entre Ubuntu et Debian en particulier. Bien que la forme que cela prendra finalement ne soit pas claire, les projets existant dans un écosystème devraient explorer le domaine des relations sociales appropriées qui assureront qu'ils peuvent travailler ensemble et être informés du travail de chacun sans avoir à se «spammer» les uns avec les autres. ou des informations inutiles.

Une autre question qui a récemment joué un rôle important dans la relation Debian / Ubuntu est l'importance à la fois de donner un crédit suffisant aux auteurs ou mainteneurs en amont du logiciel sans que cela implique une relation plus étroite que ce qui est le cas. Derivers doit marcher sur une ligne de fichiers où ils créditent le travail des autres sur un projet sans que cela implique que les autres travaillent, le soutien, ou sont reliés au projet derivers auquel, pour toutes sortes de raisons, l'auteur « en amont » pourrait ne pas vouloir être associé.

Dans le cas de Debian et Ubuntu, ce qui a entraîné l'accent sur le maintien ou l'importation des entrées de changelog lorsque des modifications sont importées et à noter le pedigree des changements plus généralement. Il a récemment été discuté en termes de champ « mainteneur » dans chaque paquet dans Ubuntu. Ubuntu veut éviter de faire des changements à chaque paquet source non modifiée (et l'introduction d'un delta inutile), mais ne veut pas donner l'impression que le mainteneur du paquet est quelqu'un avec Ubuntu non associé. Même si aucune solution n'a été décidé au moment de l'écriture, une idée implique marquer le mainteneur du paquet explicitement en tant que mainteneur Debian au moment où les paquets binaires sont construits sur Ubuntu construire des machines.

L'accent mis sur des solutions sociales est également essentiel lors de l'utilisation de la technologie distribuée VCS. Comme Linus Torvalds fait allusion dans la citation ci-dessus, l'importance des changements technologiques à la technologie VCS distribuée ne se fait sentir quand les gens commencent à travailler d'une autre manière—quand ils commencent à utiliser différents modèles sociaux d'interaction des développeurs.

Bien que l'expérience Ubuntu peut fournir un bon modèle pour faire face à certaines de ces questions de contrôle des sources, il ne peut servir de modèle et non pas comme une réponse fixe. solutions sociales doivent être adaptées à une relation sociale donnée. Même dans les situations où un paquet est ramifié en raison de désaccords sociaux, un certain niveau de collaboration sur le plan social sera essentiel à la viabilité à long terme du dérivé.

Conclusions

Comme les techniques décrites dans ce document évoluent, le rôle qu'ils jouent dans le développement de logiciels libres devient de plus en plus important et de plus en plus importante. Se joint sera d'autres techniques et les modèles que je ne l'ai pas décrits et ne peut pas prédire. En raison de la taille et de l'utilité de leur code et la taille de leurs communautés de développement, de grands projets comme Debian et Ubuntu ont été contraints à affronter et tenter de servir de médiateur les problèmes inhérents à bifurquer et dériver. Toutefois, étant donné que ces problèmes sont négociés et des outils et des processus sont avancés vers des solutions, des projets de logiciels libres de toutes tailles seront en mesure d'offrir aux utilisateurs exactement ce qu'ils veulent avec une redondance minimale et peu doubles emplois. En faisant cela, le logiciel libre va exploiter une puissance que les modèles propriétaires ne peuvent pas concurrencer.Ils augmenteront leur capacité à produire de meilleurs produits et de meilleurs processus. En fin de compte, il aidera capture du logiciel libre plus d'utilisateurs, apporter plus de développeurs, et de produire plus de logiciels libres d'une qualité supérieure.


[1] L' information est présentée sur la pageaccueil distrowatch ici:http://distrowatch.com/dwres.php?resource=independence

[2] messages Netcraft misesjour annuelles sur la vitesse à laquelledistributions Linux sontplusplus. Se trouve une en question à:http://news.netcraft.com/archives/2004/01/28/debian_fastest_growing_linux_distribution.html

[3] Je et ferslance aiderconstruire une dérivation maintenant essentiellement défunte de Debian appelé-organismes sans but lucratif (Debian-NP) adapté pourorganismes sans but lucratif en travaillantsein du projet Debian.

[4] Informations Ubuntu se trouve sur la page d' accueil Ubuntu. Informations Canonique limitée se trouve à la page d' accueil de Canonical.

[5] Scott James Remnant tientjour une liste de ces patchesligne ici:http://people.ubuntu.com/~scott/patches/

[6] Vous pouvez voir cette déclaration explicite sur le site Web Ubuntu ici:http://www.ubuntulinux.org/ubuntu/relationship/

[7] Le peut lire toutmessage ici:http://www.netsplit.com/blog/work/canonical/ubuntu_and_debian.html

[8] Plusinformations sur Debconf sont disponiblesligne àadresse:http://www.kitenet.net/programs/debconf/

[9] Le message complet peut être luligne sur:http://kerneltrap.org/mailarchive/1/message/48393/thread