[Pkg-puppet-devel] Tags and upstream

Fri Feb 24 19:29:14 UTC 2012

micah anderson <micah at riseup.net> writes:

> It was that hook, I've gone and put it back now.
>
> I didn't understand what the annotation bit was about, but it makes
> sense when I think about signing the tag.

> The annoying thing about this hook was that it made it so *some* of
> upstream's tags were pushed, and not others (the ones that were signed
> were pushed) and then I wasn't able to delete the tags from the remote
> side, unless I disabled the hook.

I guess the hook views the "empty" tag used to delete existing tags as
"not annotated", and disallows the update. 

We've got privileges to disable the hooks, so I'll just view it as an
extra step to take when I need to do something destructive to the repo.

> Yep, I did this locally, so you should as well.

Yay, new tags :)

>> > I also had some problems merging the upstream's release into
>> > master, there were quite a few merge conflicts, which I would not
>> > expect as going from pristine upstream X to pristine upstream Y
>> > should not result in conflicts, so I'm a little puzzled about the
>> > state of that branch. In the end I had to do 'git merge
>> > upstream/<newversion> -X theirs' to merge in the new upstream.
>> > Perhaps its been done in a different way recently?
>> 
>> It looks like the "2.7.11" tarball was imported on top of the
>> "2.6.3rc1" upstream release instead of "2.7.10".
>
> Hm, that is why I was having problems. I guess I'm confused then why
> 'master' was 2.6.3rc1.

Could be any number of reasons; git is incredibly complex, and our build
tools are, too. I'll not speculate. :)

>> It makes the diff rather large, and the git history interesting, but
>> it should not have any effect on the generated debian source or
>> binary packages.
>> 
>> (The commmit "15b6a3e8c54c0199926cde04e8a6c0da3acde3bb" has
>> "1f6c832d659a0829e05427fb4e266980741a3481" as parent commit. It should
>> have had "c17b3ba16e7013f06416f10b8752ef783f048717" as parent. If you
>> try the "gitk" program, it visualizes this rather well)
>
> Ok, so that is what was going on. I'm a bit confused because I think
> that the way that you have been bringing in upstream code is different
> From how I've been doing it, so this would be a good opportunity to
> sync up on that!
>
> So... what are the steps that you are taking to import new upstream
> code and release it? I suspect its with git-import-orig and
> git-buildpackage? The way I was doing it involved gitpkg and merging
> upstream, but perhaps you could describe your steps?

Short version: "git import-orig" to import, "gitpkg" and "sbuild" to
build, and "git buildpackage" just for tagging the release. I used "git
buildpackage" to build earlier, but "gitpkg" is just lovely to work
with.

Keeping everything in sync
--------------------------

* "git remote update" keeps in sync, without moving my own branches.

* "git pull" if my "master" branch is not in sync with "origin/master".
  (Same for "upstream" and "pristine-tar" when there's a new upstream
  release.) I try to keep my own changes in feature branches before
  merging back to master, so there's little risk of conflicts.
  "git-wtf" is a good tool to download from somewhere to check 

Importing new release tarball
-----------------------------

* Make sure "master" matches "origin/master", "upstream" matches
  "origin/upstream" and "pristine-tar" matches "origin/pristine-tar"

* "git import-orig --uscan --pristine-tar" updates "pristine-tar" with
  the new tarball, sets "upstream" to the content of the tarball, then
  merges this into "master".

  - If this fails, I can back out all changes with "git checkout master
    && git reset --hard origin/master" (same for "upstream" and
    "pristine-tar") and try again. Until I push, I can always delete my
    local changes, and try again.

* "dch -D UNRELEASED -v 1.2.3-1 New upstream release" to update
  debian/changelog, and commit.

  - I often forget "-D UNRELEASED".

* "git push" 

* "git push origin upstream/1.2.3-1" (Will this also perform the
  previous step? Can't remember)

  - At this point, we have an unfinished release, but the upstream
    version is imported and pushed fast, enabling others to build their
    own versions on top of that, and merge later.

Bureaucracy
-----------

* "git diff upstream/1.2.2 upstream/1.2.3", and read through everything
  to check for new copyright statements. Update debian/copyright if
  there are changes.

Change, build and test until OK
-------------------------------

* "pristine-tar checkout something_1.2.3.orig.tar.gz", and move it to
  the gitpkg package build directory. (or download and rename the
  upstream release tarball). It's very nice if the checksum of our
  tarball and upstream's tarball match.

* "gitpkg master" (if you work directly on the "master" branch) for each
  major change to build test builds, until I'm satisfied.

  I build with "sbuild", but any build system using a clean build
  environment will do. I've told "sbuild" to also run lintian on each
  build. It can also run "piuparts", but that takes bit of time.

* test. "lintian" unless that happens for each build.

* "debdiff something_1.2.3-1_amd64.changes \
   something_1.2.2-1_amd64.changes"

  ...shows changes between versions. Also works on ".dsc" files, but I
  get that information from other tools.

Release and upload
------------------

* "dch -r" Change "UNRELEASED" to "unstable" in debian/changelog,.

* "git buildpackage --git-tag-only --git-sign-tags" to make a signed
  tag. (it could be done with "git tag --lots-of-options", but I'm lazy)

* "gitpkg debian/1.2.3-1" to build the final .dsc from the new tag.
  Mostly redundant, but it ensures that the package is built from the
  tag.

* "sbuild" or whatever for the final build, and test the packages.

* "dput ssh-upload something_1.2.3-1_amd64.changes"

>> If you like, I could try doing a local "git import-orig" on top of
>> that, and see if a merge will create a direct "upstream" history line
>> which can be merged into our "master".
>
> If you would like to try it, please feel free.

I'll try. :)

> I think if we are doing the same thing in the future this wont happen.

That sounds reasonable.

-- 
Stig Sandbeck Mathisen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20120224/2b346aa6/attachment-0001.pgp>