Hi, eventually, we will have to migrate away from Darcs, I’m afraid. If only that nobody can use his ignorance of darcs as an excuse to do work here :-). I’m sure some of you will be happy to hear that. But this opens a new can of worms: What is the best git-based packaging approach for us? I would argue that we have uncommon needs. Most of our packages are very simple (and can be made even simpler with the help of cabal -debian/debdry), but often changes affect multiple packages (bumping of haskell-devscripts dependency) and may only make sense together (upgrading of dependency chains). So we should discuss what that means for us. In particular, I wonder if we find a scheme where all development happens in one git repository. Also, there is the question of what should be in a packaging git repository. I am a firm believer that the upstream code should _not_ be tracked in a packaging repository, on the grounds that we create and maintain the debian/ directory, and the debian directory only: The version in debian/changelog file and the debian/patches/ directory are sufficient to produce the source package. So I currently see three sensible variants: A. One repo per package, debian/ files in repo root. This is basically the status quo, simply converted to git. B. One repo per package, debian directory in repo. A small variation. This has the advantage that you can run $ git clone ..../haskell-foo.git $ cd haskell-foo $ origtargz and have a standard debian source directory, ready to run debuild or quilt or whatever. A .gitignore file can be crafted that makes sure that everything but "debian/" is ignored. Note that debcheckout supports this as well. C. One big repo, haskell-foo’s debian/ files in haskell-foo/debian/ Having one repo has various advantages: * Most importantly, there is one commit per logical change, even if it affects multiple packages. * This also reduces noise on the commit mailing list. * It is immediately clear which packages we have packaged. * No need to annoyingly create remote repositories when you package something new. * In order to compare the repo state with the package plan, only one repository has to be looked at, not 700. * It becomes easier to enforce certain things with git hooks, as they do not have to be set up for every repository. * Git hooks (and maybe jenkins jobs) have a global view of the packaging. But there are also disadvantages: * Slightly unusual, so needs explanation. * It is not possible to check out just one package. But maybe that is a good thing, for such a tightly coupled package set. * Some tools might need to be extended to support that well. For example debcheckout would need to support a "subdirectory" parameter in the url specified in Vcs-Git, similar to the branch parameter. * Tags needs to be qualified by the package name ("haskell -foo/1.0-1" instead of "1.0-1"). This would need support in debcommit, similar to how gbp supports --git-debian-tag which can be set to "%(pkg)/%(version)". I’d prefer C over B over A. How about you? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part