Re: 3.27.90 tarball deadline extended
On Fri, Feb 9, 2018 at 8:36 AM, Bastien Nocera wrote: 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. To be clear, we're not asking for that. You can use whatever tool you want. JHBuild was previously the easiest way to generate a release tarball for GNOME. Now we intend for BuildStream to fulfill that role. So, going forward, it will be our recommendation to use it. But you certainly don't have to. It's just a tool, after all. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
On Fri, Feb 9, 2018 at 9:14 AM, Emmanuele Bassi wrote: 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. Yes, this! Milan, feel free to do the .91 release whenever you want. Or you could do it now and call it .90.5, or whatever you want to call it. The delay seemed appropriate because, having advised maintainers to switch from JHBuild to BuildStream, but not having any way to generate release tarballs with BuildStream, was not a friendly situation for maintainers. I had provided guidance that was not possible to follow. I know you're used to releasing without using JHBuild, but that can be difficult, and anyone who relies on JHBuild to make releases and followed our advice to stop doing so would have been stuck. Hence, some extra time to figure out what we were doing was needed. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
On 9 February 2018 at 14:36, Bastien Nocera 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 desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
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. > if your module has > dependencies that can't be satisfied by your host system. Even though > the release team is no longer maintaining JHBuild, you can make > whatever changes to the modulesets you need, and I believe that it is > still the easiest way to generate your release tarballs at this time. gnome-control-center requires a newer version of gnome-desktop, which has usually been released by the release-team on the day of the tarball deadline. gnome-settings-daemon requires a new version of gnome-session which hasn't been released yet. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
On Thu, 2018-02-08 at 13:57 -0600, mcatanz...@gnome.org wrote: > Due to this delay, we will skip the 3.27.91 release altogether, so > the next tarball deadline will be 3.27.92, on March 5. Perhaps by > then we will be able to recommend using BuildStream for tarball > generation. Hi, is it a good idea? I know that 3.27.90 release of some of the products I care of has issues which I promised to fix in 3.27.91, not longer than two weeks after 3.27.90, as the GNOME schedule says. Nobody forces me to not do the release, I know. I understood that *the release team* has some trouble with tarballs, but I do not understand why it should be such a big deal for everyone else. There had been ways to generate tarballs a month ago, and it didn't change. Not that significantly during that single month. Why to postpone anything *for the rest of the world* in this transition period? What I also do not understand is that release team should not generate any tarballs, it's the developer's duty (I know, I know, the practice is sometimes somewhat different, but anyway). You want to use BuildStream, you are in the transition period, but it doesn't mean that everything freezes, it shouldn't mean that you have no backup plan if anything breaks. That's the transition period, it's expected to face bugs and issues. I understood that BuildStream is a *recommended* way of developing for GNOME, the same as jhbuild was a *recommended* way of the same. I do not use either of them. I'm able to create release tarballs for the products I care of. Thus, from my point of view, as long as developers can create tarballs and release them, and as long as the release team is able to validate these tarballs, then there is no need to postpone anything. The worst the BuildStream "exclusive" usage would be postponed, but not the release of GNOME. Again, transition period, bugs expected, and so on. Everything makes sense. Just my opinion. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
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, if your module has dependencies that can't be satisfied by your host system. Even though the release team is no longer maintaining JHBuild, you can make whatever changes to the modulesets you need, and I believe that it is still the easiest way to generate your release tarballs at this time. The final tarball deadline for 3.27.90 will be Monday, February 12. Our release deliverable will still be a BuildStream project: that has not changed. Due to this delay, we will skip the 3.27.91 release altogether, so the next tarball deadline will be 3.27.92, on March 5. Perhaps by then we will be able to recommend using BuildStream for tarball generation. Thanks very much for your patience during this transition period. Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
On Mon, Feb 5, 2018 at 11:59 AM, mcatanz...@gnome.org wrote: The release team is still learning how to get by in a BuildStream world. It turns out that nobody who is currently available knows how to generate release tarballs using BuildStream. Hi developers, An update on this. With some help from Mathieu and Jürg, we've figured out how to generate tarballs. You need to use a combination of `bst workspace open` and `bst shell --build`. Then once you enter the bst shell, you can generate a tarball normally (mkdir build; cd build; meson ..; ninja; ninja dist) and it will be generated in the workspace. This is actually pretty simple; I had gotten confused earlier today because I had forgotten the --build flag to `bst shell`. Unfortunately, I discovered a bug that's a blocker for Epiphany [1], so it might not work for you in practice. We'll evaluate later this week whether we'll need to recommend switching back to JHBuild to generate tarballs for the time being, or whether we can get this working reliably. Thanks for your patience, Michael [1] https://gitlab.com/BuildStream/buildstream/issues/232 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.27.90 tarball deadline extended
Hi developers, TL;DR: the 3.27.90 tarball deadline is extended until next Monday The release team is still learning how to get by in a BuildStream world. It turns out that nobody who is currently available knows how to generate release tarballs using BuildStream. Many developers, notably Tristan, are traveling from FOSDEM and unavailable at the moment. I've been discussing with Javier, and we're both kind of lost as to what to do. If you've already released a tarball, you must have done so either using host dependencies, which doesn't work for modules that depend on new stuff, or with JHBuild. We think it's important to actually be able to release all modules without using JHBuild, and we'll need a couple days to figure this out, and you all surely deserve at least one weekend after that before tarballs are due, so let's extend the 3.27.90 tarball deadline until at least next Monday. Expect more development schedule change announcements as we figure out what we're doing. Thanks for your patience throughout this big transition, Michael ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list