tags in bzr.dev

[Maritza Mendez]

On Mon, Jun 22, 2009 at 7:25 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martin Pool wrote:
> > 2009/6/21 Maritza Mendez <martitzam at gmail.com>:
> >> I understand that nothing can (and does not need to be) perfectly
> >> synchronized, so this is a question not a bug.
> >>
> >> When I noticed that there is already a 1.16 installer for Windows, I
> assumed
> >> I would find a tag for the 1.16 release in bzr.dev.
> >>
> >> But when I did
> >>
> >>     bzr pull
> >>     bzr tags | grep '1.16'
> >>
> >> all I got was
> >>
> >>     bzr-1.16rc1          4431.1.3
> >>
> >> I also see that there seem to be no tags at all for 1.13 and 1.14.
> >
> > I believe there is an as-yet undiagnosed problem with propagation of
> > tags through pqm.  (Robert may know more.)  I'm not sure why there are
> > some tags and not others.
> >
>
> You can't tag a release until PQM has finished merging, testing, and
> committing it. So you can't have a release tag "right away".
>

That makes sense.  In fact, tagging before testing would be just plain wrong
imho.
But should not tagging be done before (1 second or 1 hour, whatever) before
the release is announced?
What I am suggesting is based on my experience where tagging is a required
step in the release process rules.

Other rules are possible, of course!  So I'm just asking what the rules are
here in bzr-land.


> The way we tend to get them in there is by someone else (like me) having
> created the tag in my 'jam-integration' branch, and then having that
> merged at some later time.
>

See, I think that is dangerous.  What if after the merge, testing reveals
more work is required?  This is my own bias, but in my job we have a social
rule which says the RM is responsible for manually applying the tag as a
last setp before announcing the release.  That way, release tags are always
100% authoritative.


> The other way to do it is for whoever merges a release back to trunk. So
> when they pull their local copy to update it, they then tag it, and
> submit a copy of that branch to pqm for merging. (note that you still
> don't get 'bzr-1.16' on the official http://bazaar-vcs.org/bzr/bzr.1.16
> branch...)
>

Exactly.  Except that I would require another round of regression to
validate the merge, before applying the release tag. I guess I should
mention that I think its ok to apply RC tags at any time, regardless of test
status, because RC implies that testing is not yet complete.  But the actual
release tag (as in "go ahead and burn thousands of discs") should mean that
all changes (including merges which should be fine but sometimes are not)
have been subjected to regression testing.  I admit to being paranoid about
this.  It's a much bigger deal if someone is literally manufacturing discs.
But for the bzr community maybe it is ok to tell people to roll back if they
don't like the latest release.


> I think PQM has actually been fixed WRT propagating tags. It was just a
> bug that PQM was doing ".fetch()" directly and not directly requesting
> tags get fetched.
>
>
> I also think that we probably need to update our release-manager
> documentation to include "when merging the release branch back to trunk,
> tag the release number".



Yes.  That one simple step gets it all done.

-M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090622/b607a909/attachment-0001.htm