On Aug 19, 2014, at 09:44 PM, Barry Warsaw wrote: >Anyway, I think that's it for now. Feel free to muck about in this package, >but please do let me know if you want to push any permanent changes. Tomorrow >I'll probably try to do a new upstream release to fix the typo in the setup.py >so I'll do a new package version and see how well that process works. Done. A few more thoughts: d/patches are handled very nicely. The thing I had to quilt patch in 2.0.1-1, I fixed in the new upstream version. When I updated to the new upstream, git-dpm did the right thing by deleting the entire d/patches directory. I.e. because the specific patch was no longer necessary, it got deleted, but then there were no other patches in the quilt stack, so the whole directory could just be dropped. This was handled completely seamlessly. Be sure you `git push --all --tags` or your upstream-* and pristine-tar branches don't get pushed. --tags of course pushes the tags, and `git-dpm tag` works nicely[*]. I really wish `git-dpm import-new-upstream` would optionally take no arguments, in which case it would call uscan to get the orig.tar.gz before importing. It would just save a little typing. Even cooler would be `git-dpm -vX.Y.Z` in which case it would add the d/changelog entry, uscan to download the new orig.tar.gz, then call import-new-upstream. git-dpm is "just" a shell script so I might try to submit a patch for that. It's a little inconvenient to test out a new upstream tarball. I think this is a corner case, but I'll describe the situation for posterity. I'm both upstream for lazr.smtptest and maintainer, and the bug I hit was in the setup.py so for 2.0.1-1 I just added a quilt patch to work around the problem. Now, I go back to upstream and fix the typo there, but before I release the new upstream, I'd like to test it in the context of a provisional package build. So I `python setup.py sdist` to create the tarball, copy it to blah.orig.tar.gz and then import it into my local git-dpm repo. I do a test build and notice that the upstream patch is not quite right. So I go back to the upstream branch, fix the bug again, generate a new orig.tar.gz and head back to the git-dpm repo. The problem is that I've already imported the 2.0.2 orig.tar.gz. The import had been committed on all three branches, otherwise I wouldn't have been able to test the new potential upstream release. To back out of this and import the newly generated 2.0.2 tarball, I have to checkout all three branches (i.e. upstream-lazr.smtptest, pristine-tar, and lazr.smtptest) and "uncommit" (`git reset --hard HEAD^`) the effects of the import. Now I'm back to a known good place and can replay the import. The other option would have been to do all this in a separate clone until I was happy, but that's kind of icky. I'm not sure what else would work better, and as I say it's a corner case so probably not worth spending much effort on. One last thing: I'm not sure I recommend going with the package name as the branch name. I'm tired of typing `upstream-lazr.smtptest`. The default git-dpm branch names are starting to make more sense. :) Cheers, -Barry
Attachment:
signature.asc
Description: PGP signature