Env and Stacks/Projects/PackageReviewProcessRedesign

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

(DRAFT) Incremental Review Process for Fedora Packages (DRAFT)

Fedora Packaging Reviews are currently largely "all or nothing" - a component doesn't really get reviewed until it's been repackaged as an RPM and submitted to a full review for packaging policy compliance. This is a draft proposal for breaking Fedora's packaging policy up into 6 different tiers based on the centrality of a component to the Fedora platform.

The term "Aleph" is proposed for each tier based on the Fedora logo, and the fact that each tier is expected to contain correspondingly larger numbers of different packages.

The 6 proposed levels:

• Aleph 0: Essential components
• Aleph 1: Integrated components
• Aleph 2: Policy compliant components
• Aleph 3: Repackaged components
• Aleph 4: Redistributed components
• Aleph 5: Upstream components

Aleph 0 would be the domain of the Base WG and Edition WG's, Aleph 1 would include everything else specifically taken into account for release management purposes (and perhaps a bit more), while Aleph 2 would primarily be the domain of individual package maintainers.

Aleph's 3-5 would be the domain of Environments & Stacks.

Components would need to pass a packaging review to be included in Alephs 0-2.

Components would need to pass a redistribution review to be included in Alephs 0-4.

Tiers using RPM as the publication format may contain distro specific patches, tiers using other formats (i.e. Aleph 4 & 5) would always provide vanilla upstream packages.

Tier	Build System	Redistribution Review?	RPM Required?	Packaging Review?	Maintenance Plan?
Aleph 0	koji	Yes	Yes	Yes	Yes
Aleph 1	koji	Yes	Yes	Yes	Yes
Aleph 2	koji	Yes	Yes	Yes	No
Aleph 3	COPR	Yes	Yes	No	No
Aleph 4	COPR?	Yes	No	No	No
Aleph 5	Upstream	No	No	No	No

Aleph 0: Essential components

• Publication format: RPM
• Build system: koji
• Consumption formats: RPM, ISO, AMI, OSTree, base Docker images

All the RPMs that go into Fedora Cloud, Fedora Atomic Host, and the base installs for Fedora Server and Fedora Workstation are Aleph 0 components. Any component proposed for inclusion at this tier *must* be available as a policy compliant RPM.

Some essential components could eventually be made available as xdg-app sandboxes or layered Docker images. Whether they're classed as "essential" or not would still be determined by whether or not they were a default component in one of the Fedora Editions.

If essential components aren't closely tracking their upstream counterparts, we should want to know why. We'd expect essential components to be smoothly handed over to new maintainers rather than getting orphaned without a migration plan.

Aleph 1: Integrated components

• Publication format: RPM
• Build system: koji
• Consumption formats: RPM, ISO (, layered Docker image?, xdg-app?)

All the RPMs that go into Labs and Spins would be Aleph 1 components. There might be other components that would fit here as well if the Fedora starts providing them in a pre-integrated form, like a layered Docker image, or an xdg-app. The upstream packages that feed into softwarecollections.org should likely also be Aleph 1

If integrated components aren't closely tracking their upstream counterparts, we should want to know why. We'd expect integrated components to be smoothly handed over to new maintainers rather than getting orphaned without a migration plan.

The key difference relative to Aleph 0 is whether or not a component is a standard part of one of the main Fedora Editions. From a general maintenance policy perspective there shouldn't be much of a difference, but FESCo may take the distinction into account when assessing release blockers.

Aleph 2: Policy compliant components

• Publication format: RPM
• Build system: koji
• Consumption formats: RPM(, layered Docker image?, xdg-app?)

Everything else in the main Fedora repos, as well as everything in EPEL.

Acceptance into Aleph 2 represents packages that have passed a full review against the relevant packaging policy.

The key difference relative to Aleph 0 and 1 is that Aleph 2 components may not closely track their upstream counterparts, and they may be orphaned and retired without a specific migration plan in place.

Aleph 3: Repackaged components

• Publication format: RPM
• Build system: COPR
• Consumption formats: RPM

Fedora Playground, COPR repos in general.

The key difference relative to Aleph 2 is that while these components have passed a redistribution review and have been repackaged as RPMs, they haven't passed a full review against the relevant packaging policy. This means they may still contain bundled subprojects, fail to adhere to the Filesystem Hierarchy Standard, fail to uninstall cleanly, etc.

Aleph 4: Redistributed components

• Publication format: ecosystem dependent (Pulp plugin required)
• Build system: COPR????
• Consumption formats: ecosystem dependent

This level would be for components published in a distro independent format that have passed a redistribution review that establishes:

• that the component complies with Fedora's licensing policies
• that the component appears to have been published in good faith
• that the component appears to be benign

All signatories to the Fedora Contributor Agreement would be permitted to "self review" on this basis, with exceptions detected after the fact and the offending components removed (this is the way COPR repos already work)

The intended use of these components would be for local development and testing, as well as incorporation into layered Docker images and xdg-app sandbox builds.

To qualify for this tier, a packaging ecosystem must have:

• a Pulp repo hosting plugin in Aleph 0-2
• a package installation client in Aleph 0-2
• a package build utility in Aleph 0-2
• upstream support for the notion of third party redistribution of components

Components approved for redistribution can then be automatically rebuilt and published into a Pulp managed repo.

Languages that don't natively support redistribution could potentially still be supported at this tier through a cross-platform user level package management tool like nix or conda.

Aside from the packaging format, the key difference relative to Aleph 3 is that these components will be completely unmodified from their upstream versions - the only difference relative to upstream is that that any prebuilt binaries will have been compiled against a specific Fedora or EPEL ABI.

Aleph 5: Upstream components

• Publication format: ecosystem dependent
• Build system: ecosystem dependent
• Consumption formats: ecosystem dependent

This tier would represent software distribution ecosystems where a package installation client was present in Aleph 0-3, but the full criteria for inclusion in collaborative package review for Aleph 4 are not met.