On 9 February 2018 at 14:36, Bastien Nocera <had...@hadess.net> wrote: > On Thu, 2018-02-08 at 13:57 -0600, mcatanz...@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] _______________________________________________ desktop-devel-list mailing list email@example.com https://mail.gnome.org/mailman/listinfo/desktop-devel-list