Strawman Proposal for a New Package Repository and Workflow
I'm going to try and be SCM-agnostic here, but of the distributed SCMs out there I'm most familiar with Git so some of what I propose here is probably going to be strongly influenced by Git and the concepts embodied in Git.
Choice of a Source Code Manager
Repository Structure
The current package repository (essentially) consists of RPM spec files, tarballs (linked to by reference in the lookaside cache), patches, and other Fedora-specific source files.
The new package repository would be based upon "exploded source trees" that have been modified so that the source tree can be checked out of the SCM, tarred up and submitted to Koji.
Note that this is a fundamental change in the philosophy of RPM which has been to build packages from pristine sources plus patches.
Exploded Source Trees
One question that arises at this point is where do the exploded source trees come from?
1. Direct clones of upstream source code repositories. If we choose the right SCM (or allow multiple SCMs that have the right properties) we can clone the upstream repository, create branches for our modifications, and away we go. (Note: two of our most important upstreams - the kernel and X.org - use Git).
1. Conversions of upstream source code repositories. It's possible to incrementally convert SCMs (see git-cvsimport and git-svn for examples) to our chosen SCM. The key is incremental conversion - that allows us to keep our copy of the source code up to date with relative easy.
1. Imports of tarballs. It can be done, but it's less than optimal. It may be necessary for projects that don't have a public source code repository or have a public source code repository managed by a SCM that we can't convert.
Modifications to Source Trees
The upstream source trees will need to be modified for a number of reasons:
1. To add a Fedora-specific spec file. Many upstream projects have a spec file in their source code but it is rarely in shape to be submitted directly to the build system.
1. To patch in Fedora-specifc changes for things like different locations for installed files (FHS compliance) or to add features that are not in the upstream source (the Fedora kernel has many features not available in the "vanilla" kernel).
1. To add other files required to get a usable Fedora package (again, the Fedora kernel package has a number configuration files required to build a kernel woth the correct features enabled).
Many projects do not include things like the outputs of autoconf or automake in their source code repositories. It would be my recommendation that such outputs *not* be added to the Fedora package repository and that they be generated during the build.
Building Process
1. Maintainers would submit the URL to the repository and a tag name. 1. Koji would then: 1. Clone the repository to a local working directory. 1. Check out the tag name. 1. Create a tarball of the checked out code. 1. Koji would retain the SCM history and configuration information (e.g. the .git, .hg, or .svn directories). This will make it easier for someone that just has the SRPM to generate patches to send back to Fedora or upstream 1. Use the tarball to create a SRPM.
Review Process
1. Packages to be reviewed would no longer be posted as SRPMs. Instead people wanting to