# The problem you're addressing
Low review bandwidth for contributions to Qub…es OS.
# The solution you'd like
Proposal: Base Distribution Developers = Derivative Developers
# The value to a user, and who that user might be
Higher review bandwidth for contributions to Qubes OS, faster review, merge process.
# Proposal: Base Distribution Developers = Derivative Developers
This proposal outlines a strategy for increasing review bandwidth and development efficiency within Linux derivative projects by granting base distribution developers commit access for derivative distributions.
This proposal suggests a collaborative framework whereby developers from base Linux distributions, such as Debian or Fedora, are granted commit access within derivative Linux projects like Qubes. The aim is to leverage the established trust and vetting processes of larger distributions to expedite development, enhance security, and improve the implementation of bug fixes and feature requests in derivative distributions.
_Version: 3.0_
## Definitions
- **reviewer:** A "reviewer" in this context is someone with the right to review and merge (commit) source code contributions (such as pull requests on GitHub) without necessarily requiring approval from the derivative distribution core team.
- **Similar names in different contexts:** In the case of Debian, these are called Debian Developer (DD) or maintainer, a different but similar concept. A DD can upload packages to Debian which they maintain, and any other package (NMU - non-maintainer upload), subject to Debian policy.
- **base distribution:** Examples include Debian, Fedora.
- **derivative distribution:** Examples include Kicksecure, Whonix, Qubes.
## Issue
- **Low Review Bandwidth:** The review bandwidth of many derivative Linux distributions (such as Kicksecure, Whonix, Qubes) is low. This means there are sometimes complex or large source code or documentation contributions than the existing derivative core team can thoroughly merge, maintain and review without jeopardizing the security and/or quality of the operating system. This slows down development, growth, implementation of bug fixes and feature requests.
- **Trust Decisions Difficulty:** Establishing trust with people far from the internet is challenging. Physical meetups such as conferences are not a magical solution either. Deciding who gets commit access is difficult. This is probably why the named Linux derivatives have only a small team of people with commit access, and new committers are rarely added.
## Current State versus Potential Future State
**Base Distributions:**
- How to acquire commit access for the base distribution?
- Answer: By becoming a base distribution developer.
- Example: Is it possible to get commit access in Debian? Yes.
- How to get Debian commit access? By becoming a Debian Developer (DD). How to become a DD? By going through the [Debian New Member Process](https://nm.debian.org/).
**Derivative Distributions - Current State:**
- **Possibility:** Is it possible to acquire commit access for the derivative distribution? No. Realistically, unlikely.
- **How:** There is no defined process/path that one could point to that more or less "guarantees" acquiring heritable commit access, whether technologically or via a shared set of widely agreed upon protocols and principles.
**Derivative Distributions - Potential Future State:**
- **Possibility:** Is it possible to acquire commit access for the derivative distribution? Yes.
- **How:** By becoming a base distribution developer one has a viable path to acquire commit access for the derivative distribution.
- Example for Kicksecure: Debian developers would have an easy path to request Kicksecure commit access.
- Examples for Qubes:
- Debian developers would have an easy path to request commit access for Qubes Debian Templates.
- Fedora developers would have an easy path to request commit access for Qubes Fedora Templates.
- dom0? Intentionally left out in this proposal to see first if this proposal receives positive feedback. Could be considered later or stay as is.
## Solution
- **Base distribution developer proposal:** Any properly authenticated base distribution developer should be able to nominate themself for review and/or commit access rights for the derivative distribution. In other words, there should be a process to allow base distribution merge access to be inherited by the derivative distribution.
- **Prior contributions requirement:** This may be limited to individuals who have made prior contributions to the derivative.
- **Shortcut solution rationale:** This is an imperfect shortcut solution for the low bandwidth review queue by derivatives such as Qubes. What would be the "perfect" solution? See footnote [1].
## Advantages
- **More speedy review of contributions:** The review of pending contributions (pull requests) could be sped up because potentially there might be more reviewers.
- **Simplified vetting process:** The reviewer vetting process would be outsourced to larger Linux distribution(s) that have existing infrastructure to handle that. Want commit access? Simply make a number of useful source code contributions (to be defined), have credentials from eligible Linux base distributions and complete a brief application requesting access.
- **Closer Cooperation with Upstream:** By encouraging more people to become base distribution developers, cooperation with upstream would improve. One can only become a base distribution developer by making useful and accepted contributions to the base distribution.
## Eligible Linux Base Distributions
- **Debian:** Debian is a natural choice because Debian Developers must be trusted as they have the capability to backdoor Debian and therefore any distribution based on it (Kicksecure, Whonix, Qubes Debian Template) anyway.
- **Extension to other distributions:** Could potentially be extended to include Fedora and other Linux base distributions pending the definition of eligibility criteria.
- **Discussion on expansion:** This should be discussed separately in case this proposal receives positive feedback. No need to engage in distribution polemics if this concept is completely rejected.
## Why Commit Access
- **Commit access versus review rights:** Why commit access, review, and rights and not only review rights? Because then the responsibility would still be on the shoulders of the person with commit access. The merge at the end is what gets recorded in the source control system (git). With only review rights, not much would change. Even now, anyone can make a comment that can serve as a community review.
- **Importance of commit access:** Without commit access, the usefulness of this proposal would be severely limited.
## What this is not
- **Hard condition:** Is this an exclusive, hard condition? **No.** This does not create a hard condition. It's an additional way. It does not curtail the rights of the existing decision-makers to grant review privileges to other people of their choice.
- **Exclusion of existing members:** Should existing people with commit access be removed if they are not base distribution developers? **No**. This proposal does not suggest curtailing the rights of any existing members.
## Questions and Answers
- **rights grant for non-base distribution developers:** Will it still be possible for the current decision makers to "sidestep" this proposal and grant commit access to any person, including those who are not base distribution developers? **Yes.**
- **refusal of rights to base distribution developers:** Can the project current decision makers still refuse to grant commit access to any arbitrary number of base distribution developers? **Yes.**
- **revocation of commit access:** Can the project current decision makers still revoke commit access at any time? **Yes.**
- **public pull requests:** Can any member of the public still send pull requests as is possible prior to this proposal? **Yes.**
- **absolute rule:** Is this an absolute rule? **No.** This is a living document that aims to grow the pool of trusted developers and removing development friction in order to maximize the effect of their contributions to the FLOSS ecosystem. It can be further extended or amended as needed based on feedback.
- **vetting for new reviewers:** Could there be a (short, cursory, or long) vetting before adding new reviewers? **Optional.**
- **base distribution developers' contributions:** Did any base distribution developers ever contribute to derivative distributions? **Yes.**
- **examples of contributions:** Examples of base distribution developers contributing to derivative distributions? Intentionally left out to avoid putting unnecessary spotlight on these contributors. Since everything is public and Open Source, it's on the public record.
- **realism of contributions:** How realistic is it that base distribution developers would contribute to derivative distributions? **Unknown**, but see above question. Worth trying. Effort is comparatively low. Maybe some will comment here.
- **point of proposal if there is disinterest from current base distribution developers:** What's the point if no base distribution developers are interested to apply for derivative distribution merge access anyhow? Then at least derivative contributors can be pointed to a viable path on how they can get commit access to the derivative distribution - by first becoming a base distribution developer.
- **distribution developer rationale:** What is so special about becoming a base distribution developer? It is hard, time-consuming, requires a learning process, going through the proverbial school of the base distribution, social skills and includes a vetting process.
- **upload rights:** Build/upload rights for releases and/or binary packages are a separate right and are not covered by merely having source commit access.
## Qubes Specific
- **prerequisite knowledge:** [Qubes Core Reviewer (QCR)](https://www.qubes-os.org/doc/package-contributions/)
- **commit access to Qubes core packages:** Does this mean, a base distribution developer would necessarily get commit access to Qubes core packages such as qubes-core-agent-linux? **No**, not necessarily. The concept of maintainers could be kept. A package maintainer of a package or QCR could remain the only reviewer deciding what is permissible to be merged.
- **NMU policy:** There is no policy suggestion for NMU (non-maintainer upload) in Qubes yet. Such as when no uploader (QCR?) is (planned or unexpectedly) unavailable. For example, a selection and/or quorum of a minimum number of base distribution developers might be allowed to perform NMU. Such things could be considered at a later point in case this proposal receives positive feedback.
- **QubesOS-contrib eligibility:** A base distribution developer could be eligible to add packages to QubesOS-contrib, perhaps without even needing a second reviewer, but this would be optional. Another option would be that two base distribution developers would be eligible to add packages without requiring a review by QCR.
## Footnotes
- [1] The "perfect" solution would be for the derivative to develop and maintain a member mechanism similar to [Debian New Member Process](https://nm.debian.org/). This would also require forking related policies such as [Debian Constitution](https://www.debian.org/devel/constitution), [Debian Free Software Guidelines (DFSG)](https://wiki.debian.org/DebianFreeSoftwareGuidelines), [Debian Policy](https://www.debian.org/doc/debian-policy/), among an unknown number of other important policies and processes. However, this would be very hard, time-consuming, require reducing development activities, and a strong focus on the development of an organisational structure. This is presumably why that has not been done yet and is unlikely to happen soon.
## Improvements to this Proposal
- Suggestions welcome.
- This is just a proposal. Instead of dismissing it, how can it be improved to be made suitable?
- The core team is obviously free to make any changes of their liking.
## Disclaimer
- **no conflict of interest:** I am not a base distribution developer myself, neither did I start the process to become one at this point. I would therefore not personally benefit from this policy suggestion.
- **proposal origin:** Did any base distribution developer suggest this? **No**, Patrick invented this idea without prior counseling with any base distribution developers.
- Speaking for myself only.
## See Also
- [https://producingoss.com/en/committers.html](https://producingoss.com/en/committers.html)
- [https://developer.blender.org/docs/handbook/contributing/commit_rights/](https://developer.blender.org/docs/handbook/contributing/commit_rights/)
- [https://medium.com/@elombrozo/the-bitcoin-core-merge-process-74687a09d81d](https://medium.com/@elombrozo/the-bitcoin-core-merge-process-74687a09d81d)