From Fedora Project Wiki

< User:Toshio

Revision as of 18:36, 15 May 2009 by Toshio (talk | contribs) (Add admon that pre-review is not yet a general-purpose guide)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

This was a one-off to help the Java Team through a tough transition. If you want to do other prereview type packaging, it needs to be discussed ahead of time on fedora-devel-list. Any use of prereviews will need to be approved by rel-eng and fesco before being implemented.

What is Pre-review?

FESCo approved a releng request that there be a way for getting some packages into cvs before review in order to work on building the packages in a temporary tag and get them building against each other before they get reviewed and built into a dist tag. The proposal included having the packages pre-reviewed for legal issues and not-from-source included.

This specific instance was for approximately 10 new java packages needed for a maven upgrade but if this is successful it could be used for other new packages that need to be added as a set as well.

How might it be implemented?

  1. Package gets a review bug in bugzilla
  2. Someone reviews the package for a minimal set of Guideline compliance aimed at finding anything wrong that we wouldn't want to enter the buildsystem.
  3. Packages are checked into cvs in such a way that they can only be built for their special tag.
  4. Packages are built to a special tag, tweaked, until ready for review.
  5. Other packages are built into the tag with fixes for the new maven
  6. All packages finish going through normal review
  7. Packages in the side tag are moved to the dist-f12 tag.

Note that because of bootstrapping issues, the packages will be moved from the side tag to the dist-f12 tag rather than being rebuilt fresh into that tag.

What needs to be done?

We need to define the Guidelines that need to be checked for the pre-review step. We want to make sure that Fedora is not doing anything illegal and not putting the buildsystem/integrity of packages in danger.

Questions on what we're aiming for

Proposed Guidelines to Check


We want to do a check for legal issues so we aren't distributing code that we don't have a right to. So everything in these Guidelines should be checked:

Preventing Malicious Source

We don't want to be building pieces of build toolchain with other pieces of toolchain that could have malicious code embedded in them. We can't be perfect about this but some checks can be done:

Making sure the SourceURL is canonical (via google, checking other distributions, etc) helps to verify that we're grabbing our source tarballs from the correct location. We also need to verify the tarball included matches what's in the source URL:

From Source

We want to make sure that the packages are being built from source. Building with packages that are not from source makes it extremely hard to verify what is actually inside the compiled code. So there's a chance that we're including malicious code without being aware of it.

Note that maven2 will need to bootstrap itself from binaries included in the tarball for the first build in koji. After that (and before final review) we'll be able to delete those binaries.

No System Libraries

Including several upstream projects inside of a package can inadvertantly mix conflicting licenses together (for instance, Apache License and GPLv2), include proprietary code that we cannot ship, include code with security flaws that we are not tracking, and other issues that could cause legal or security issues.

Headline text