Design Goals
1. Allow packagers comfortable with the workflow in the current package repositories to use the Git package repositories with minimal retraining.
Repositories
Official Package Repositories
Each package would have an "official" Git repository. This is the repository that Koji would pull information from to build RPMs from.
git://packages.fedoraproject.org/packages/$package http://packages.fedoraproject.org/packages/$package git+ssh://$username@packages.fedoraproject.org/packages/$package
Instead of using directories as a "poor man's branch" as the current CVS and many of the proposals for a new VCS system, this proposal uses "real" branches in Git. So for example, for the kernel package, there would be a Git repository at
git://git.fedoraproject.org/packages/kernel
that would have branches named "devel", "F-7", "FC-6", "EL-5", etc.... Git tags would be used in a similar manner to CVS, except that moving tags would be forbidden. For discussion see the "On Re-tagging" section of the git-tag manual page.
Branch Names in Official Package Repositories
The official package repository will only allow commits on branches with names that match the following regular expressions:
- ^devel$
- ^FC?-[0-9] +$
- ^EL-[0-9] +$
- ^OLPC-[0-9] +$
Pre-commit scripts will be developed that enforce this restriction.
Furthermore, commits on these branches will only be accepted if they are "open". Branches are open if a VCS request has been submitted through bugzilla and a VCS admin has opened the branch (possibly creating the repository in the process). The branches will be closed when the release the branch is for reaches end of life.
Tag Names in Official Package Repositories
Tag names must match the N-V-R of the package as extracted from the .spec file.
Patch Development Repository
Packagers will be encouraged to use a patch development repository to develop patches in. The patch development repository will contain the "exploded source" of the package and will be used to
Setting Up Patch Development Repositories
The procedure for setting up a patch development repository is going to depend on how an upstream project manages it's source code.
1. If the upstream project does not have a public source code repository, then released tarballs will be expanded and imported into the patch development repository.
1. If the upstream project has a public source code repository, but the repository is maintained using tools that cannot be imported into a Git repository then either:
1. released tarballs will be expanded and imported into a Git repository or
1. snapshots of the source code repository will be generated using the native tools and then imported into a Git repository
1. If the upstream project has a public source code repository and the repository is maintained using tools that *can* be imported into Git, then
1. If the upstream projects uses Git to maintain a public source code repository then the patch development repository will be a clone of the upstream repository.
Private Package Repository
Packagers could request package repositories so that they could share development work on packages and/or request "scratch" builds from Koji. The packager that requested the repository would be the only user allowed to commit to the repository but the repository would be world-readable. There would be no restrictions on the naming of branches or tags but the contents would still be required to be
Embargoed Package Repositories
From time to time it may be necessary to develop updates to packages in a non-public repository. For example, if a remotely-exploitable vulnerability was discovered in the kernel, developing an updated package in the official package repository would alert troublemakers that the kernel was vulnerable before an updated package could be built and pushed out to the the mirrors. For security reasons, Koji should not pull from a repository not under the control of the Fedora Project.
Requests for embargoed package repositories shall be handled by the Fedora Security Response Team .
(Criteria for creating embargoed package repositories TBD.)
Once the updated package has been built and has been on the mirrors for a reasonable amount of time, all of the changes made to the embargoed package repository shall be pushed to the official repository. Commits to the embargoed package repository will then be disabled until the next time that a package update needs to be deveoped under embargo. Audits of the embargoed package repositories should be conducted by the FSRT to ensure that this rule is followed.
Common Repository
This repository would contain the Makefiles and scripts that simplify the task of interacting with the package repository and the build system. Once submodule support in Git becomes stable enough, submodules will be used to link the common repository to the package repositories.
TODO
- hook scripts:
- pre-receive:
- Verify that the user pushing updates into the repository is in the packages ACL.
- Verify that the branch is open.
- If a tag is created verify that the N-V-R of the package matches the tag name.
- post-receive:
- send email announcements out
- koji:
- Modify koji so that it can build SRPMs from a GIT repository instead of a CVS repository.
- There is no official GIT url standard that will allow us to specify a tag value, so I propose using:
- git+ssh://username@git.fedoraproject.org/packages/packagename#tagname
- git://git.fedoraproject.org/packages/packagename#tagname
- Need a test instance of Koji so that GIT integration can be tested without disrupting production instance.
- git-import script
- Replacement for cvs-import.sh
- Use fast-import
- Mass renaming of .cvsignore to .gitignore
- Get cgit into Fedora. Gitweb is too slow (at least on my system).
- Move the demonstration system over to a test Xen guest hosted on Fedora Infrastructure .