On Mar 05, 2016, at 10:06 PM, Ben Finney wrote: >I have made another attempt, by using the above separation to inspire >several parallel branches: > >* master: An integration-only branch for what the DPMT team requires. >* upstream: The upstream source from released tarballs. >* pristine-tar: The data from ‘pristine-tar(1)’ for the tarballs. >* packaging: The Debian packaging. [...] > >I now keep the ‘upstream’ and ‘packaging’ branches representing the >parallel work: they never moerge into each other. > >All the actual development work on the package goes to: > >* Importing upstream tarballs to ‘upstream’ and ‘pristine-tar’. > >* Developing the Debian packaging on ‘packaging’. > >The ‘master’ branch, for those who want it, is the result of only >merge commits from ‘upstream’ and ‘packaging’, in order to make >finalised Debian releases. > >> TBH, if it were me, I'd probably take one of the simpler approaches >> and not worry about preserving all the vcs history from Bazaar. > >This was somewhat a revelation for me. The full history from the >earlier VCS is the most valuable part: it's the packaging work that is >the whole point of the repo I'm creating. > >So I keep the integrity of that by keeping it on ‘packaging’ branch, >and only merge it to ‘master’ when ready to release. > >The repo is now online at ><URL:https://anonscm.debian.org/git/collab-maint/pkg-python-lockfile.git/>. >Do you think that meets the DPMT policy?
Interesting. I hadn't thought about a separate packaging branch, since that doesn't fit into the typical git-dpm (or gbp afaik) workflows, but I can see why that works better for you. As far as DPMT policy goes, the repo isn't under git-dpm so officially until that happens I'd say "no". Have you tried your branch arrangement with git-dpm? I kind of think it should work okay, but it would be interesting to know. I suspect that it might not work quite as well with some of the gbp workflows, e.g. `gbp import-orig --uscan`[*]. Let's say it works fine with git-dpm. The other thing is that if you want to move the package into DPMT, and you want people to make changes on the packaging branch and then merge up into master, you'll want to add a d/README.source so that others walking up to the repo will know that the there's some deviation from https://wiki.debian.org/Python/GitPackaging My comment about not importing the full bzr vcs history of course assumed that the bzr history would still be available, but it's true that the split would make spelunking more difficult. The other option of course is to use something like `gbp import-dscs --debsnap` to preserve the upload history if not the intermediate commits. FWIW, I think the conversion to git is a good thing aside from all that, so if you were to keep it on collab and not put it in DPMT, I would still be entirely willing to sponsor it (until of course your successful DD comes through. :) Just let me know whether I should sponsor from the bzr repo or the git repo. Cheers, -Barry [*] I only mention this because I suspect at some point git-dpm will bit rot into uselessness and we'll either be forced or will want to switch. Not something to worry about right now though.
pgpYyHvuhtbOG.pgp
Description: OpenPGP digital signature
