[libvirt] Cleaning up libvirt.git tags
We have four types of tags in libvirt.git right now: * vX.Y.Z: we have one of these per release, starting with v0.1.0 from April 2006 and going all the way to v5.2.0 from April 2019 (but see below). Most of them[1] are PGP-signed. * LIBVIR(T)_X_Y_Z: these point to the same commit as the ones above, but the last one we created is for v0.6.5 from July 2009; not a single one is PGP-signed. * CVE-YYYY-*: these point to the commit fixing the corresponding vulnerability. We seem to have stopped creating them in 2017, even though we definitely have had to deal with CVEs since ;) * LIBXEN_FIRST_COMMIT: one-of-a-kind tag pointing to the second ever (!) libvirt (!) commit. Of course the project was still called libxen back then, but this is the only surviving tag to reference the old name. Interestingly[2] enough, a few releases seem to have partially or completely slipped through the cracks: version commit tag tarball --------- -------------- ----- --------- v0.1.2 | 567b42ce6a07 | no | no v0.1.5 | 786e029cd743 | no | yes v0.4.0 | 6cb028991705 | no | yes v0.4.3 | 7db4c905d745 | no | yes v0.4.5 | 9d3d43436eac | no | yes Note that I stopped checking at v0.6.5, so there might actually be more. Anyway, since the LIBVIR(T)_X_Y_Z tags are a strict subset of the vX.Y.Z tags, and we have abandoned that naming scheme a decade ago, all they're doing right now is clutter the output of 'git tag' and I would suggest getting rid of them; same goes for that lonely, lonely LIBXEN_FIRST_COMMIT tag, which serves no real purpose other than reminding us that the project was named differently for, like, an entire month. As for the missing release commits, I see no harm in creating them retroactively for completeness' sake, but if nobody can be bothered doing that I'll also fully understand :) The CVE tags... I really don't have an opinion there. Thoughts? [1] Though not all of them: I'm pointing my finger at you, Cole! :P [2] Well, to me at least. -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Apr 15, 2019 at 12:34:58PM +0200, Andrea Bolognani wrote:
We have four types of tags in libvirt.git right now:
* vX.Y.Z: we have one of these per release, starting with v0.1.0 from April 2006 and going all the way to v5.2.0 from April 2019 (but see below). Most of them[1] are PGP-signed.
* LIBVIR(T)_X_Y_Z: these point to the same commit as the ones above, but the last one we created is for v0.6.5 from July 2009; not a single one is PGP-signed.
* CVE-YYYY-*: these point to the commit fixing the corresponding vulnerability. We seem to have stopped creating them in 2017, even though we definitely have had to deal with CVEs since ;)
* LIBXEN_FIRST_COMMIT: one-of-a-kind tag pointing to the second ever (!) libvirt (!) commit. Of course the project was still called libxen back then, but this is the only surviving tag to reference the old name.
Interestingly[2] enough, a few releases seem to have partially or completely slipped through the cracks:
version commit tag tarball --------- -------------- ----- --------- v0.1.2 | 567b42ce6a07 | no | no v0.1.5 | 786e029cd743 | no | yes v0.4.0 | 6cb028991705 | no | yes v0.4.3 | 7db4c905d745 | no | yes v0.4.5 | 9d3d43436eac | no | yes
Note that I stopped checking at v0.6.5, so there might actually be more.
Anyway, since the LIBVIR(T)_X_Y_Z tags are a strict subset of the vX.Y.Z tags, and we have abandoned that naming scheme a decade ago, all they're doing right now is clutter the output of 'git tag' and I would suggest getting rid of them; same goes for that lonely, lonely LIBXEN_FIRST_COMMIT tag, which serves no real purpose other than reminding us that the project was named differently for, like, an entire month.
As for the missing release commits, I see no harm in creating them retroactively for completeness' sake, but if nobody can be bothered doing that I'll also fully understand :)
We should create the missing ones. When we stopped using the LIBVIRT_X_Y_Z tag naming scheme, our intention was to create new vX.Y.Z tags to match all the original LIBVIRT_X_Y_Z tags that we had.
The CVE tags... I really don't have an opinion there.
Thoughts?
IMHO deleting "clutter" is a non-goal. GIT history should be append only, and never changed after the fact. If you only want to see the 'vX.Y.Z' tags then just tell git to filter them when listing tags. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Mon, 2019-04-15 at 11:53 +0100, Daniel P. Berrangé wrote:
On Mon, Apr 15, 2019 at 12:34:58PM +0200, Andrea Bolognani wrote:
Interestingly[2] enough, a few releases seem to have partially or completely slipped through the cracks:
version commit tag tarball --------- -------------- ----- --------- v0.1.2 | 567b42ce6a07 | no | no v0.1.5 | 786e029cd743 | no | yes v0.4.0 | 6cb028991705 | no | yes v0.4.3 | 7db4c905d745 | no | yes v0.4.5 | 9d3d43436eac | no | yes
Note that I stopped checking at v0.6.5, so there might actually be more. [...] As for the missing release commits, I see no harm in creating them retroactively for completeness' sake, but if nobody can be bothered doing that I'll also fully understand :)
We should create the missing ones. When we stopped using the LIBVIRT_X_Y_Z tag naming scheme, our intention was to create new vX.Y.Z tags to match all the original LIBVIRT_X_Y_Z tags that we had.
Perhaps I was not clear enough: for all releases in the table above, there is neither a vX.Y.Z nor a LIBVIRT_X_Y_Z tag. So it looks like the switch has been carried through as intended, it's just that some releases were never tagged in the first place.
Thoughts?
IMHO deleting "clutter" is a non-goal. GIT history should be append only, and never changed after the fact.
I obviously don't agree when it comes to this specific case :) But noted. -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Apr 15, 2019 at 12:34:58PM +0200, Andrea Bolognani wrote:
Anyway, since the LIBVIR(T)_X_Y_Z tags are a strict subset of the vX.Y.Z tags, and we have abandoned that naming scheme a decade ago, all they're doing right now is clutter the output of 'git tag' and I would suggest getting rid of them; same goes for that lonely, lonely LIBXEN_FIRST_COMMIT tag, which serves no real purpose other than reminding us that the project was named differently for, like, an entire month.
https://www.redhat.com/archives/libvir-list/2019-April/msg00102.html Jano
On Mon, 2019-04-15 at 13:02 +0200, Ján Tomko wrote:
On Mon, Apr 15, 2019 at 12:34:58PM +0200, Andrea Bolognani wrote:
Anyway, since the LIBVIR(T)_X_Y_Z tags are a strict subset of the vX.Y.Z tags, and we have abandoned that naming scheme a decade ago, all they're doing right now is clutter the output of 'git tag' and I would suggest getting rid of them; same goes for that lonely, lonely LIBXEN_FIRST_COMMIT tag, which serves no real purpose other than reminding us that the project was named differently for, like, an entire month.
https://www.redhat.com/archives/libvir-list/2019-April/msg00102.html
My healing commences. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Ján Tomko