Releasing GNOME modules

Community
,
41

Hi,

Because git is distributed, and deleting the tag in one repo does not
delete it in everybody else’s copy of the repo. It gets really
confusing when your 3.54.3 tag is different from other developers’
tags, so GNOME simply prohibits this.

Branches deleted in the remote are not deleted from the respective
clones, thus the branch deletion should be disabled in the GNOME for
the very same reason :stuck_out_tongue:

I believe “git fetch --prune-tags” is there just for this reason, to
detect what (or if anything) changed with the remote tags. The same as
git fetch --prune helps with the branches, even it does not seem
to delete existing local branches which point to those now deleted
branches.

Both GitLab.com and GitHub.com allow to delete tags. I hesitate to
believe they are all wrong, with so many projects they host, and only
the GNOME instance does “the right thing” by disallowing tag deletion.
It’s safer, I agree, but it’s not the right thing.

The only reason why I do so much noise about this is that I do not want
to push more work on others (the packagers), just because I’m stupid
and I made a mistake. That won’t be fair. In this particular case,
there is no code change involved, thus it does not matter much where
precisely the tag would point here.

There are only 10 forks of the evolution-ews in the GNOME GitLab
instance, where one of them is mine. The other were not updated from 2
months to several years. They are stale. The GitHub copy has 21 forks,
but I cannot see whom they are and how much current they are.

I can come up with some stupid workarounds like reverting all the
commits in the evolution down to the pre-API change commit (that’s just
several weeks including the holiday break), re-run the release CI, and
then revert the revert, but that really sounds stupid and it would
poison the git history and waste the disk space.

I suppose I cannot convince anyone to help me to not push more work to
the other maintainers here though. You (a plural “you”) might be more
stubborn than I am (I am very stubborn). It seems this will result in a
nonsense tag version, which will partly look like a new version, but it
will be the 3.54.3 inside. A dirty non-hack. I do not like this. It will
still need an additional work for the packagers.

Bye,
Milan
42

Uhhh… What exactly are GNOME modules?

43

Hi,
yes, that’s what I’m thinking of in case nobody will be willing to do a
clean 3.54.3 tarball release.

A fan fact: the evo-ews received a report of missing the tarball, yay.

Bye,
Milan
44

Deleting tags, replacing tarballs with a different checksum ones and so on is what would cause packagers extra work, as they’ll need to deal with it, worry about whether the tarball got replaced by a compromised one and so on. I’m talking as a packager.

If a release tag or tarball is there, it’s there, no going back on that unless it actually was compromised and needs safety cleanup, but that’s what this CI based system is intended to prevent (ignoring code compromises committed into the git repository).

45

Hi,
there is no tarball from the existing tag, thus there is no replacing
of the tarball. I won’t ask to delete the tag if the tarball was
created. I consider download.gnome.org as a read-only source of the
truth. Once the things are there they stay there unchanged. Being there
a tarball I’d just make a new point release to fix any problem with
that tarball.

have the tarball release on an expected place. That the tarball is
created from the tag is only an implementation detail, from my point of
view.

Thanks and bye,
Milan