On Friday, April 5, 2024 12:04:28 PM CEST Albert Vaca Cintora wrote: > It seems a lot of people feel conservative in favor of tarballs, so > maybe I aimed too far. At least I think the discussion brought some > interesting points that we can explore further. Some I identified: > > - The tarballs should contain no changes with respect to git, or > minimal changes obviously justifiable in a diff.
I would argue that there should be no change at all. Adapting the versions and adding the version to the AppStream file should be done in a git commit and not done in the tarball. This is already done by everyone using releaseme and following the steps from https://community.kde.org/ReleasingSoftware > - Tarballs should only be generated in a reproducible manner using > scripts. Ideally by the CI only. > - We should start to sign tarballs in the CI. I disagree. I want my tarball to be signed with my GPG key stored in my Yubiky and not by a generic KDE key. It should be a proof that I as a maintainer of a project did the release and not someone else. Same with the upload to download.kde.org, while this adds some overhead in the process, I think it is important that KDE Sysadmins are the one who move the tarball to their final location and do some minimal check (checksum match, it's not a random person doing the release, ...). > - We should start to sign commits and tags. Git recently made this > super easy by allowing signing with the ssh keys that we all are > already using to push things, so no excuses for not enabling this. > Sample config below: > > [user] > signingkey = <path to your public key> > [commit] > gpgsign = true > [gpg] > format = ssh > [tag] > forceSignAnnotated = true +1 git tags are already signed for people following the releaseme workflow. Signing commits is also good and I encourage everyone to do it but I wouldn't make it a requirement as it increases the barrier to contribution for new contributors.
signature.asc
Description: This is a digitally signed message part.
