L’upstream d’abord : un principe au cœur de Fedora

Le concept de « upstream-first » est un principe fondamental au sein du Fedora Project. Il est déterminant de notre histoire, notre culture et de notre approche de la contribution à l’écosystème open source. Il est crucial de comprendre ce principe si l’on souhaite contribuer à Fedora et à l’écosystème gravitant autour de la distribution Linux.

L’engagement de Fedora en faveur de l’upstream-first

Fedora, en tant que distribution Linux, joue un rôle unique en tant qu’intégratrice d’innombrables composants logiciels. Bien que Fedora développe une partie de son logiciel, sa fonction principale est de packager et de fournir une expérience de système d’exploitation cohérente grâce au travail des projets upstream.

Dès sa naissance, Fedora a décidé de défendre le principe d’upstream-first. Il ne s’agit pas d’une politique ou d’une règle stricte ; c’est une valeur fondamentale qui fait partie intégrante du tissu communautaire. Les contributeur·rices Fedora considèrent que les modifications et améliorations apportées aux logiciels open-source doivent être rendues aux projets upstream à chaque fois que cela est possible. En procédant de la sorte, tout le monde en bénéficie, et pas uniquement les utilisateur·rices de Fedora. Enfin, l’objectif de Fedora est d’améliorer la vie de l’utilisateur·rice : c’est pourquoi les contributeur·rices font ce qu’iels considèrent être au bénéfice de l’utilisateur·rice, même si l’upstream n’est pas du même avis.

L’upstream d’abord est aussi un principe d’ingénierie pragmatique. En participant upstream, Fedora réduit à long terme la charge induite par la maintenance des patchs downstream. Maintenir des ensembles de patchs peut devenir très complexe à mesure de l’évolution des projets upstream. Adopter l’upstream-first aide donc à assurer la résilience de Fedora et de ses contributions.

Cette approche a un fort impact sur l’écosystème open source. Les modifications de Fedora impactent souvent de nombreux projets downstream utilisant Fedora comme base. C’est pourquoi contribuer à Fedora est un moyen très efficace d’influencer et d’améliorer le paysage de l’open source et particulièrement l’écosystème RPM/Enterprise Linux.

En priorisant les contributions upstream, Fedora est cohérent avec sa vision d’un monde où tout le monde bénéficie de logiciels libres et open-source bâtis par des communautés inclusives et accueillantes. Cet engagement s’étend à tous les projets de logiciels open-source, pas uniquement Fedora.

Comprendre l’upstream et le downstream

Dans le monde de l’open source, les projets ont souvent des relations d’interconnexion appelées « upstream » (en amont) et « downstream » (en aval). Le projet upstream est la source d’où provient le logiciel, les fondations sur lesquelles sont bâties d’autres projets. Les projets downstream, quant à eux, sont ceux qui utilisent et souvent modifient le logiciel upstream. Imaginez une rivière : l’upstream est la source de la rivière, et les projets downstream sont en aval et bénéficient de l’eau et/ou la transforment.

Cette métaphore est essentielle pour comprendre l’interaction entre les projets open-source. Des modèles de développement différents sont susceptibles d’encourager des types de relation upstream/downstream différents.

Une communication ouverte avec l’upstream

Fedora reconnaît l’importance d’une communication claire et ouverte avec les projets upstream. Nous croyons en l’établissement de relations fortes avec les développeur·ses et communautés upstream et recherchons activement leurs retours et commentaires.

Fedora est toujours ouvert aux avis des projets upstream portant sur comment nous pouvons améliorer nos processus de collaboration et d’intégration. Nous comprenons que l’utilisation downstream de Fedora peut parfois être éprouvante pour les projets upstream ou susceptible de créer des désaccords. Nous encourageons les mainteneur·ses upstream à venir à notre rencontre s’iels rencontrent des problèmes ou ont des suggestions d’améliorations.

Notre but est de travailler ensemble de manière constructive à l’élaboration de solutions qui bénéficient à fois à Fedora et aux projets upstream dont nous dépendons. Bien que nous ne puissions pas satisfaire toutes les demandes de l’upstream, nous nous engageons à écouter, apprendre et adapter nos pratiques pour minimiser tout impact négatif sur les communautés upstream.

La philosophie de travailler en privilégiant l’upstream ne se limite pas au développement. Elle concerne également les relations avec nos projets upstream : elles se doivent d’être productives, positives et respectueuses. Nos communautés se chevauchent et nous voulons étendre les valeurs de Fedora à leurs projets. Dans ce but, nous souhaitons travailler constamment ensemble sur nos défis communs et avoir des lignes de communication claires.

Les modifications downstream nécessaires

Bien que Fedora donne la priorité aux contributions upstream, il y a des situations où des modifications spécifiques au downstream sont nécessaires. Ces exceptions n’entrent pas en contradiction avec le principe d’upstream-first, mais témoignent au contraire des réalités complexes du développement et de la distribution de logiciels.

Les raisons justifiant la création de patchs downstream incluent :

Rejet upstream : Parfois, il arrive que les mainteneur·ses upstream rejettent un patch pour des raisons diverses, même si celui-ci est bénéfique pour Fedora. Fedora peut être amené à appliquer quand même ce patch pour corriger un problème ou répondre à un besoin.
Avancée upstream : Il se peut que les projets upstream avancent significativement en ajoutant de nouvelles fonctionnalités ou en effectuant des changements qui nécessitent des adaptations significatives. Fedora peut être amené à effectuer un backport des corrections ou à implémenter des solutions de contournement temporaires en attendant que l’adaptation downstream soit terminée.
Besoins spécifiques de la distribution : Fedora, et ses distributions downstream comme EPEL, peuvent avoir des exigences ou des contraintes uniques qui peuvent nécessiter des modifications downstream. Ces besoins peuvent porter sur la prise en charge de matériels spécifiques, la sécurité ou l’intégration avec d’autres composants Fedora.
Blobs non libres : Fedora s’engage à promouvoir les logiciels libres et open-source et à toujours construire à partir de la source. Parfois, les projets upstream incluent des blobs binaires non libres ou précompilés que Fedora doit exclure afin de tenir ses engagements. Bien que Fedora puisse discuter des corrections potentielles avec l’upstream, ces patchs sont susceptibles d’être refusés s’il n’existe aucune alternative viable ou s’ils suppriment des fonctionnalités.

Dans ces situations, Fedora s’efforce de minimiser la portée et la durée d’existence de ses patchs downstream, et continue d’œuvrer en faveur de la modification upstream dès que possible. Comprendre les raisons poussant à effectuer des changements downstream est essentiel au maintien de la transparence et de la confiance au sein de la communauté.

Exemples concrets

Le principe de « upstream-first » se concrétise de plusieurs manières. Voici quelques exemples :

Amélioration de la création de paquets : Un·e packager identifie un bug ou une fonctionnalité manquante dans une suite d’outils de build. Plutôt que de créer un patch spécifique à Fedora, le/la packager soumet un patch aux mainteneur·ses upstream de la suite d’outils. Après examen et discussion, le patch est appliqué upstream au bénéfice de tous·tes les utilisateur·rices de la suite d’outils, éliminant la nécessité d’un patch downstream Fedora.
Script communautaire : Un·e contributeur·rice développe un script dédié à l’analyse des données contenues dans un paquet. Iel partage le script publiquement. Un·e autre contributeur·rice améliore le script en ajoutant de nouvelles fonctionnalités et crée une pull request. Lae contributeur·rice original·e accepte les modifications, rendant la version améliorée du script disponible pour l’ensemble de la communauté.
Clarification de la licence : Un·e packager Fedora découvre un problème dans les licences d’un projet open-source, par exemple une licence peu claire ou non conforme pour certaines ressources. Plutôt que de simplement exclure le projet de Fedora, iel travaille avec les développeur·ses upstream afin de clarifier ou de corriger les licences. Cela permet de garantir que le projet peut bel et bien être inclus dans Fedora et bénéficie plus largement à la communauté open source en encourageant le respect des licences.
Retirer les dépendances intégrées : Un·e packager Fedora remarque qu’un projet upstream fournit une version particulière d’une dépendance. Au lieu d’utiliser la dépendance intégrée au projet, iel repackage le projet de manière à utiliser la version de la dépendance fournie par le système. Cela permet d’assurer une cohérence entre les paquets Fedora, de permettre le déploiement rapide de patchs de sécurité et de maintenir la compatibilité entre les paquets interdépendants.
Anticiper et signaler des bugs : Fedora fait partie des premiers à intégrer les nouvelles versions de logiciels et de bibliothèques. En adoptant rapidement ces versions, les contributeur·rices Fedora peuvent identifier et signaler les bugs de compilation ou de compatibilité à l’upstream (particulièrement important pour Python). Ces contributions bénéficient à l’ensemble de la communauté open source en garantissant la facilité de transition et de mise à jour.

Ces exemples illustrent en quoi l’upstream-first encourage la collaboration, la propriété partagée et l’amélioration continue au sein de l’écosystème open source. Nous vous encourageons à réfléchir à la manière dont vous pouvez appliquer le principe d’upstream-first dans vos contributions Fedora. Vous avez quelque chose à raconter à propos d’une contribution upstream ? Faites-en part à la communauté !

Want to help? Learn how to contribute to Fedora Docs ›