From a40f527a6ff5d4cd297ce09a20b6463435511204 Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Feb 17 2025 19:31:19 +0000 Subject: [PATCH 1/6] 📝🆕 docs(project): Initial commit, "Upstream First" (closes #84) This commit adds a new page that offers an explanation and overview of Fedora's place in the Fedora ecosystem. This is inspired by a request that @ankursinha asked to the Council in August 2020, and recent events with the Flatpak/OBS situation. The goal of creating this page is an attempt at making an implicit part of our community ethos into something explicit. If we do not write it down and make sure we are clear about what we believe, how can we expect that the next generation will be able to steward the project in accordance with our values and beliefs in the betterment of Free Software? This explanation may not be perfect, but it is a first start, and it is placed prominently in our official project documentation. Closes Fedora-Council/council-docs#84. ref: https://pagure.io/Fedora-Council/council-docs/issue/84 Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/nav.adoc b/project/modules/ROOT/nav.adoc index 559045f..a09c12c 100644 --- a/project/modules/ROOT/nav.adoc +++ b/project/modules/ROOT/nav.adoc @@ -1,4 +1,5 @@ * xref:index.adoc[Mission and Foundations] +* xref:upstream-first.adoc[Upstream First] * xref:leadership.adoc[Leadership] * xref:orgchart.adoc[High-Level Organization] * xref:brand.adoc[Brand] diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc new file mode 100644 index 0000000..62bc6e4 --- /dev/null +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -0,0 +1,64 @@ += Upstream First: A Core Fedora Principle + +The concept of "upstream first" is a fundamental principle within the Fedora Project. +It shapes our history, culture, and approach to contributing to the open source ecosystem. +Understanding this principle is crucial for anyone looking to contribute to Fedora and the broader Linux distribution ecosystem. + + +[[upstream-downstream]] +== Understanding Upstream and Downstream + +In the world of open source, projects often have interconnected relationships described as "upstream" and "downstream." +The _upstream_ project is the original source of the software—the foundation upon which other projects are built. +_Downstream_ projects, in turn, are those that utilize and often modify the upstream software. +Think of it like a river: the upstream is the source, and downstream projects are further along the flow, receiving and potentially altering the water. + +This metaphor is essential for understanding how open source projects depend on and interact with each other. +Different development models encourage varying types of upstream/downstream relationships. + + +[[upstream-why]] +== Fedora's Commitment to Upstream First + +Fedora, as a Linux distribution, plays a unique role as an _integrator_ of countless software components. +While Fedora develops some of its own software, its primary function is to package and deliver a cohesive operating system experience built upon the work of numerous upstream projects. + +From its inception, Fedora has championed the principle of _upstream first_. +This isn't a policy or hard rule; it's a core value woven into the fabric of the Fedora community. +Fedora contributors believe that changes and improvements to open source software should, whenever possible, be shared back with the upstream projects. +This ensures that *all* users of that software, not just Fedora users, can benefit. + +This commitment to upstream first distinguishes Fedora from some other distributions. +While others might choose to maintain extensive downstream-specific modifications, Fedora prioritizes contributing back to the source. +When Fedora packagers make necessary changes to upstream software, they strive to have those changes integrated upstream, regardless of the software's license. + + +[[upstream-benefits]] +== The Benefits of Upstream First + +Fedora's upstream-first approach has a ripple effect throughout the open source ecosystem. +Changes landed in Fedora often impact numerous downstream projects that use Fedora as a foundation. +Therefore, contributing to Fedora is a highly effective way to influence and improve the broader open source landscape, particularly within the RPM/Enterprise Linux ecosystem. + +By prioritizing upstream contributions, Fedora aligns with its vision of a world where everyone benefits from free and open source software built by inclusive and welcoming communities. +This commitment extends to *all* open source software, not just Fedora itself. + + +[[examples]] +== Examples in Action + +The principle of "upstream first" manifests in various ways. +Here are a couple of examples: + +* *Packaging Improvements*: + A Fedora packager identifies a bug or missing feature in a build toolchain. + Instead of creating a Fedora-specific patch, they submit a patch upstream to the toolchain's maintainers. + After review and discussion, the patch is merged upstream, benefiting all users of the toolchain and eliminating the need for a downstream Fedora patch. +* *Community Script*: + A Fedora contributor develops a script for analyzing package data. + They share the script publicly. + Another contributor enhances the script with new features and submits a pull request. + The original contributor merges the changes, making the improved script available to the entire community. + +These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. +We encourage you to share your own examples of upstream first contributions to this list. From e7c8fa9b5ff3c1f9a561d0c7d68e48c0c8d6ebfc Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Feb 17 2025 19:31:30 +0000 Subject: [PATCH 2/6] 📝♻️ docs(project): Incorporate edits to Upstream First doc This commit incorporates a few additional changes to the original draft, per discussion in the Pagure Pull Request comments: * Added Section on Downstream Patches: Addressed @shaunm's excellent point about explaining the "second" part of "upstream first" by adding a new section "When Downstream Changes Happen." This section explains the legitimate reasons for downstream patches and emphasizes that they are not contradictions of the core principle. * Clarified "Distinguishes Fedora": Removed potentially exclusive phrasing as per @smilner's suggestion. The focus is now on the practice of Upstream First, not comparisons. * Emphasized Pragmatic Benefits: Incorporated @blc's point about the practical engineering advantages of upstream first, specifically the reduction of maintenance burden. This adds another layer of justification for the principle. * Added License Clarifications Example: This example summarizes @mattdm's point about the importance of upstreaming license-related fixes. It highlights how Fedora contributors actively engage with upstream projects to address licensing issues, ensuring compliance and broader inclusion in the open source ecosystem. * Minor Edits: Minor edits for clarity and flow. ref: https://pagure.io/Fedora-Council/council-docs/pull-request/244 Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc index 62bc6e4..6e96a8c 100644 --- a/project/modules/ROOT/pages/upstream-first.adoc +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -28,9 +28,31 @@ This isn't a policy or hard rule; it's a core value woven into the fabric of the Fedora contributors believe that changes and improvements to open source software should, whenever possible, be shared back with the upstream projects. This ensures that *all* users of that software, not just Fedora users, can benefit. -This commitment to upstream first distinguishes Fedora from some other distributions. -While others might choose to maintain extensive downstream-specific modifications, Fedora prioritizes contributing back to the source. -When Fedora packagers make necessary changes to upstream software, they strive to have those changes integrated upstream, regardless of the software's license. +Upstream first is also a pragmatic engineering principle. +By contributing changes upstream, Fedora reduces the long-term maintenance burden of carrying downstream-specific patches. +Maintaining external patch sets can become increasingly difficult as upstream projects evolve. +Embracing upstream first helps ensure the sustainability of Fedora and its contributions. + +[[upstream-exceptions]] +=== When Downstream Changes Happen + +While Fedora prioritizes upstream contributions, there are situations where downstream-specific changes are necessary. +These exceptions are not contradictions of the upstream-first principle, but rather acknowledgements of the complex realities of software development and distribution. + +Reasons for downstream patches include: + +* *Upstream Rejection*: + Sometimes, upstream maintainers may reject a patch for various reasons, even if it is beneficial to Fedora. + Fedora may still need to carry that patch to address a specific issue or requirement. +* *Upstream Progress*: + Upstream projects may move forward with new features or changes that require significant adaptation in Fedora. + Fedora may need to backport fixes or implement temporary workarounds while the downstream adaptation is completed. +* *Distribution-Specific Needs*: + Fedora, and its downstream distributions like EPEL, may have unique requirements or constraints that necessitate downstream modifications. + These needs might relate to specific hardware support, security considerations, or integration with other Fedora components. + +In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. +Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community. [[upstream-benefits]] @@ -59,6 +81,10 @@ Here are a couple of examples: They share the script publicly. Another contributor enhances the script with new features and submits a pull request. The original contributor merges the changes, making the improved script available to the entire community. +* *License Clarifications*: + A Fedora packager discovers licensing issues with an open source project, such as unclear or non-compliant licenses for included assets. + Instead of simply excluding the project from Fedora, they work with the upstream developers to clarify or correct the licenses. + This ensures that the project can be included in Fedora and benefits the broader open source community by promoting license compliance. These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. We encourage you to share your own examples of upstream first contributions to this list. From 73112bf569e71ba25ca32196dc3f2faf41b75f3b Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Feb 17 2025 21:02:22 +0000 Subject: [PATCH 3/6] 📝 docs(project): Add Upstream Comms section for Upstream First This commit addresses feedback from @kevin in Matrix about how we engage and work together with upstream communities. It emphasizes that while we are not always going to agree with upstream's suggestions, we work hard to maintain strong, healthy relationships with our upstreams, and Fedora values the importance of working together in what we do as a community. Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc index 6e96a8c..4ceddc1 100644 --- a/project/modules/ROOT/pages/upstream-first.adoc +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -16,6 +16,16 @@ Think of it like a river: the upstream is the source, and downstream projects ar This metaphor is essential for understanding how open source projects depend on and interact with each other. Different development models encourage varying types of upstream/downstream relationships. +[[upstream-benefits]] +=== The Benefits of Upstream First + +Fedora's upstream-first approach has a ripple effect throughout the open source ecosystem. +Changes landed in Fedora often impact numerous downstream projects that use Fedora as a foundation. +Therefore, contributing to Fedora is a highly effective way to influence and improve the broader open source landscape, particularly within the RPM/Enterprise Linux ecosystem. + +By prioritizing upstream contributions, Fedora aligns with its vision of a world where everyone benefits from free and open source software built by inclusive and welcoming communities. +This commitment extends to *all* open source software, not just Fedora itself. + [[upstream-why]] == Fedora's Commitment to Upstream First @@ -54,16 +64,18 @@ Reasons for downstream patches include: In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community. +[[upstream-communication]] +=== Open Communication with Upstream -[[upstream-benefits]] -== The Benefits of Upstream First +Fedora recognizes the importance of clear and open communication with upstream projects. +We believe in fostering strong relationships with upstream developers and communities, and actively seek their input and feedback. -Fedora's upstream-first approach has a ripple effect throughout the open source ecosystem. -Changes landed in Fedora often impact numerous downstream projects that use Fedora as a foundation. -Therefore, contributing to Fedora is a highly effective way to influence and improve the broader open source landscape, particularly within the RPM/Enterprise Linux ecosystem. +Fedora is always open to hearing from upstream projects about how we can improve our collaboration and integration processes. +We understand that Fedora's downstream usage can sometimes create challenges or friction for upstream projects. +We encourage upstream maintainers to reach out to us if they encounter any issues or have suggestions for improvement. -By prioritizing upstream contributions, Fedora aligns with its vision of a world where everyone benefits from free and open source software built by inclusive and welcoming communities. -This commitment extends to *all* open source software, not just Fedora itself. +Our goal is to work together constructively to find solutions that benefit both Fedora and the upstream projects we rely on. +While we cannot always accommodate every upstream request, we are committed to listening, learning, and adapting our practices to minimize any negative impact on upstream communities. [[examples]] From 013a145f9ef66781f75ff4b8f6b6f5d6a7a2e373 Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Feb 18 2025 16:31:30 +0000 Subject: [PATCH 4/6] 📝 docs(project): Add context for nonfree blobs and bundled dependencies This commit addresses feedback from @mattia about the Upstream First principle and why we do this in Fedora. Changes summarized below: * Added "Non-Free Blobs" to Downstream Reasons: Incorporated the point about patching out non-free or pre-built blobs as a reason for downstream patches in the "When Downstream Changes Happen" section. * Added "Avoiding Bundled Dependencies" Example: Included an example in the "Examples in Action" section illustrating how Fedora avoids bundling dependencies to ensure consistency, security, and compatibility. Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc index 4ceddc1..a602470 100644 --- a/project/modules/ROOT/pages/upstream-first.adoc +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -60,6 +60,10 @@ Reasons for downstream patches include: * *Distribution-Specific Needs*: Fedora, and its downstream distributions like EPEL, may have unique requirements or constraints that necessitate downstream modifications. These needs might relate to specific hardware support, security considerations, or integration with other Fedora components. +* *Non-Free Blobs*: + Fedora is committed to promoting free and open source software and building everything from source. + Sometimes, upstream projects include non-free or pre-built binary blobs that Fedora needs to patch out to adhere to our principles. + While Fedora may discuss potential fixes with upstream, these patches might not always be accepted if there are no suitable alternatives or if they remove functionality. In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community. @@ -97,6 +101,10 @@ Here are a couple of examples: A Fedora packager discovers licensing issues with an open source project, such as unclear or non-compliant licenses for included assets. Instead of simply excluding the project from Fedora, they work with the upstream developers to clarify or correct the licenses. This ensures that the project can be included in Fedora and benefits the broader open source community by promoting license compliance. +* *Avoiding Bundled Dependencies*: + A Fedora packager notices that an upstream project bundles a specific version of a dependency. + Instead of using the bundled dependency, they repackage the project to use the system-wide version of the dependency. + This ensures consistency across Fedora packages, enables rapid security patch deployment, and maintains compatibility between interdependent packages. These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. We encourage you to share your own examples of upstream first contributions to this list. From e992119d2cf24a871077dbd9b5e8e1d010e4a26c Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Feb 22 2025 23:56:05 +0000 Subject: [PATCH 5/6] 📝 docs(project): Voluntary nature, early testing, positive relations This commit addresses a round of feedback by other community members in building this common definition of what "Upstream First" means to the Fedora community: * Addressed @jnsamyak feedback by emphasizing the voluntary nature of the Upstream First philosophy and encouraged contributors to actively adopt it in their work by adding a call to action at the end. * Addressed @dreua feedback by adding an example about early testing and bug reporting in the Python ecosystem to the "Examples in Action" section. * Addressed @joseph feedback by including a sentence in the "Open Communication with Upstream" section to highlight the importance of positive and respectful relationships with upstream projects, extending Fedora's values to those interactions. Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc index a602470..b2bf857 100644 --- a/project/modules/ROOT/pages/upstream-first.adoc +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -81,6 +81,11 @@ We encourage upstream maintainers to reach out to us if they encounter any issue Our goal is to work together constructively to find solutions that benefit both Fedora and the upstream projects we rely on. While we cannot always accommodate every upstream request, we are committed to listening, learning, and adapting our practices to minimize any negative impact on upstream communities. +The philosophy of working upstream first doesn't end with just development. +It also encompasses a productive, positive, and respectful relationship with our upstream projects. +Our communities overlap and we want to extend our Fedora values to their project as much as we would within Fedora. +To that end we always want to deal with challenges between projects together and have clear lines of communication. + [[examples]] == Examples in Action @@ -105,6 +110,12 @@ Here are a couple of examples: A Fedora packager notices that an upstream project bundles a specific version of a dependency. Instead of using the bundled dependency, they repackage the project to use the system-wide version of the dependency. This ensures consistency across Fedora packages, enables rapid security patch deployment, and maintains compatibility between interdependent packages. +* *Early Testing and Bug Reporting*: + Fedora often pioneers the integration of new software versions and libraries. + This early adoption allows Fedora contributors to identify and report build or compatibility bugs upstream, particularly in the Python ecosystem. + These contributions benefit the entire open source community by ensuring smoother transitions and upgrades for everyone. These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. -We encourage you to share your own examples of upstream first contributions to this list. +We encourage you to think about how you can apply the "Upstream First" principle in your Fedora contributions. +Have a story about an upstream contribution? +Share it with the community! From d1719d28cdc6a00fc2503f98b004bc1237a810bd Mon Sep 17 00:00:00 2001 From: Justin W. Wheeler Date: Apr 02 2025 15:15:53 +0000 Subject: [PATCH 6/6] 📝 docs(project): Reorder sections, clarify user focus in Upstream First This commit refactors the "Upstream First: A Core Fedora Principle" document to improve clarity and flow, and incorporates feedback from the community. Changes include: - Move the "Fedora's Commitment to Upstream First" section to the top to emphasize the core principle and its rationale. - Integrate the key points from the "The Benefits of Upstream First" section into the "Fedora's Commitment to Upstream First" section, removing redundancy and streamlining the document. - Add a statement emphasizing Fedora's commitment to prioritizing user benefit, even if it means diverging from upstream decisions. - Minor edits for improved readability and consistency. Signed-off-by: Justin W. Wheeler --- diff --git a/project/modules/ROOT/pages/upstream-first.adoc b/project/modules/ROOT/pages/upstream-first.adoc index b2bf857..e2ddfac 100644 --- a/project/modules/ROOT/pages/upstream-first.adoc +++ b/project/modules/ROOT/pages/upstream-first.adoc @@ -5,28 +5,6 @@ It shapes our history, culture, and approach to contributing to the open source Understanding this principle is crucial for anyone looking to contribute to Fedora and the broader Linux distribution ecosystem. -[[upstream-downstream]] -== Understanding Upstream and Downstream - -In the world of open source, projects often have interconnected relationships described as "upstream" and "downstream." -The _upstream_ project is the original source of the software—the foundation upon which other projects are built. -_Downstream_ projects, in turn, are those that utilize and often modify the upstream software. -Think of it like a river: the upstream is the source, and downstream projects are further along the flow, receiving and potentially altering the water. - -This metaphor is essential for understanding how open source projects depend on and interact with each other. -Different development models encourage varying types of upstream/downstream relationships. - -[[upstream-benefits]] -=== The Benefits of Upstream First - -Fedora's upstream-first approach has a ripple effect throughout the open source ecosystem. -Changes landed in Fedora often impact numerous downstream projects that use Fedora as a foundation. -Therefore, contributing to Fedora is a highly effective way to influence and improve the broader open source landscape, particularly within the RPM/Enterprise Linux ecosystem. - -By prioritizing upstream contributions, Fedora aligns with its vision of a world where everyone benefits from free and open source software built by inclusive and welcoming communities. -This commitment extends to *all* open source software, not just Fedora itself. - - [[upstream-why]] == Fedora's Commitment to Upstream First @@ -37,36 +15,31 @@ From its inception, Fedora has championed the principle of _upstream first_. This isn't a policy or hard rule; it's a core value woven into the fabric of the Fedora community. Fedora contributors believe that changes and improvements to open source software should, whenever possible, be shared back with the upstream projects. This ensures that *all* users of that software, not just Fedora users, can benefit. +Ultimately, Fedora's final objective is the benefit of the user, and Fedora contributors will do what they think is best for the user, even if upstream disagrees. Upstream first is also a pragmatic engineering principle. By contributing changes upstream, Fedora reduces the long-term maintenance burden of carrying downstream-specific patches. Maintaining external patch sets can become increasingly difficult as upstream projects evolve. Embracing upstream first helps ensure the sustainability of Fedora and its contributions. -[[upstream-exceptions]] -=== When Downstream Changes Happen +This approach has a ripple effect throughout the open source ecosystem. +Changes landed in Fedora often impact numerous downstream projects that use Fedora as a foundation. +Therefore, contributing to Fedora is a highly effective way to influence and improve the broader open source landscape, particularly within the RPM/Enterprise Linux ecosystem. -While Fedora prioritizes upstream contributions, there are situations where downstream-specific changes are necessary. -These exceptions are not contradictions of the upstream-first principle, but rather acknowledgements of the complex realities of software development and distribution. +By prioritizing upstream contributions, Fedora aligns with its vision of a world where everyone benefits from free and open source software built by inclusive and welcoming communities. +This commitment extends to *all* open source software, not just Fedora itself. -Reasons for downstream patches include: -* *Upstream Rejection*: - Sometimes, upstream maintainers may reject a patch for various reasons, even if it is beneficial to Fedora. - Fedora may still need to carry that patch to address a specific issue or requirement. -* *Upstream Progress*: - Upstream projects may move forward with new features or changes that require significant adaptation in Fedora. - Fedora may need to backport fixes or implement temporary workarounds while the downstream adaptation is completed. -* *Distribution-Specific Needs*: - Fedora, and its downstream distributions like EPEL, may have unique requirements or constraints that necessitate downstream modifications. - These needs might relate to specific hardware support, security considerations, or integration with other Fedora components. -* *Non-Free Blobs*: - Fedora is committed to promoting free and open source software and building everything from source. - Sometimes, upstream projects include non-free or pre-built binary blobs that Fedora needs to patch out to adhere to our principles. - While Fedora may discuss potential fixes with upstream, these patches might not always be accepted if there are no suitable alternatives or if they remove functionality. +[[upstream-downstream]] +== Understanding Upstream and Downstream -In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. -Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community. +In the world of open source, projects often have interconnected relationships described as "upstream" and "downstream." +The _upstream_ project is the original source of the software—the foundation upon which other projects are built. +_Downstream_ projects, in turn, are those that utilize and often modify the upstream software. +Think of it like a river: the upstream is the source, and downstream projects are further along the flow, receiving and potentially altering the water. + +This metaphor is essential for understanding how open source projects depend on and interact with each other. +Different development models encourage varying types of upstream/downstream relationships. [[upstream-communication]] === Open Communication with Upstream @@ -86,6 +59,31 @@ It also encompasses a productive, positive, and respectful relationship with our Our communities overlap and we want to extend our Fedora values to their project as much as we would within Fedora. To that end we always want to deal with challenges between projects together and have clear lines of communication. +[[upstream-exceptions]] +=== When Downstream Changes Happen + +While Fedora prioritizes upstream contributions, there are situations where downstream-specific changes are necessary. +These exceptions are not contradictions of the upstream-first principle, but rather acknowledgements of the complex realities of software development and distribution. + +Reasons for downstream patches include: + +* *Upstream Rejection*: + Sometimes, upstream maintainers may reject a patch for various reasons, even if it's beneficial to Fedora. + Fedora may still need to carry that patch to address a specific issue or requirement. +* *Upstream Progress*: + Upstream projects may move forward with new features or changes that require significant adaptation in Fedora. + Fedora may need to backport fixes or implement temporary workarounds while the downstream adaptation is completed. +* *Distribution-Specific Needs*: + Fedora, and its downstream distributions like EPEL, may have unique requirements or constraints that necessitate downstream modifications. + These needs might relate to specific hardware support, security considerations, or integration with other Fedora components. +* *Non-Free Blobs*: + Fedora is committed to promoting free and open source software and building everything from source. + Sometimes, upstream projects include non-free or pre-built binary blobs that Fedora needs to patch out to adhere to its principles. + While Fedora may discuss potential fixes with upstream, these patches might not always be accepted if there are no suitable alternatives or if they remove functionality. + +In these situations, Fedora strives to minimize the scope and duration of downstream patches, and continues to work towards upstreaming changes whenever feasible. +Understanding the reasons for downstream changes is essential for maintaining transparency and trust within the community. + [[examples]] == Examples in Action @@ -94,26 +92,26 @@ The principle of "upstream first" manifests in various ways. Here are a couple of examples: * *Packaging Improvements*: - A Fedora packager identifies a bug or missing feature in a build toolchain. - Instead of creating a Fedora-specific patch, they submit a patch upstream to the toolchain's maintainers. - After review and discussion, the patch is merged upstream, benefiting all users of the toolchain and eliminating the need for a downstream Fedora patch. + A Fedora packager identifies a bug or missing feature in a build toolchain. + Instead of creating a Fedora-specific patch, they submit a patch upstream to the toolchain's maintainers. + After review and discussion, the patch is merged upstream, benefiting all users of the toolchain and eliminating the need for a downstream Fedora patch. * *Community Script*: - A Fedora contributor develops a script for analyzing package data. - They share the script publicly. - Another contributor enhances the script with new features and submits a pull request. - The original contributor merges the changes, making the improved script available to the entire community. + A Fedora contributor develops a script for analyzing package data. + They share the script publicly. + Another contributor enhances the script with new features and submits a pull request. + The original contributor merges the changes, making the improved script available to the entire community. * *License Clarifications*: - A Fedora packager discovers licensing issues with an open source project, such as unclear or non-compliant licenses for included assets. - Instead of simply excluding the project from Fedora, they work with the upstream developers to clarify or correct the licenses. - This ensures that the project can be included in Fedora and benefits the broader open source community by promoting license compliance. + A Fedora packager discovers licensing issues with an open source project, such as unclear or non-compliant licenses for included assets. + Instead of simply excluding the project from Fedora, they work with the upstream developers to clarify or correct the licenses. + This ensures that the project can be included in Fedora and benefits the broader open source community by promoting license compliance. * *Avoiding Bundled Dependencies*: - A Fedora packager notices that an upstream project bundles a specific version of a dependency. - Instead of using the bundled dependency, they repackage the project to use the system-wide version of the dependency. - This ensures consistency across Fedora packages, enables rapid security patch deployment, and maintains compatibility between interdependent packages. + A Fedora packager notices that an upstream project bundles a specific version of a dependency. + Instead of using the bundled dependency, they repackage the project to use the system-wide version of the dependency. + This ensures consistency across Fedora packages, enables rapid security patch deployment, and maintains compatibility between interdependent packages. * *Early Testing and Bug Reporting*: - Fedora often pioneers the integration of new software versions and libraries. - This early adoption allows Fedora contributors to identify and report build or compatibility bugs upstream, particularly in the Python ecosystem. - These contributions benefit the entire open source community by ensuring smoother transitions and upgrades for everyone. + Fedora often pioneers the integration of new software versions and libraries. + This early adoption allows Fedora contributors to identify and report build or compatibility bugs upstream, particularly in the Python ecosystem. + These contributions benefit the entire open source community by ensuring smoother transitions and upgrades for everyone. These examples illustrate how upstream first fosters collaboration, shared ownership, and continuous improvement within the open source ecosystem. We encourage you to think about how you can apply the "Upstream First" principle in your Fedora contributions.