Re: 3.27.90 tarball deadline extended

[mcatanzaro]

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

[mcatanzaro]

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

[Emmanuele Bassi]

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

[Bastien Nocera]

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

[Milan Crha]

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

[mcatanzaro]

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

[mcatanzaro]

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

[mcatanzaro]

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