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

[Michael Gratton]

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?


That would also enable having a standard Gitlab CI script for the 
per-module CI which also pulls the config in and does a build based on 
that (much like the one that already exists for for building Flatpak 
manifest), and hence also act as a reminder for maintainers to keep it 
up to date when it fails.


//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Philip Withnall]

On Thu, 2019-09-12 at 19:14 +0100, Emmanuele Bassi wrote:
> On Thu, 12 Sep, 2019 at 19:08, Philip Withnall <
> phi...@tecnocode.co.uk> 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.

> From my perspective, I don't think is much to ask to the community of
> GNOME maintainers to help us on the release team (and all the people
> that build GNOME components) in ensuring their projects actually
> build instead of deploying hopes and prayers to users.

I don’t think anyone is going to begrudge you their time, it’s just the
practicality of having ~30 humans remember to send an e-mail to a list
every time they (infrequently and rarely) touch a particular part of
their code base.

I will endeavour to remember to do so, but I can pretty much guarantee
I’ll forget at some point. I apologise in advance.

Philip
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

[Philip Withnall]

On Thu, 2019-09-12 at 18:54 +0100, Emmanuele Bassi via desktop-devel-
list wrote:
> 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-t...@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).

That sounds like something people are going to forget to do. Would it
be possible to use computers to automate this?

For example, https://gitlab.com/gitlab-org/gitlab-ee/issues/1817

Philip
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Maintainers should announce build-related changes in their modules

[Emmanuele Bassi via desktop-devel-list]

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-t...@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-t...@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

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.34 released

[Matthias Clasen via desktop-devel-list]

On Thu, Sep 12, 2019, 13:14 Matthias C

>
>
> If you are interested in building applications for GNOME 3.34, you can
> use the GNOME 3.34 Flatpak SDK, which is available in the sdk.gnome.org
> repository.
>
>
This was meant to say:

The GNOME 3.34 Flatpak SDK is available on www.flathub.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME 3.34 released

[Matthias Clasen via desktop-devel-list]

The GNOME Project is proud to announce the release of GNOME 3.34,
Θεσσαλονίκη
(Thessaloniki).

This release brings performance improvements in the shell, Drag-And-Drop in
the overview, improved mouse and keybord accessibility, previews in the
background panel, support for systemd user sessions, and more.

Improvements to core GNOME applications include new icons, sandboxed
browsing
in Web, gapless playback in Music, support for bidirectional text in the
Terminal, more featured applications in Software, and more.

For more information about the changes in GNOME 3.34, you can visit
the release notes:

 https://help.gnome.org/misc/release-notes/3.34/

GNOME 3.34 will be available shortly in many distributions. If you want
to try it today, you can use the Fedora 31 beta that will be available soon
or the openSUSE nightly live images which include GNOME 3.34.

 https://www.gnome.org/getting-gnome/

http://download.fedoraproject.org/pub/fedora/linux/development/31/Workstation/x86_64/iso/

http://download.opensuse.org/repositories/GNOME:/Medias/images/iso/?P=GNOME_Next*

To try the very latest developments in GNOME, you can also use Fedora
Silverblue, whose rawhide branch always includes the latest GNOME packages.


https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/compose/Silverblue/x86_64/iso/

If you are interested in building applications for GNOME 3.34, you can
use the GNOME 3.34 Flatpak SDK, which is available in the sdk.gnome.org
repository.

This six-month effort wouldn't have been possible without the whole
GNOME community, made of contributors and friends from all around the
world: developers, designers, documentation writers, usability and
accessibility specialists, translators, maintainers, students, system
administrators, companies, artists, testers and last, but not least,
our users.

GNOME would not exist without all of you. Thank you to everyone!

Our next release, GNOME 3.36, is planned for March 2020. Until then,
enjoy GNOME 3.34!

💓, the GNOME Release Team
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changes: GNOME 3.35/3.36 release schedule

[mcatanzaro]

On Thu, Sep 12, 2019 at 8:22 AM, Bastien Nocera  
wrote:

This is very important for the maintainers of libraries that live in
the GNOME runtime. Do we have a full list of those? What happens if
there are security issues that crop up in the meanwhile?


Security issues that crop up in the meanwhile will be fixed in the next 
runtime update, *if* the issue is in a tarball that's updated by our 
release scripts and the module is flagged for such updates. All GNOME 
stuff should be included, as should freedesktop stuff that uploads 
tarballs outside GitLab. GitLab/GitHub-hosted tarballs require manual 
updates and thus are not updated.


Keep in mind there is no GNOME security team. Or, to the extent that 
there is a GNOME security team, it's myself and Tobi spending five 
minutes per vulnerability to ensure project maintainers know they're on 
their own. :P And there is currently no human watching for security 
issues or handling security advisories anyway. That's why I'm still not 
entirely comfortable with Epiphany returning to Flathub at this time.


So, status quo is not good. But this will still be better than we've 
ever had before, because until now we've had no scheduled runtime 
rebuilds at all after the .2 stable release.


Of course, you can always manually propose updates to specific packages 
in gnome-build-meta whenever you want. That's what I do for WebKit 
updates, for example. The schedule only shows when release-team will 
get around to doing it for you. So if you have a particular issue that 
you think shouldn't wait until the next scheduled update, go ahead and 
propose a merge request to gnome-build-meta.


Michael


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changes: GNOME 3.35/3.36 release schedule

[Bastien Nocera]

On Thu, 2019-09-12 at 08:19 -0500, mcatanz...@gnome.org wrote:
> On Thu, Sep 12, 2019 at 2:45 AM, Milan Crha via desktop-devel-list 
>  wrote:
> > As a real life example, I skipped 3.32.5 this year, because there
> > was
> > no code change in the stable branch with which the users could 
> > benefit.
> > The late stables are for bug fixes, from my point of view.
> 
> I wondered about how to best present that on the schedule.
> 
> We don't actually expect you to release tarballs past 3.34.0 unless
> you 
> have actual need to do so (bugfixes that need released). These are
> more 
> informational deadlines so that you know when our runtime updates
> will 
> occur.
> 
> E.g. say you release 3.34.0 on time, then by some magic nobody
> reports 
> any bugs in evolution-data-server for four months. (Wouldn't that be 
> nice?) We make it to February and finally you have some fixes that
> you 
> want to release. If you release your 3.34.1 by the tarball deadline
> for 
> 3.34.5, then your 3.34.1 will make it into the 3.34.5 runtime update 
> during the next week. Otherwise it might wait six weeks until the 
> 3.34.6 runtime update. (We'll be doing 3.34 releases until March
> next 
> year, because the runtime will be supported for one year. This
> schedule 
> only shows the first half of the 3.34 lifetime.)

This is very important for the maintainers of libraries that live in
the GNOME runtime. Do we have a full list of those? What happens if
there are security issues that crop up in the meanwhile?

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changes: GNOME 3.35/3.36 release schedule

[mcatanzaro]

On Thu, Sep 12, 2019 at 2:45 AM, Milan Crha via desktop-devel-list 
 wrote:

As a real life example, I skipped 3.32.5 this year, because there was
no code change in the stable branch with which the users could 
benefit.

The late stables are for bug fixes, from my point of view.


I wondered about how to best present that on the schedule.

We don't actually expect you to release tarballs past 3.34.0 unless you 
have actual need to do so (bugfixes that need released). These are more 
informational deadlines so that you know when our runtime updates will 
occur.


E.g. say you release 3.34.0 on time, then by some magic nobody reports 
any bugs in evolution-data-server for four months. (Wouldn't that be 
nice?) We make it to February and finally you have some fixes that you 
want to release. If you release your 3.34.1 by the tarball deadline for 
3.34.5, then your 3.34.1 will make it into the 3.34.5 runtime update 
during the next week. Otherwise it might wait six weeks until the 
3.34.6 runtime update. (We'll be doing 3.34 releases until March next 
year, because the runtime will be supported for one year. This schedule 
only shows the first half of the 3.34 lifetime.)


Michael


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Changes: GNOME 3.35/3.36 release schedule

[Milan Crha via desktop-devel-list]

On Wed, 2019-09-11 at 14:09 +0200, Andre Klapper wrote:
> * Stable maintenance releases over a longer period

Hi,
does it make sense to have 3.34.5 at the time of 3.36.1? I guess not
for majority of the projects. Even if it would be a soft requirement,
it happens that the stable branch doesn't get that much attention after
the first half, like after 3.x.2. I do not tell it, because previous
schedules ended with 3.x.2, I released up to 3.x.5, which was usually
aligned with 3.x+1.90 release. I do not think forcing even soft
requirement for more stable releases make any sense, if the maintainers
would like to give users more fixes in the current stable version, they
are already doing it. There are projects which do that, even for older
stable releases, but it's a real minority.

As a real life example, I skipped 3.32.5 this year, because there was
no code change in the stable branch with which the users could benefit.
The late stables are for bug fixes, from my point of view.

Just my opinion and experience from the past years.
Bye,
Milan

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list