Re: FYI: vte 0.56.2 + No more ftp tarballs

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

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 <egmont gmail com> 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