Hi, I uploaded haskell-x11, with all history I could easily get hold of (snapshot.debian.net and my laptop). I also adjusted the maintainer fields, documented that in the changelog, but kept a distribution of "UNRELEASED" so that it’s clear that this is not meant to be uploaded just now: http://git.debian.org/?p=pkg-haskell/haskell-x11.git;a=commitdiff;h=710575118999bf914b75d1b47d2faf408c7da1cc I also set the Vcs-* fields: http://git.debian.org/?p=pkg-haskell/haskell-x11.git;a=commitdiff;h=aeb9cba85de7c8b2ddbfd7524e9647c350cd100b If you didn’t know it, you can keep debian/changelog entries and git commit messages in sync by using: $ # do your changes $ dch "Your message" $ debcommit -a Note that the overview on http://git.debian.org/ needs a while to pick up new repositories. > Next steps: > > 1) Deciding on a set of best practices. I suggested some on the wiki > (use of --pristine-tar, branch naming, etc.) We must agree on these if > we are to have a working set of automated tools later. I think it’s ok to go by git-buildpackage’s defaults, at least in the cases where we do not import an upstream repository. If we do, we need to check whether we want to separate between upstream and upstream-dist (i.e. the contents of upstream’s VCS and of upstream’s released tarballs). I’ve made the experience that having upstream’s history in the packaging git does not gain you much, and would be in favour of a „always use git-import-dsc on released tarballs, ignore upstream’s git“ workflow. > 3) Uploading packages with changed Maintainer: lines. I’d say no need to do extra uploads for that, but we can make the change in git already to make sure the change is done with the next upload. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil