Re: 3.27.90 tarball deadline extended

[Emmanuele Bassi <ebassi gmail com>]

On 9 February 2018 at 14:36, Bastien Nocera <hadess hadess net> wrote:
> On Thu, 2018-02-08 at 13:57 -0600, mcatanzaro gnome org wrote:
> > Hi developers,
> >
> > We're getting closer, but we're not yet at a point where we can
> > recommend that you try generating release tarballs with BuildStream and
> > expect it to work. So I have to reluctantly recommend that you use
> > JHBuild to generate your 3.27.90 release tarballs,
>
> FWIW, I don't see any reason why individual maintainers are being asked
> to use this particular tool to create tarballs.
>
> It was clear from the earlier mails that the release-team would be
> using BuildStream, it really wasn't explicit that the developers and
> maintainers of individual modules were also being asked that.

Yes, that was also what I understood from the announcement and the
discussions around the adoption of buildstream.

The only thing that maintainers should be required to do is to ensure
that the build instructions and dependencies for their modules are
kept up to date; we currently have three different places for that
information, using vastly different formats:

 - jhbuild modulesets
 - the Continuous manifest
 - the GNOME SDK flatpak manifest

The assumption was that buildstream would provide a single source for
the build description format, and we'd either generate the other
formats from buildstream recipes, or we would use buildstream
directly. Buildstream is in the process of generating the Flatpak run
time for the Freedesktop SDK, and I assume it'll start getting used
for the GNOME SDK as well, at some point. Continuous will switch to
Buildstream as soon as we can build OS images (and VMs) that can be
upgraded via OSTree. The release team is going to switch to
Buildstream as well, as soon as the various identified issues are
resolved.

Whatever maintainers use to build release tarballs is fine — as long
as you ensure that you're always keeping the build of the whole GNOME
set of modules running.

Ideally, in the jetpacks and flying cars future, generating release
tarballs is going to be automated through CI, so that we won't really
need maintainers to deal with that, and we can still provide
downstream projects with release artefacts for their own purposes.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]