Add "How to make a libxkbcommon release"

[bluetech]

I hope I didn't forget anything. We can certainly automate some of this, but this is documenting what I am currently doing.

Note that I explicitly decided to remove publishing a tarball. Given what happened with xz backdoor, I think we are better off without them. I'm pretty sure most distros build directly from git these days. We should make a prominent note of this change in the announcement email. Old tarballs will not be removed.

Let me know if you have any comments.

[wismill]

I'm pretty sure most distros build directly from git these days.

It seems openSUSE does not. I do not know for others.

[bluetech]

It seems openSUSE does not. I do not know for others.

Good to know. I am sure they have support for git, but let's let them know.

---

@DimStar77 If I understand correctly, you are the maintainer of the libxkbcommon package in openSUSE (apologies if not). In the next release, we are planning to drop publishing a tarball, instead instructing distros to build directly from git. The openSUSE package does use the tarball, if you'd have trouble switching, let us know.

[wismill]

@bluetech could you transform the items into checklists? So that we can copy them as a template when creating a release issue/MR.

[bluetech]

Good idea, done.

[bluetech]

Hmm I figure since we're removing the tarballs & sha-256, and git tags are not immutable, we should add the commit hash to the announcement mail. I'll add it to the template.

[whot]

I'm pretty sure most distros build directly from git these days.

ftr, fedora doesn't either. we have copied-everywhere shell scripts to be able to build from git but right now we're using the tarballs.

I suspect the vast majority of distros will simply switch to the github auto-generated tarballs that are created when you create a release here on the repo, e.g. https://github.com/xkbcommon/libxkbcommon/releases/tag/xkbcommon-1.7.0 :)

[wismill]

I suspect the vast majority of distros will simply switch to the github auto-generated tarballs that are created when you create a release

@whot Is it secure though? Can someone mess with these files or does Github ensure their integrity?

[whot]

@whot Is it secure though? Can someone mess with these files or does Github ensure their integrity?

I think you can delete a release and make a new one in which case a new zip file would be generated. The best workaround for this would be to push out the release, generate the sha and then publish that somewhere independently.

I don't think there's an easy-to-exploit way of changing those generated files and we're probably not in the line of projects worth that much effort to take over a tarball :)

[wismill]

LGTM, thanks! Would you like me to take care of the 1.8 release so I can test these instructions?

[bluetech]

Would you like me to take care of the 1.8 release so I can test these instructions?

Sure. You can also go for a release candidate (1.8.0-rc1) if you'd like to test the procedure and maybe get some testing before the main release (I would run my systems on it 😀 ).

[jengelh]

you are the maintainer of the libxkbcommon package in openSUSE (apologies if not). In the next release, we are planning to drop publishing a tarball, instead instructing distros to build directly from git.

No problem. But, for the record, manual tarballs are great because they do not fall victim to https://lwn.net/Articles/921787/ , and there is infrastructure at the distros for detached-file GPG signature verification, which I can't say about signatures tacked onto a git-tag (overcomable I suppose).
Alas, libxkbcommon does not use signatures at all, so…🤷