<br><div class="gmail_quote">On Mon, Jun 22, 2009 at 7:25 AM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><div></div><div class="h5"><br>
Martin Pool wrote:<br>
> 2009/6/21 Maritza Mendez <<a href="mailto:martitzam@gmail.com">martitzam@gmail.com</a>>:<br>
>> I understand that nothing can (and does not need to be) perfectly<br>
>> synchronized, so this is a question not a bug.<br>
>><br>
>> When I noticed that there is already a 1.16 installer for Windows, I assumed<br>
>> I would find a tag for the 1.16 release in bzr.dev.<br>
>><br>
>> But when I did<br>
>><br>
>> bzr pull<br>
>> bzr tags | grep '1.16'<br>
>><br>
>> all I got was<br>
>><br>
>> bzr-1.16rc1 4431.1.3<br>
>><br>
>> I also see that there seem to be no tags at all for 1.13 and 1.14.<br>
><br>
> I believe there is an as-yet undiagnosed problem with propagation of<br>
> tags through pqm. (Robert may know more.) I'm not sure why there are<br>
> some tags and not others.<br>
><br>
<br>
</div></div>You can't tag a release until PQM has finished merging, testing, and<br>
committing it. So you can't have a release tag "right away".<br>
</blockquote><div><br>That makes sense. In fact, tagging before testing would be just plain wrong imho.<br>But should not tagging be done before (1 second or 1 hour, whatever) before the release is announced?<br>What I am suggesting is based on my experience where tagging is a required step in the release process rules.<br>
<br>Other rules are possible, of course! So I'm just asking what the rules are here in bzr-land.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The way we tend to get them in there is by someone else (like me) having<br>
created the tag in my 'jam-integration' branch, and then having that<br>
merged at some later time.<br>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The other way to do it is for whoever merges a release back to trunk. So<br>
when they pull their local copy to update it, they then tag it, and<br>
submit a copy of that branch to pqm for merging. (note that you still<br>
don't get 'bzr-1.16' on the official <a href="http://bazaar-vcs.org/bzr/bzr.1.16" target="_blank">http://bazaar-vcs.org/bzr/bzr.1.16</a><br>
branch...)<br>
</blockquote><div><br>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think PQM has actually been fixed WRT propagating tags. It was just a<br>
bug that PQM was doing ".fetch()" directly and not directly requesting<br>
tags get fetched.<br>
<br>
<br>
I also think that we probably need to update our release-manager<br>
documentation to include "when merging the release branch back to trunk,<br>
tag the release number".</blockquote><div><br><br>Yes. That one simple step gets it all done. <br><br>-M<br><br></div></div>