Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

On Thu, 12 Sep 2019 at 22:40, Philip Withnall 
wrote:

> On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
>
> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall 
> wrote:
>
> That sounds like something people are going to forget to do. Would it be
> possible to use computers to automate this?
>
>
> It's software: anything is possible.
>
> As to whether we can automate this **right now**, the answer is: no.
>
> I'm not going to block on a feature that may or may not appear in Gitlab's
> enterprise edition and then may or may not be backported to the community
> edition we have. Of course, enterprising hackers are strongly encouraged to
> work on that.
>
>
> The link to the GitLab EE issue was illustrative, not definitive. If it
> solves the problem, a cronjob which polls every module’s `/meson.build` and
> `/meson_options.txt` files every 30 minutes and uses sendmail to send you
> an e-mail about changes would work.
>
>
If you're volunteering to write that script, make it work for Autotools and
CMake, then feel free.

Of course, a script polling your meson.build files doesn't help us in the
slightest when you add a dependency on libfoobar, hosted on a random
repository on GitHub, from a specific tag or branch, but only built with a
set of specific options because you rely on an optional feature.

Not every single problem we have in building a complex project like GNOME
can be solved by a script; if it were, we wouldn't need maintainers, and
y'all would have been replaced by a script already.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

On Thu, 12 Sep 2019 at 23:49, Michael Gratton  wrote:

> On Thu, 12 Sep, 2019 at 22:39, Philip Withnall 
> wrote:
> > On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
> >> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall
> >>  wrote:
> >>> That sounds like something people are going to forget to do. Would
> >>> it be possible to use computers to automate this?
> >>
> >> It's software: anything is possible.
> >>
> >> As to whether we can automate this **right now**, the answer is: no.
>
> It's a shame that build deps can't be picked up automatically from the
> meson build config, where it's already specified.
>
> What about requiring modules include a buildstream config fragment with
> a well-known name in their repos, much like how DOAP files are
> required, which then gets pulled in by the release team's CI?
>

If maintainers want to be responsible for their own module's BuildStream
recipe, by all means: submit MRs to gnome-build-meta.

Adding a BuildStream recipe in your repo doesn't solve anything, though.

 1. BuildStream is an implementation detail of how we build the GNOME SDK
and releases
 2. Applications already have their own build system, a CI configuration,
and a flatpak builder manifest; adding yet another place, with a completely
different syntax and semantics where your dependencies are listed is a
recipe for maintainers just not doing this work
 3. GNOME releases are built out of gnome-build-meta; distributing the
BuildStream recipes isn't going to fix broken builds in gnome-build-meta

Let's not overengineer ourselves out of sending an email.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via release-team]

Hi all;

the 3.34 release is out of the door, but before we go into the 3.35 
development cycle, the release team would like to kindly ask **all** 
GNOME maintainers to send an email to release-team@gnome.org 
 (and possibly Cc: 
distributor-l...@gnome.org ) every 
time their project(s) introduce a new dependency, or update the version 
requirement of existing dependencies, or change the build options of 
their project(s).


The announcement is especially important for dependencies hosted 
outside of gitlab.gnome.org.


## How does an announcement look like?

A simple email sent to release-team@gnome.org 
 will suffice.


If you added or updated a dependency, please specify:

- the name of the dependency
- the minimum required version of the dependency
- the build options of the dependency your project requires
- the source code repository of the dependency and the branch/tag to 
be used -OR-
- the location of the release archive, possibly with the size and 
SHA256 checksum of the release


If you changed a build option:

- the name of the old and new build option
- whether it's automatically enabled or disabled based on a dependency

As a friendly notice to the downstream distributors of GNOME modules, 
you may also want to Cc: distributor-l...@gnome.org 
.


## Why is this necessary?

GNOME releases are built from [gnome-build-meta][1] recipes; if a build 
option is changed, a new dependency is introduced, or if a minimum 
requirement gets updated, the build will fail until the recipe is 
updated; and, in the case of new dependencies, until a new recipe for 
the dependency is written and tested.


Failed builds block everything:

- the CD pipeline that generates the Flatpak run times for CI
- the release pipeline
- in the future, it'll also block the build of installable VMs for 
design, QA, and user testing


This means that a broken build is going to make the life of everyone 
else in the project harder.


As builds take a lot of time to complete, it might happen that the 
breakage introduced by a new dependency will go unnoticed for a while; 
on top of that, it requires the release team to go and hunt down the 
dependencies repositories, tarballs, or release archives, and figure 
out the build options your own project depends on.


## I already have to update the CI, I might forget to send an email

It's understandable: we do have a large infrastructure, so it might 
happen that you forget something. Ideally, if you're updating your 
custom CI, you're also going to have time to send a very short email to 
a mailing list.


## Can I update gnome-build-meta myself?

Of course! Open a [new merge request][2] against gnome-build-meta, and 
the release team will be happy to review it and merge it.


## Is this mandatory?

Currently, we want to be flexible with maintainers, so this requirement 
is not going to be enforced; this is also why it's an *announcement*.


If builds keep breaking during 3.35 because of new/updated 
dependencies, the release-team might start considering something more 
binding, like pinning modules to previously released tags/versions; if 
that proves to be impossible due to module interdependencies, we might 
very well end up reverting commits in the offending module(s).


On behalf of the release team,
Emmanuele.

[1]: 
[2]: 
W: https://www.bassi.io

___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: String/UI Freeze Break (#2) - totem

[Emmanuele Bassi via release-team]

On Tue, 26 Feb 2019 at 15:32, Bastien Nocera  wrote:

> On Mon, 2019-02-25 at 13:52 +0100, Piotr Drąg wrote:
> > pon., 25 lut 2019 o 13:44 Bastien Nocera 
> > napisał(a):
> > > Hey,
> > >
> > > This removes some UI which isn't connected to anything anymore.
> > > There
> > > aren't any screenshots in the user documentation, and the removed
> > > paragraph would automatically be dropped from user docs
> > > translations:
> > > https://gitlab.gnome.org/GNOME/totem/merge_requests/79
> > >
> >
> > It doesn’t break the string freeze, but thanks a lot for the
> > notification!
>
> Could the release team weigh in with some feedback, please?
>

Looks very low impact, so +1 from me (r-t).

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[Emmanuele Bassi via release-team]

Thank you for the clarification; in one of the issues you linked I saw the
error screen with a GDBus blurb and I got worried. :-)

It's +1 from me (release-team).

Ciao,
 Emmanuele.

On Fri, 8 Feb 2019 at 16:43, Jean Felder  wrote:

>
>
> Le ven. 8 févr. 2019 à 12:16, Emmanuele Bassi  a écrit :
>
>> Are we really showing a GDBus error message in a landing screen aimed at
>> newcomers? Because that would be an immediate -1 from me.
>>
>
> Hi Emmanuele,
>
> This is not GDBus related. This landing screen is only visible if Tracker
> is not installed on the host system.
>
> Jean
>
>
>
>>
>> Ciao,
>>  Emmanuele.
>>
>> On Fri, 8 Feb 2019 at 11:08, Daniel Mustieles García via gnome-i18n <
>> gnome-i...@gnome.org> wrote:
>>
>>> Early in the freeze, so 1/2 from i18n.
>>>
>>> Thanks!
>>>
>>> El vie., 8 feb. 2019 a las 11:40, Jean Felder ()
>>> escribió:
>>>
 Hi,

 I would like to ask for a freeze break request to introduce a new empty
 view when Tracker is not available [1].
 This is a long standing issue for newcomers who want to contribute to
 Music using flatpak without tracker installed (for example, Tracker is not
 installed by default on Ubuntu).
 Without this view, these users will see an "music library not avaiable"
 message, which is quite misleading.
 Besides, Photos introduced a similar view [2] during this cycle. So,
 this would provide some consistency between two core applications.

 This feature has not been introduced before the freeze because of some
 lack of avaibility of both maintainers (Marinus Schraal and myself).
 Finally, it introduces two new strings.


 [1] https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335
 [2] https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85

 Regards,
 Jean
 ___
 release-team@gnome.org
 https://mail.gnome.org/mailman/listinfo/release-team
 Release-team lurker? Do NOT participate in discussions.
>>>
>>> ___
>>> gnome-i18n mailing list
>>> gnome-i...@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>>>
>>
>>
>> --
>> https://www.bassi.io
>> [@] ebassi [@gmail.com]
>>
>

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: GNOME Music freeze break request

[Emmanuele Bassi via release-team]

Are we really showing a GDBus error message in a landing screen aimed at
newcomers? Because that would be an immediate -1 from me.

Ciao,
 Emmanuele.

On Fri, 8 Feb 2019 at 11:08, Daniel Mustieles García via gnome-i18n <
gnome-i...@gnome.org> wrote:

> Early in the freeze, so 1/2 from i18n.
>
> Thanks!
>
> El vie., 8 feb. 2019 a las 11:40, Jean Felder ()
> escribió:
>
>> Hi,
>>
>> I would like to ask for a freeze break request to introduce a new empty
>> view when Tracker is not available [1].
>> This is a long standing issue for newcomers who want to contribute to
>> Music using flatpak without tracker installed (for example, Tracker is not
>> installed by default on Ubuntu).
>> Without this view, these users will see an "music library not avaiable"
>> message, which is quite misleading.
>> Besides, Photos introduced a similar view [2] during this cycle. So, this
>> would provide some consistency between two core applications.
>>
>> This feature has not been introduced before the freeze because of some
>> lack of avaibility of both maintainers (Marinus Schraal and myself).
>> Finally, it introduces two new strings.
>>
>>
>> [1] https://gitlab.gnome.org/GNOME/gnome-music/merge_requests/335
>> [2] https://gitlab.gnome.org/GNOME/gnome-photos/merge_requests/85
>>
>> Regards,
>> Jean
>> ___
>> release-team@gnome.org
>> https://mail.gnome.org/mailman/listinfo/release-team
>> Release-team lurker? Do NOT participate in discussions.
>
> ___
> gnome-i18n mailing list
> gnome-i...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-i18n
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Freeze break request for gnome-shell

[Emmanuele Bassi via release-team]

With 24 hours to go from the cut off deadline for 3.30, I don’t think this
is a good idea; this can wait for 3.30.1, and might as well use the
appropriate fix. Most distros will ship that version anyway.

Ciao,
 Emmanuele.

On Sun, 2 Sep 2018 at 17:13, verdre  wrote:

> I have an alternative solution which would be more compatible with
> changes we'll make in the future, could this one also get an approval?
>
> It's even less intrusive than the other one since there's no need to
> stop initially hiding the label.
>
> https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/215
>
> Thank you,
> verdre
>
> On 02.09.2018 02:37, mcatanz...@gnome.org wrote:
> >
> > I'll give a hesitant +1 to this one, since the change is small.
> >
> > If you consider it important enough for a 3.30.0 freeze break, rather
> > than waiting three weeks for 3.30.1, then it should also important
> > enough to backport to 3.28. It would be nice to see this fixed there too.
> >
> > Thanks for solving it,
> >
> > Michael
> >
> ___
> release-team@gnome.org
> https://mail.gnome.org/mailman/listinfo/release-team
> Release-team lurker? Do NOT participate in discussions.
>
-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.

Re: Logo Proposal for GNOME 4 (2020)

[Emmanuele Bassi via release-team]

Hi;

I honestly don't understand what this means. What's "GNOME 4"? Why "2020"?
What's "gingerblue"? What is this logo for?

Additionally, you keep "releasing" tarballs of "gingerblue" on
download.gnome.org, and every time you do, you're sending emails to the
release team; but all those releases are done every couple of (barely
functional) commits on your personal repository. There's no description of
what the project you're releasing is, or does, outside of "Gingerblue is
Free Music Software for GNOME" in your README, but you definitely should
not keep releasing things every time you add a file, or you rename it.

I don't know what you're trying to achieve, but right now you're just
spamming the GNOME infrastructure, so I'd kindly request you stop and
consider what you're doing.

Ciao,
 Emmanuele.

On Sat, 28 Jul 2018 at 19:03, Ole Aamot  wrote:

> Logo Proposal for GNOME 4 (2020)
>
> https://www.gnome.org/~ole/gingerblue-gnome-gtk-gnu.png
> https://www.gnome.org/~ole/gingerblue-gnome-gtk-gnu.svg
>
> Happy hacking,
> Ole Aamot
> ___
> gnome-announce-list mailing list
> gnome-announce-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-announce-list
>


-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
release-team@gnome.org
https://mail.gnome.org/mailman/listinfo/release-team
Release-team lurker? Do NOT participate in discussions.