On Wed, Jul 06, 2011 at 19:02 +0200, Thomas Preud'homme wrote: > Personally I don't have any local branch, just remote branches. And when I > need to do a bisect for example I will checkout temporarily one of the > upstream dev branches. What I have is: > > origin => upstream repo > alioth => alioth repo > [ snip ] > I think the best is to have a working get-orig-source and then just call uscan > + debian/rules get-orig-source and pristine-tar commit the result. Of course > you should check the result but the interesting thing about this setup is that > people can reproduce the filtering themself when a new version is released and > you didn't package it yet. Ok based on this discussion and some great help on #debian-mentors I can now think of the following workflows. I would sincerely appreciate any comments on their merits and problems from people who have more experience than me. (i.e. almost all of you). The main desiderata are: * Intuitive setup that follow the principle of least surprise * debcheckout + git-buildpackage should work out of the box * Easy * Not much work for new upstream releases * Flexibel if something goes boink and adaptations are needed * Integrates well with existing infrastructure (github, alioth, commit hooks that push news to IRC channels or mailing lists, ...) Git-only ======== Branches -------- Name Local/Remote Merges From Tracks ------------------------------------------------------------------------------- master local upstream alioth/master upstream local real_upstream/master alioth/upstream real_upstream/master remote n/a alioth/master remote n/a alioth/upstream remote n/a Workflow -------- Essentially tags are merged from real_upstream/master into upstream and debian. The debian branch also contains the debian packaging and is the branch from which Debian releases are cut. Packages are built with git-buildpackage and the orig tarball is automagically created with "git archive" from a tag. (Or?) Questions --------- * How to differentiate between upstream and packaging history? → git-dch will be flooded with real_upstream changelogs (Or?) * How to make sure that Charles Plessy is happy? (i.e. commit-hooks do not flood channels with upstream changelogs) * I know how to download tags from github with githubredir, but how to handle repositories elsewhere? (in debian/watch) Git only - Repackaging ====================== Essentially the same as before, but with an additional dfsg_free branch that merges from upstream and is merged into master. My main questions here are due to my wish to see repacking done in an automated way by a script which is used in get-orig-source. * Where do you put those scripts? * What to do in the case of NMUs for new versions, such that the script is not applicable anymore and get-orig-version is essentially useless? * Are there collections of these scripts somewhere? I can think of "jh_repack" right now, but are there other helpers? * What uses get-orig-version? Tarball only ============ Branches -------- Name Local/Remote Merges From Tracks ------------------------------------------------------------------------- master local n/a alioth/master upstream local n/a alioth/upstream pristine-tar local n/a alioth/pristine-tar alioth/master remote n/a alioth/upstream remote n/a altoth/pristine-tar remote n/a Workflow -------- Tarballs are downloaded from upstream and merged with git-import-orig, orig tarballs are constructed from upstream + pristine-tar. Questions --------- * Is pristine-tar *really* needed here as it will basically say "No change from upstream"? I have to confess that I don't quite see the merit of pristine-tar when generating tarballs as those should be exactly the same tarball as produced by "git archive TAG. Or am I missing something here? Combination =========== I can easily see how the "git-only" workflow can also just be changed to use "git-import-orig --uscan" which somehow feels like the right thing to do. What to do though if new tarballs suddenly needs repacking? In a way I have the feeling that the "tarball" only workflow is much better suited for packaging, but something in me says that it is wrong as the tarballs are not really needed because everything that is needed is already in the VCS. Sorry for the many questions -- I certainly owe all of you a dram of Talisker when we meet ... -- .''`. Wolodja Wentland <babilen@gmail.com> : :' : `. `'` 4096R/CAF14EFC `- 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
Attachment:
signature.asc
Description: Digital signature