Differences between revisions 2 and 3
Revision 2 as of 2010-09-08 06:00:01
Size: 3279
Comment:
Revision 3 as of 2010-09-28 04:49:02
Size: 3226
Comment:
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
Patches and fixes to upstreams are in ''patch-<name>'' or ''typo-<name>'' branches of the respective upstream source. These are not rebased and should be forwarded to upstream. When patches or fixes are no longer needed in the ''master-sid'' branch they are renamed to ''archive-patch-<name>'' or ''archive-typo-name''. Patches and fixes to upstreams are in ''patch-<name>'' or ''typo-<name>'' branches of the respective upstream source. These are not rebased and should be forwarded to upstream. When patches or fixes are no longer needed in the ''master-sid'' branch they are deleted.

Git usage in the Common Lisp packaging Team

Still a proposal!

Recommandations for handling the Git repository.

The Git repositories are stored on Alioth, for example for clisp we have:

  • web view

  • For people with Alioth access: git clone ssh://git.debian.org/git/pkg-common-lisp/clisp.git

  • Anonymous access either one of:
    • git clone http://git.debian.org/git/pkg-common-lisp/clisp.git

    • git clone git://git.debian.org/git/pkg-common-lisp/clisp.git

Repository setup

Upstream goes to a branch called upstream, each upstream version that is packages is also a branch upstream-<version>. The upstream for a released Debian version has a parallel branch called upstream-<Debian code name>, for example upstream-lenny.

The debian/ directory lives in the debian-<upstream version> branch. This branch is created new for every new upstream release and is rebased on the new release. So in practice you go:

git checkout -b upstream-2.49 upstream-2.48
#import 2.49 here
git add ..
git commit ...
git rebase --onto debian-2.49 upstream-2.49 debian-2.48
git checkout debian-2.49
dch --newversion 2.49-1 --distribution UNRELEASED

Patches and fixes to upstreams are in patch-<name> or typo-<name> branches of the respective upstream source. These are not rebased and should be forwarded to upstream. When patches or fixes are no longer needed in the master-sid branch they are deleted.

The real package itself is build on the master-sid branch, which is branched into the master-testing and master-<Debian release codename> when the package moves there.

The master-sid branch is recreated on each new upstream release like:

git branch -m master-sid master-<debian package version>
git checkout -b master-sid debian-<upstream version>
git pull . patch-<name>
git pull . patch-<name 2>
etc

If you discover a problem while working on preparing the master-sid branch you fix is in a new branch, for example if you have a build-failure on sparc due to a GCC bug you can do:

git checkout -b patch-sparc-gcc-bug-in-2.49 upstream-2.49
vi ...
git commit -a -m '...'
git checkout master-sid
git pull . patch-sparc-gcc-bug-in-2.49

Don't forget to forward this new patch to upstream.

You build using git-buildpackage --git-debian-branch=master-sid --git-upstream-branch=upstream-<version> -us -uc

Other Guidelines

  • Keep the distribution UNRELEASED until we release
  • Keep one commit to one consistent change, use git commit --amend in case you make mistakes

  • Do not change debian/changelog in the patches or typo branches, note the merge explicitly

  • After each upload, the first commit should be creating a new changelog entry with distribution set to UNRELEASED
  • If upstream uses a SVC consider importing the upstream changes into the git tree.

NMU's and patches

NMU's are strongly encouraged to apply the changes directly into the git repositories.