No edit summary |
(Work in progress, gotta eat dinner.) |
||
| Line 2: | Line 2: | ||
== Overview == | == Overview == | ||
This proposal concerns the desire to replace Fedora's package source control, currently based on CVS, with git, and to improve the developer workflow at the same time. | |||
=== Problem Space === | === Problem Space === | ||
<!-- Describe the problem this proposal seeks to solve --> | <!-- Describe the problem this proposal seeks to solve --> | ||
Current package source control is in CVS, and designed in a way that can make the developer's life difficult. See [[Infrastructure/VersionControl#Current_Pain_Points]] for a list of current pain points with our package source control. See also Jesse Keating's [http://jkeating.fedorapeople.org/presentations/fudcon-die-cvs-die-2009.odp FUDCon presentation] on the issue. | |||
=== Proposed Solution === | === Proposed Solution === | ||
<!-- Describe proposed solution in detail --> | <!-- Describe proposed solution in detail --> | ||
We propose to convert the current package source control repositories into git format, turning the CVS release subdirs into git branches. We also propose to replace the Make and common/ dir system with a userland utility. | |||
=== Scope === | === Scope === | ||
<!-- Describe the scope of any project work or properties that will be affected by the proposal --> | <!-- Describe the scope of any project work or properties that will be affected by the proposal --> | ||
# CVS | |||
# git | |||
# fedpkg | |||
# Koji | |||
# Wiki Pages | |||
=== | ==== CVS ==== | ||
<!-- The first of a list of prerequisites, and what exactly needs to be done with it --> | <!-- The first of a list of prerequisites, and what exactly needs to be done with it --> | ||
All available history from Fedora dist-cvs will need to be imported. Currently we are planning to use parsecvs in order to import the history. This requires read access to the ",V" files which live on the CVS server. CVS commits must be disabled prior to the final import run to prevent any lost changes. | |||
==== | ==== git ==== | ||
<!-- The second of a list of prerequisites, and what exactly needs to be done with it. Add more subsections as needed for additional components. --> | <!-- The second of a list of prerequisites, and what exactly needs to be done with it. Add more subsections as needed for additional components. --> | ||
Git is where the CVS history will wind up. As mentioned, parsecvs will be used to get content into the git repo. The layout of the git repos will be: | |||
# One git repo per package | |||
# Development (rawhide) happens on origin/master | |||
# Remote branches for each Fedora/EPEL release (F-12, F-11, EL-5...) | |||
== Discussion Points == | == Discussion Points == | ||
Revision as of 02:03, 17 December 2009
Overview
This proposal concerns the desire to replace Fedora's package source control, currently based on CVS, with git, and to improve the developer workflow at the same time.
Problem Space
Current package source control is in CVS, and designed in a way that can make the developer's life difficult. See Infrastructure/VersionControl#Current_Pain_Points for a list of current pain points with our package source control. See also Jesse Keating's FUDCon presentation on the issue.
Proposed Solution
We propose to convert the current package source control repositories into git format, turning the CVS release subdirs into git branches. We also propose to replace the Make and common/ dir system with a userland utility.
Scope
- CVS
- git
- fedpkg
- Koji
- Wiki Pages
CVS
All available history from Fedora dist-cvs will need to be imported. Currently we are planning to use parsecvs in order to import the history. This requires read access to the ",V" files which live on the CVS server. CVS commits must be disabled prior to the final import run to prevent any lost changes.
git
Git is where the CVS history will wind up. As mentioned, parsecvs will be used to get content into the git repo. The layout of the git repos will be:
- One git repo per package
- Development (rawhide) happens on origin/master
- Remote branches for each Fedora/EPEL release (F-12, F-11, EL-5...)
Discussion Points
Comments?
To leave a comment, use the Talk page for this proposal.