[Pkg-puppet-devel] Tags and upstream

[micah anderson]

On Fri, 24 Feb 2012 18:16:36 +0100, Stig Sandbeck Mathisen <ssm at debian.org> wrote:
> Micah Anderson <micah at riseup.net> writes:
> 
> > Last night, when pushing the 2.7.11-1 tag, I accidentally pushed all
> > upstream's tags,
> 
> I've done that myself, on another package, with about as many releases.
> 
> *bing* you have mail, *bing* you have mail, *bing*.... :D

exactly... :)

> > some of which were refused. I went through and removed them all, but I
> > first had to disable the update hook because it was denying me from
> > doing interesting tags. I'm not even sure where that hook came from,
> > does anyone know? It seems to have been created in 2007, based on the
> > filesystem.
> 
> If it was the "update" hook (now called "update.disabled"), it just
> prevents the repo from accepting tags with no annotation (and GPG
> signature).

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.

> This is visible at
> http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git, where you see
> some tags in the list with no description. The hook would prevent these
> From being pushed to the repo.

Ok, I see now.

> You can safely remove the debian/2.7.11-1 tag, and replace it with a
> signed one, if you like.

I did that, and I replaced the squeeze3 and squeeze4 tags with a signed
one as well.

> We would need to replace our local tags after that. "git tag -d
> debian/2.7.11-1" and "git remote update" would get the new one.

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

> > 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.

> 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?

> The "upstream" branch on git.debian.org still points to the
> "upstream/2.7.10" tag.

Yes, I wasn't able to do a git-import-orig, nor was I able to merge
upstream onto master, so I ended up doing the merge described before
which resolved all commits.

> 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 think if we are doing the same thing in the future this wont happen.

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20120224/0aa6e378/attachment.pgp>