It would be really nice if Oracle developerss would start using either annotated tags (git tag -a) or signed tags (git tag -s) for lustre version tags. The default "git tag" command just creates a lightweight tag, so there is no record of who created the tag, or when the tag was created. Chris
On 2010-11-24, at 12:25, Christopher J. Morrone wrote:> It would be really nice if Oracle developerss would start using either > annotated tags (git tag -a) or signed tags (git tag -s) for lustre > version tags. > > The default "git tag" command just creates a lightweight tag, so there > is no record of who created the tag, or when the tag was created.Chris, thanks for the heads-up on this. We can start to use "git tag -a" for future build and release tags if that is more useful. Looking back through the commit history, I do see commit messages that are made whenever we do a build internally:> - Log ----------------------------------------------------------------- > commit 2a63fa84d379e4261dcdb40ee25cbf3547a9de0a > Author: Terry Rutledge <terry.rutledge at oracle.com> > Date: Fri Nov 19 13:33:04 2010 -0800 > > Updated for 2.1.0 build 08. > > diff --git a/lustre/autoconf/lustre-version.ac b/lustre/autoconf/lustre-version.ac > index 3454c63..2dc7ecd 100644 > --- a/lustre/autoconf/lustre-version.ac > +++ b/lustre/autoconf/lustre-version.ac > @@ -1,6 +1,6 @@ > m4_define([LUSTRE_MAJOR],[2]) > m4_define([LUSTRE_MINOR],[0]) > -m4_define([LUSTRE_PATCH],[55]) > +m4_define([LUSTRE_PATCH],[56]) > m4_define([LUSTRE_FIX],[0])This is updating the build version number.> The tag, v2_0_56_0 has been created > at 2a63fa84d379e4261dcdb40ee25cbf3547a9de0a (commit) > > - Log ----------------------------------------------------------------- > commit 2a63fa84d379e4261dcdb40ee25cbf3547a9de0a > Author: Terry Rutledge <terry.rutledge at oracle.com> > Date: Fri Nov 19 13:33:04 2010 -0800 > > Updated for 2.1.0 build 08. > -----------------------------------------------------------------------This is adding the tag on that commit. For existing tags it should be possible to determine from the commit hash approximately when the tag was created, though I can imagine that it is possible to create a tag on an old hash long after the fact. What specific use do you have for the tags, and is the above tag hash-to-commit-date mapping enough? Is there any reason NOT to always use "-a" when creating a tag? Terry, could you please add this into the build/release tagging procedure for the future? Cheers, Andreas -- Andreas Dilger Lustre Technical Lead Oracle Corporation Canada Inc.
On 11/24/2010 12:30 PM, Andreas Dilger wrote:> What specific use do you have for the tags, and is the above tag hash-to-commit-date mapping enough? Is there any reason NOT to always use "-a" when creating a tag?I hadn''t done a fetch from prime in a couple of weeks, and when I just did it I saw that v1_8_5_RC4 had been tagged 1.8.5. In that case, you can see that the change to lustre-version.ac to make it 1.8.5 actually happened several commits before the actual 1.8.5 tag. I have no way of knowing how long v1_8_5_RC4 was in existence before it became 1.8.5. Not a big deal, really. But it would have been simple to see what happened if the tag had been of the annotated/signed type. Also, in the past "git describe" did not stop at lightweight tags, only at annotated/signed tags. That may have changed in newer versions of git. I believe that annotated tags for lustre version numbers. In fact, it kind of seems like annotated tags should be the default behavior for "git tag". I can''t think of a good reason why you would not want a tag to be annotated if you are going to share it with others. My guess is that lightweight tags are just the default in git for historical reasons (they were implemented first). Chris
On Wed, 2010-11-24 at 14:17 -0800, Christopher J. Morrone wrote:>Christopher, You probably realize all of this but to ensure that it''s absolutely clear...> I hadn''t done a fetch from prime in a couple of weeks, and when I just > did it I saw that v1_8_5_RC4 had been tagged 1.8.5.Yes. This signifies that our release candidate 4 of the 1.8.5 series was what was released as the official 1.8.5.> In that case, you > can see that the change to lustre-version.ac to make it 1.8.5 actually > happened several commits before the actual 1.8.5 tag.That''s right. We have to change the version (lustre-version.ac) at the start of the 1.8.5 release candidate testing phase so that when a candidate is chosen, it can be released as it was created and tested and not regenerated just for the purposes of final release. Put another way, the exact same packages that were generated for the RC and tested and passed our QA are then given to the users. There is no regeneration of packages after the chosen RC to produce "GA" packages. This is to prevent any kind of silliness from being introduced into the GA packages between the chosen RC and the GA release.> I have no way of > knowing how long v1_8_5_RC4 was in existence before it became 1.8.5.By "long" are you referring to linear time here? Are you trying to assess how much time elapsed while testing the final RC before it was declared GA? b. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.lustre.org/pipermail/lustre-devel/attachments/20101124/d5149842/attachment.bin