Hi.
With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head
So the questions are: - how can I add tag '0.9.3' to commit abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore - how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5 in future? - what's the general guidelines for tagging new versions? Do we go through gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria?
Hi Max,
On Tue, Dec 13, 2016 at 06:29:04PM +0100, Max wrote:
With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head
Thisis indeed odd. The normal procedure should be to push changes via the gerrit review process, and then after code has ended up in master push the related tags on those versions.
So the questions are:
- how can I add tag '0.9.3' to commit
abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore
I just did
"git tag -s 0.9.3 abc46af90fde9e9435dee5f4f472aec3f68d3353" "git push gerrit 0.9.3"
I'm still waiting for this to show up in the public read-only repo on git.osmocom.org, though.
- how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5
in future?
The question is how did those tags end up in the repository? Was the above procedure used, or did somebody push the tags already while patches were still in review?
- what's the general guidelines for tagging new versions? Do we go through
gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria?
I think I mentioned it recently somewehre: We should bump the minor version number each time a new symbol is added to libosmocore, so the code depending on new symbols can require a certian minimum version.
Hi.
Can we swap 0.9.5 and 0.9.6 than? I don't think any of the tools like gbp-dch can really accommodate for such an unexpected time flow in git history.
On 14.12.2016 00:21, Harald Welte wrote:
Hi Max,
On Tue, Dec 13, 2016 at 06:29:04PM +0100, Max wrote:
With the migration to gerrit the situation around version tagging become even funnier than before. For example right now in libosmocore v0.9.3 does not exist as a git tag, only as entry in debian/changelog. Versions 0.9.5 and 0.9.6 are committed in reversed order - see output of git log --tags --show-notes --decorate | grep 'tag:' | head
Thisis indeed odd. The normal procedure should be to push changes via the gerrit review process, and then after code has ended up in master push the related tags on those versions.
So the questions are:
- how can I add tag '0.9.3' to commit
abc46af90fde9e9435dee5f4f472aec3f68d3353 in libosmocore
I just did
"git tag -s 0.9.3 abc46af90fde9e9435dee5f4f472aec3f68d3353" "git push gerrit 0.9.3"
I'm still waiting for this to show up in the public read-only repo on git.osmocom.org, though.
- how can we prevent the inverted commit situation as with 0.9.6 and 0.9.5
in future?
The question is how did those tags end up in the repository? Was the above procedure used, or did somebody push the tags already while patches were still in review?
- what's the general guidelines for tagging new versions? Do we go through
gerrit or ask responsible person (who?) to do it manually? Or even auto-tag commit matching certain criteria?
I think I mentioned it recently somewehre: We should bump the minor version number each time a new symbol is added to libosmocore, so the code depending on new symbols can require a certian minimum version.
- how can I add tag '0.9.3' to commit
I made those tags recently, I also made a wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
One may need the appropriate pushing powers on gerrit to set a tag? Let me know if I should change access permissions... Could be good to agree whom to allow tagging and some guidelines.
Above wiki page would be a good place to document such.
git log --tags --show-notes --decorate | grep 'tag:' | head
commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
In the revision history, 0.9.5 comes before 0.9.6, but 0.9.6 has an earlier commit date.
This comes from to the way git does rebases: the commit's date remains the same as the original commit time. Most of our log history has wildly jumping dates. I'm not sure whether we will or should get rid of that.
So, my guess is: the way the tags were created doesn't matter. We can't re-order the way they are displayed as long as the two *commits* that are tagged (whenever) keep the same dates:
2016-12-08 17:47 <0.9.6> 2016-12-10 17:01 <0.9.5>
I can think of ways to work around it, sort of like
$ git log --tags --show-notes --decorate | grep 'tag:' | sort -k 1.54 -r -V | head commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
(though it would be good to filter on signed tags as well)
The most important question: do we have an actual use case where this wrong ordering breaks anything?
~N
I've checked with gbp dch and it seems to work fine - it treats commit log as emacs rather than as git log :)
So we don't have to do anything about 0.9.5 and .6, pardon the noise.
On 14.12.2016 13:54, Neels Hofmeyr wrote:
- how can I add tag '0.9.3' to commit
I made those tags recently, I also made a wiki page: https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release
One may need the appropriate pushing powers on gerrit to set a tag? Let me know if I should change access permissions... Could be good to agree whom to allow tagging and some guidelines.
Above wiki page would be a good place to document such.
git log --tags --show-notes --decorate | grep 'tag:' | head
commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
In the revision history, 0.9.5 comes before 0.9.6, but 0.9.6 has an earlier commit date.
This comes from to the way git does rebases: the commit's date remains the same as the original commit time. Most of our log history has wildly jumping dates. I'm not sure whether we will or should get rid of that.
So, my guess is: the way the tags were created doesn't matter. We can't re-order the way they are displayed as long as the two *commits* that are tagged (whenever) keep the same dates:
2016-12-08 17:47 <0.9.6> 2016-12-10 17:01 <0.9.5>
I can think of ways to work around it, sort of like
$ git log --tags --show-notes --decorate | grep 'tag:' | sort -k 1.54 -r -V | head commit 9c0751fc60e6282b5f5ff791d53f6f862f1c9c79 (tag: 3G_2016_09) commit 3cc757df1822114bf446dc2d5f6a95da92321a25 (tag: 0.9.6) commit 9795cf1b126d5567dbd0a25b56e9ba75be9513c1 (tag: 0.9.5) commit 3b6fb0880c3ab1e23a3d7d738d073b00c2a794c2 (tag: 0.9.4) commit abc46af90fde9e9435dee5f4f472aec3f68d3353 (tag: 0.9.3)
(though it would be good to filter on signed tags as well)
The most important question: do we have an actual use case where this wrong ordering breaks anything?
~N
-
Harald Welte -
Max -
Neels Hofmeyr