Hi, Thanks for bringing this up.
On Thu, 2019-04-25 at 17:08 +0200, Debarshi Ray via release-team wrote: > Hey Egmont, > > Thanks for the heads up! > > > On Thu, Apr 25, 2019 at 11:59 AM Egmont Koblinger <[email protected]> wrote: > > - VTE 0.56.2 was released ahead of schedule in order to fix a crash > > (RH #1701590). Could you please update the Rawhide (F30) package? (F29 > > with VTE 0.54.x is unaffected.) > > > > - VTE git master (0.57 series) switched to the meson build system and > > dropped autotools. Since there are no longer any autogenerated files > > to distribute, we will no longer manually create tarballs and upload > > them to the static ftp/http download area. Instead, you should check > > out particular tags from git, or download the autogenerated tarballs > > > > from gitlab at https://gitlab.gnome.org/GNOME/vte/tags. > > (gnome-terminal is likely to follow soon, I won't send a separate FYI, > > you'll notice it when it happens.) > > I guess I could live with downloading the autogenerated GitLab > tarballs for the purposes of building Fedora packages. I wonder if > this has a bearing on how the GNOME release team builds things to > prepare the upstream GNOME releases. I have CC'ed them. First of all, I think this is certainty a freedom that we want maintainers to have, avoiding steps and process just makes things better. For the technical part of creating a GNOME release, I don't think we're quite ready for that at the moment, but I it should not be too much work to update the script which converts `gnome-build-meta` to be aware of modules which don't release as tarballs here: https://gitlab.gnome.org/GNOME/releng/blob/master/tools/smoketesting/convert-to-tarballs.py Also, I'm not familiar with how release notes for major GNOME releases are currently created, but I *think* there is a NEWS file aggregation script which is based on the uploaded tarballs, that should probably receive some attention too. However there are other concerns than just this. * I think our gitlab instance is not really an appropriate infrastructure for hosting releases; when compared to the ftp server which has mirrors to help balance the load. This might result in intense CI pipelines for builds of downstream distros running around the world, continuously trying to download our modules directly from our poor little gitlab instance. * If I understand correctly, I might be wrong, but I think gitlab creates tarballs on the fly instead of persisting them in permanence. I raise this because I don't know with certainty that gitlab tarball creation is reproducible (in the bit-for-bit sense). This could mean that an upgrade of our gitlab or it's dependencies, can potentially result in the same tarballs being offered up but no longer matching the checksums as before. I wonder if we might prefer an approach where we automate the creation of tarballs for modules who have decided to rid themselves of the process of creating tarballs ? Cheers, -Tristan _______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
