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: [GitLab] Projects moved, tips of the week and question of the week

[Alberts Muktupāvels]

On Thu, Feb 8, 2018 at 8:47 PM, Olav Vitters  wrote:

> I assume Gitlab has some API to show the available repositories. As
> such, script is only thing which needs to change.
>

https://gitlab.gnome.org/Infrastructure/sysadmin-bin/merge_requests/3

Quick test shows that it works, but it must be checked by someone who knows
python and/or gitlab api better then me.

-- 
Alberts Muktupāvels
___
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: Planned MAJOR OUTAGE: Thursday 08th of February, 17:00 - 19:00 UTC

[Andrea Veri]

While the move was overall successful one of the hosts has been found
having an hardware failure and requires its mainboard to be replaced.
The part will be replaced today between 14 - 15 UTC. The affected
services that will have a downtime are:

bugzilla.gnome.org
paste.gnome.org
etherpad.gnome.org
id.gnome.org
opw.gnome.org

Thanks,

2018-02-05 12:04 GMT+01:00 Andrea Veri :
> Hi,
>
> this upcoming Thursday we'll be performing a rack migration for *all*
> the GNOME Infrastructure machines hosted in PHX2, the services that
> will see a one to two hours downtime are:
>
> wiki.gnome.org
> smtp.gnome.org
> mail.gnome.org
> git.gnome.org
> gitlab.gnome.org
> bugzilla.gnome.org
> www.gnome.org
> extensions.gnome.org
> sdk.gnome.org
> cloud.gnome.org
> pentagon.gimp.org (hosting all GIMP/GTK main websites)
> paste.gnome.org
> download.gnome.org
> blogs.gnome.org
> master.gnome.org
> jabber.gnome.org
> help.gnome.org
> developer.gnome.org
> planet*.gnome.*
> vote.gnome.org
> api.gnome.org
> *.guadec.org
>
>
> The GNOME Infrastructure team and Red Hat NOC will make sure the
> downtime will be minimized as much as possible. Once the machines have
> been migrated we'll move forward with service validations. As usual
> please keep an eye at [1] for status updates.
>
> Thanks!
>
> [1] https://status.gnome.org
>
>
> --
> Cheers,
>
> Andrea
>
> Red Hatter,
> Fedora / EPEL packager,
> GNOME Infrastructure Team Coordinator,
> Former GNOME Foundation Board of Directors Secretary,
> GNOME Foundation Membership & Elections Committee Chairman
>
> Homepage: http://www.gnome.org/~av



-- 
Cheers,

Andrea

Red Hatter,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
Former GNOME Foundation Board of Directors Secretary,
GNOME Foundation Membership & Elections Committee Chairman

Homepage: http://www.gnome.org/~av
___
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