Re: FYI: vte 0.56.2 + No more ftp tarballs

I think for the time being, the practical consequence is that we'll no longer update vte in our flatpak runtimes, until we make changes to our release infrastructure to support this. (Which we've been considering doing for a long time anyway; we seem to have consensus that in the long term we'd like to move to using git tags instead of tarballs.) Anyway, we're not there yet, and we won't spend special effort to handle vte and gnome-terminal manually.

The recommended way to generate tarballs with meson is 'meson dist'. It is much easier than with autotools.

On Thu, Apr 25, 2019 at 11:54 PM, Tristan Van Berkom via release-team <release-team gnome org> wrote:
  * If I understand correctly, I might be wrong, but I think gitlab
    creates tarballs on the fly instead of persisting them in

    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.

This has actually caused problems for release team in the past with GitHub tarballs, because the checksums for "old" tarballs actually have changed on us before when GitHub changes how tarballs are compressed. So with GitHub, the autogenerated tarballs are sadly not suitable for use as releases. But you can still separately upload a stable tarball for your releases that will appear on the releases page. That requires extra work, of course.

I'm not sure about the situation with GitLab, but I assume it is similar.

This sounds like a good idea. In particular, to address all the
worries you listed above, I think the easiest and safest short-term
solution would be to create a script which automatically fetches the
tarballs from git for newly appearing tags (for specified versions
only, e.g. vte >= 0.57.0), and pushes them to the FTP area via a
scripted "ftpadmin install" or alike. Does it sound feasible?

I think we should discuss with release-team regarding the best technical path forward; ideally that would not involve adding news steps to the release process.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]