Re: Moving final mailman lists over to discourse

[Emmanuele Bassi via desktop-devel-list]

On Sun, 30 Oct 2022 at 18:45, Anastasios Lisgaras via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> On 10/20/22 20:48, Andre Klapper via desktop-devel-list wrote:
> > On Thu, 2022-09-29 at 16:48 +0100, Neil McGovern wrote:
> > Are there plans to update the https://mail.gnome.org frontpage to link
> > to Discourse, and put redirects in place
> > for https://mail.gnome.org/mailman/listinfo/* URLs?
> > The last section on https://mail.gnome.org has two broken links.
> >
> > Looking at Git repo content under GNOME, there are a lot of outdated
> > mailing list links in DOAP files and documentation pages to update:
> >
> > $:ac\> grep -r --include=*.page "mail.gnome.org" . | wc -l
> > 44
> > $:ac\> grep -r --include=*.xml "mail.gnome.org" . | wc -l
> > 24
> > $:ac\> grep -r --include=*.doap "mail.gnome.org" . | wc -l
> > 170
> >
> > andre
>
> It would be a *great idea* if we want to retire mailing lists to have
> information about where that mailing list is now in Discourse.
>

There is no 1:1 mapping between mailing lists and Discourse, because
Discourse is not a mailing list server.

Generally, you'll use tags, but those tags may not exist yet. It's up to
the people maintaining the DOAP and documentation pages to ask for a tag,
if it doesn't exist.

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: Is libgd still a thing?

[Emmanuele Bassi via desktop-devel-list]

Looking at the gnome-world moduleset, the following modules are still using
libgd:

 - nautilus
 - evince
 - totem
 - gnome-photos
 - gedit

Archiving libgd will likely have to wait, considering that all of these are
core GNOME applications.

Ciao,
 Emmanuele.

On Mon, 14 Jun 2021 at 17:19, Andre Klapper via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> https://gitlab.gnome.org/GNOME/libgd/commits/master hasn't seen changes
> for 30 months. Emails to both maintainer addresses listed in the DOAP
> file ({cosimoc|malureau}@gnome.org) bounced.
>
> Context: Wondering whether to archive; coming from Bugzilla migration.
>
> Thanks,
> andre
> --
> Andre Klapper  |  ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>


-- 
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: Can we enforce beta release for the freeze

[Emmanuele Bassi via desktop-devel-list]

On Mon, 22 Feb 2021 at 00:20, Shaun McCance  wrote:


> What I want is a discussion on how we can ensure beta releases happen in
> the future. For example, can we do more to automate releases? Or (again,
> for example), could we have an automated script that emails this list with
> modules missing beta releases? Then even if releases are missed, people
> like me would at least know what to expect from the beta.
>

"Automating releases" is a vast topic.

In theory, we could simply ask maintainers to upload a (signed) tag to
GitLab, and then our tools would be able to deal with that—of course, that
requires some process change and some tool change from the release team
perspective, but we've been trying to get towards that goal for a while
now. That would get rid of the "upload a dist tarball to gnome.org" step,
which is, frankly, the least involved step. We'd still require maintainers
to run dist as part of the release checklist because otherwise how are they
going to tag a release in the first place?

Of course, we *should* also rely on CI to ensure that a `dist` operation
always passes on the main development branch; it would be good to have a
project-wide CI rule that runs the dist on a schedule, but maintainers can
do this *today* in their projects.

In the end, though, releases are manual labour; only the maintainer can
say: "okay, this is good enough for other people to use" (where "people"
defines different audiences depending on the stage of the development
cycle). No amount of automation is going to solve that because if it did we
would not need per-project maintainers in the first place, and we would
only need people reviewing code and pressing the "Merge" green button.

The delay on this beta release was caused by the fact that we have a
shortage of maintainers, and too few people in key positions. This issue
can only be solved by having redundancies in the *human* pipeline.
Maintainers: *please*, mentor contributors to pick up the release process.
Document what you do, and give out release duties to other people at least
once per cycle, if you can.

The release team can do "non maintainer" releases, of course; the problem
is, of course, that maintainers can be *very* protective of their fiefdoms,
so the release team has to wait for either being explicitly asked to do a
release, or for an answer from maintainers as to whether they'll be able to
do a release. We *cannot* have it both ways: either the release team can
take over your project for a specific task—do a release, keep the build
running—or we have to wait until we get an answer from the maintainer.

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: Let's improve our communication: Discourse

[Emmanuele Bassi via desktop-devel-list]

On Tue, 29 Sep 2020 at 10:25, Milan Crha via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> On Fri, 2020-09-25 at 14:33 -0500, Michael Catanzaro wrote:
> > and make contributing to GNOME more attractive to newcomers.
>
> Hi,
> do you think the newcomers do not know how the mail works? Or it's used
> as an excuse to replace something working for years with something new,
> with new bugs, its maintenance requests and such? Just wondering.
>

You're making a simple and understandable mistake, here: email is one
thing, mailing lists are another. The two should not be conflated.

To be more specific, mailing lists have terrible signal-to-noise ratio, and
terrible moderation tools. Both issues have a definite impact on newcomers,
as well as veterans of a project; the amount of people actively engaging on
mailing lists in the GNOME project has been trending down over the past
decade or so, compared to the early 2000s—and we were complaining about
decreased SNR even back then. For a newcomer, mailing lists are hard to
search in, and hard to contribute to; for long time contributors, mailing
lists are mostly noise.

Discourse is an attempt at solving the issue; it's much more effective at
managing signal-to-noise ratio, because on Discourse you can explicitly tag
topics; split them and merge them at any point in time; re-tag and
re-categorise topics; and all the history is preserved, instead of leaving
trails of threads around different lists that are, effectively impossible
to follow. Additionally, its moderation tools are based on a bottom-up
approach, instead of having a selected list of people that have to edit the
content. The longer you use Discourse (from its web UI), the more you are
"trusted"; and the more you are trusted, the more access you have, and the
more you're entrusted with moderating and curating the community. Topics,
posts, and users can be easily flagged for moderation, and anti-spam
measures are much more effective.

There's also an infrastructure side of things, which cannot be discounted:
large mailing lists are virtually indistinguishable from spam, in the eyes
of the people who own mail servers; currently, we're operating a large set
of mailing lists by asking to be whitelisted in the various anti-spam
systems, but we're always one bug or one bad day away from the whole house
of cards crashing down. This is not the '90s any more. Discourse is a web
application that runs inside its own container; it's mostly easy to deploy,
and since it's maintained, it gets updated fairly often; from a sysadmin
perspective, it's well-integrated in our infrastructure.

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

New GNOME versioning scheme

[Emmanuele Bassi via desktop-devel-list]

 release "41.0"

This is a change that might take a bit of an adjustment, but we feel it's
the best compromise towards a consistent versioning behavior.

Q: This is nonsensical. Why do you want to change the versioning scheme at
all? It's just numbers!
A: Numbers, like words, have meaning, and tell a story. With a change in
the versioning scheme we wish to communicate the fact that GNOME doesn't
see major versions of the development platform as the driving force behind
major changes in its user experience; and that radical changes to the user
experience are going to be introduced progressively, so that we can refine
and iterate over them in time, instead of dumping them in our users lap.

## Additional questions

Feel free to discuss this topic on Discourse, and to reach out to the
release team for additional clarifications.

On behalf of the GNOME release team,
 Emmanuele Bassi

[0]:
https://discourse.gnome.org/t/straw-man-proposal-changing-the-gnome-versioning-scheme/1964
[1]:
https://mail.gnome.org/archives/desktop-devel-list/2020-July/msg4.html
[2]:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk/
[3]: https://blogs.gnome.org/aday/2017/08/08/the-gnome-way/

-- 
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: Regarding behaviour of Gnome and Fedora members

[Emmanuele Bassi via desktop-devel-list]

On Fri, 12 Jun 2020 at 13:30, Ty Young via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:


> ...sorry, just read the xkcd link. That, IMO, does indeed violates
> GNOME's Code of Conduct. There sure are a lot of people violating their
> own project's inclusion and community standards...
>

Let's be clear: just because people don't agree with your take and tell you
to go away doesn't mean they are violating the code of conduct.

Harassing people because they don't cave to your condescending remarks, and
don't do whatever you want, is, on the other hand, a code of conduct
violation; so I respectfully ask you stop doing that, and leave this
community.

Also, I'd recommend mellowing out, because you're one step away from
ranting on youtube about lizard people secretly controlling the world
governments.

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: Is any GNOME project using Mapbox legacy classic tiles with the GNOME API key?

[Emmanuele Bassi via desktop-devel-list]

Could it be caused by users of Maps on some long term support Linux
distributions, like Ubuntu 16.04/18.04, or RHEL7/8?

Ciao,
 Emmanuele.

On Mon, 8 Jun 2020 at 22:00, Marcus Lundblad via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Hi!
>
> As Mapbox has deprecated the old classic tiles, they have been sending
> out notification e-mails to users who have accessed the classic styles
> recently. And the key we use for GNOME Maps have been flagged for this.
> I have doublechecked our tile definition, and it should use the new
> tile sets. In Maps we download the tile definitions dynamically from a
> service file (we have never hardcoded the tile URLs since the migration
> from MapQuest back in 2016, though we did use a proxy briefly, but
> stopped that, and the proxy should not working since quite a long time
> AFAIK).
>
> I just wanted to check to see if maybe there is some other project in
> GNOME that uses this service (and is still use using classic styles(
> that I have missed?
>
> The old classic tiles use a URI like (for the "streets" style):
>
> https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token=
> 
>
> and the new ones:
>
>
> https://api.mapbox.com/styles/v1/mapbox/streets-v11/tiles/#Z#/#X#/#Y#?access_token=
> 
>
> Or maybe some distribution has a patched version of Maps using the
> legacy style?
>
> And also the usage figures that Mapbox provided was only referring to
> the classic style for "streets", not the satellite one. Oh, and also,
> the classic style tiles have not received any updates since sometime in
> 2018.
>
> Thanks!
> //Marcus
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>


-- 
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: How to detect a gtk desktop programmatically

[Emmanuele Bassi via desktop-devel-list]

On Thu, 30 Apr 2020 at 17:23, Michael Catanzaro 
wrote:


> I would worry about the future, though. I'm skeptical that updating to
> GTK 4 will ever be possible (due to the removal of the foreign drawing
> API that allows non-GTK apps to render boxes and buttons and such using
> the GTK theme). So even if it's the best option today, I don't see much
> long-term future here. I'm not sure what the Java community should be
> doing, but probably thinking about this early would be better than
> waiting until GTK 4 is released and it's too late for major changes.
>

Slight correction: with GTK4 it's still possible to create render nodes and
use them to render CSS state, but you have to handle that state on your
own. In practice, this means you won't be able to use GTK API to render
stuff that looks like a GTK widget according to the current theme; if you
want something that looks like a GtkWidget, you need to use GtkWidget.

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

Moving gdk-pixbuf-xlib out of gdk-pixbuf

[Emmanuele Bassi via desktop-devel-list]

Hi all;

tl;dr: the gdk-pixbuf-xlib deprecated shared library now lives in its own,
archived repository available at:

https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

If you're explicitly enabling X11 support in gdk-pixbuf in your builds
and/or packages and distributing the additional libgdk_pixbuf_xlib-2.0.so
shared library, you should build the library found in that repository
instead.



GdkPixbuf was split off from the main GTK repository, in 2010, and it
provided two main shared libraries:

  - libgdk_pixbuf-2.0.so
  - libgdk_pixbuf_xlib-2.0.so

The latter contains various functions to integrate GdkPixbuf with Xlib data
types, and some unnamespaced convenience API the likes of which we won't
mention.

The build and installation of gdk-pixbuf-xlib is gated on a configuration
option, to allow building GdkPixbuf on platforms that do not support X11.
In general, the whole gdk-pixbuf-xlib API is considered deprecated, as it
literally depends on and exposes Xlib data types.

In order to remove the dependencies on windowing system API in what
ostensibly is an image loading library, I've moved the gdk-pixbuf-xlib API
into its own repository. I've maintained as much history as possible, and
the build artefacts are identical, so it's a matter of creating a new
package for your Linux distribution and/or adding the repository to your
dependencies. The gdk-pixbuf-xlib dependencies are:

 - gdk-pixbuf
 - xlib
 - gtk-doc, for the API reference

There's no introspection data, because of the explicit use of Xlib data
types.

I'll do a release of the library for the next GNOME release, and I'm happy
to keep it in deep maintenance mode if people have outstanding patches
lying around.

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: Maintainers should announce build-related changes in their modules

[Emmanuele Bassi]

On Fri, 13 Sep, 2019 at 10:21, Bastien Nocera  wrote:

On Fri, 2019-09-13 at 10:12 +0100, Emmanuele Bassi via desktop-devel-
list wrote:


 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.


This doesn't sound one bit nice or polite.



I apologise for the rudeness.


I'd like to apologise in advance for the time that I'll also forget to
send a mail to the release-team, or wondering why I need to tell the
release-team when I bump a dependency that's going to be shipped with
the new GNOME anyway, such as GTK or glib.


If a dependency is already in the GNOME SDK then there's no real need 
to notify us; unless, of course, the dependency in the SDK is pinned to 
a specific version, and you require a later one.


As I said in the original email, before this detour into whether humans 
can or should be automated out of their jobs, this is definitely more 
important for dependencies hosted outside of gitlab.gnome.org.


Ciao,
Emmanuele.


___
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

[Emmanuele Bassi]

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.


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.


Ciao,
Emmanuele.



___
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

[Emmanuele Bassi via desktop-devel-list]

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]
___
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

[Emmanuele Bassi via desktop-devel-list]

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]
___
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: Proposal: Replace all references to master/slave in GNOME modules

[Emmanuele Bassi via desktop-devel-list]

On Fri, 26 Apr 2019 at 17:12,  wrote:

>
> I'm a little surprised that nobody has yet mentioned the elephant in
> the room. The definition of "git" is not very inclusive:
>

What did I say, upthread, about falling into the "slippery slope" fallacy,
and sticking to the topic of discussion?

Do we need to moderate this whole thread, if people are incapable of taking
things seriously?

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: Proposal: Replace all references to master/slave in GNOME modules

[Emmanuele Bassi via desktop-devel-list]

On Thu, 25 Apr 2019 at 15:24, Daniel Mustieles García via
desktop-devel-list  wrote:

> The next change we could discuss is about to remove daemons, parents
> killing child process, zombies...
>

Let's not play the tiresome "slippery slope" fallacy, here, and try to
stick to the topic of the naming of the default branch of the Git
repositories.

Ciao,
 Emmanuele.

El jue., 25 abr. 2019 a las 16:17, Christopher Davis via desktop-devel-list
> () escribió:
>
>> It does not reflect on history, it is not a reference to it.
>>
>>
>> That's not how language works. Language is years of words being assigned
>> meaning. As you
>> described it, master/slave terminology has the same exact meaning of a
>> relationship between a
>> real master and slave. That connection is the problematic bit, because in
>> some countries slavery
>> wasn't all that long ago, and in some places it's never left or it
>> changed forms.
>>
>> If we want to be an inclusive project, it would be beneficial to use
>> language that do esn't scratch at scars
>> when we have other metaphors we can use.
>>
>> Regards,
>> Chris
>>
>> On Thu, Apr 25, 2019 at 10:12 AM, Pat Suwalski  wrote:
>>
>> On 2019-04-25 9:58 a.m., Emmanuele Bassi via desktop-devel-list wrote:
>>
>> If you cannot maintain even a semblance of a civil discourse, the door is
>> shown to you at the bottom of every email.
>>
>> Fine, if you want it stated a different way, the terms being used are as
>> accurate as possible. There is a master process. It tells a slave what to
>> do. The slave process does it, no questions asked. This is what machines
>> do. It is accurate. It does not reflect on history, it is not a reference
>> to it. --Pat ___
>> desktop-devel-list mailing list desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: Proposal: Replace all references to master/slave in GNOME modules

[Emmanuele Bassi via desktop-devel-list]

On Thu, 25 Apr 2019 at 14:54, Pat Suwalski  wrote:

> On 2019-04-25 6:43 a.m., Bastien Nocera wrote:
> > It's non-gender neutral, which was mentioned earlier in the thread.
> >
> > See the master/maiden section of:
> >
> https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt
>
> Is this entire thread some weird, SJW-perverted joke?
>
> "Who the bleep cares?" If you're triggered by branch naming, go hide
> under a rock. Or maybe get a psychiatrist.


Quick reminder that desktop-devel-list, like *every other service hosted by
GNOME*, is under the Code of Conduct.

If you cannot maintain even a semblance of a civil discourse, the door is
shown to you at the bottom of every email.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 18:27, Florian Müllner  wrote:

> On Mon, Mar 25, 2019 at 6:50 PM Emmanuele Bassi  wrote:
> >
> > You cut the part where I said the appindicator implementation should be
> changed. :-)
>
> I thought you were referring to the client library, not the underlying
> spec :-)
>

AFAIK the spec still assumes X11 like:


```
org.freedesktop.StatusNotifierItem.WindowId

UINT32 org.freedesktop.StatusNotifierItem.WindowId ();

It's the windowing-system dependent identifier for a window, the
application can chose one of its windows to be available through this
property or just set 0 if it's not interested.

```


or DBus-Menu:


```

org.freedesktop.StatusNotifierItem.Menu

OBJECT PATH: DBus path to an object which should implement the
com.canonical.dbusmenu interface
```

on top of the whole wishy-washy "don't implement this if you don't like it,
Mercury is retrograde, or it's Thursday", so it's definitely needs to be
changed as well.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 17:34, Florian Müllner  wrote:

> On Mon, Mar 25, 2019 at 5:36 PM Emmanuele Bassi via desktop-devel-list
>  wrote:
> >
> > If the answer to status icons is to adopt/adapt the appindicator API,
> I'm also fine with that;
>
> I'm not. The StatusNotifier spec is seriously flawed, and I don't want
> to support it unless at least the issues that were raised ten years
> ago are addressed (the spec was put up for "review" on xdg-list, but
> then any comments were hand-waived away with "if you don't like it,
> don't implement it").
>

You cut the part where I said the appindicator implementation should be
changed. :-)

I also completely agree that the StatusNotifier spec is broken by design;
Canonical tried to fix it, but the changes ended up into the Unity silo,
and drifted apart from the baseline KDE implementation (even though I think
KDE changed their own code to match expectations with Unity after a while).

Seriously, the spec is so crappy that there are two implementations
> that are both compliant, but interpret the spec in different and
> incompatible ways (see the implementation-specific handling in [0]).
>

The spec is so badly designed that we could literally claim that we're
implementing it right now, if we just owned a name on the bus without
plugging it to anything.

If we want to support something *like* appindicators, it must be a new
> and fixed API[1] that apps can port to, not the existing API, sorry.
>

I wholeheartedly agree. The problem remains that applications would now
have to port to this new API, and support:

 - spangly new API
 - libappindicator
 - GtkStatusIcon

in their code.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 16:29, Will Thompson  wrote:


> On the other hand: this API under its various names is already
> widely-supported both by (non-GNOME) apps, and by widely-used desktop
> environments – a virtuous cycle. In particular, several third-party,
> non-free apps like Dropbox which are partially or totally
>
unusable without a status notifier already support it. (Not to make this
> all about Dropbox – it's just an app I use that falls into the "totally
> unusable" category.)
>
> I'm sure it's not as simple as "copy
> https://github.com/ubuntu/gnome-shell-extension-appindicator into the
> gnome-shell tree" – though it seems to work fine after a few days' testing
> – but supporting and improving this API would at least mean that many
> existing apps would behave as intended by their developers without needing
> to be changed (immediately).
>

If the answer to status icons is to adopt/adapt the appindicator API, I'm
also fine with that; a bunch of applications do use it, since it's
basically Ubuntu integration, and apparently "Linux == Ubuntu" for some
vendors.

Of course, a lot of the crappy "let's inspect GtkMenu at run time and
serialize it over DBus assuming nothing preserves state on top of the
menu/menu items" needs to go, and we need to handle the GMenu
serialization. But we're still back to the issue of: we need to port
applications.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 16:15,  wrote:

The dash seems like it might be a safer place to put things
> than allowing applications to clutter the precious top bar.
>

Like every other solution for placing stuff into the overview, this fails
to take into account menus created by status icons; the stacking of
override-redirect windows (i.e. menus) inside the overview, coupled with
grabs, is never going to work correctly.

Additionally, it fails to answer the question as to what happens when an
application raises its window while we're still inside the overview.

The tray notification has specific constraints that are caused by being a
component designed in 2004. These constraints cannot be magicked away
because they are encoded in how the whole thing works. If we change the
terms of the problem—introduce new API, change the behaviour of the tray or
of the status icons embedded into it—then we'll need to change all the
applications that use it, and we still won't solve the problem of the
existing tray icons being crap technology from 15 years ago.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 14:29, Pat Suwalski  wrote:

> On 2019-03-25 7:19 a.m., Emmanuele Bassi via desktop-devel-list wrote:
> > Which would achieve nothing except, once again, shoving icons and menus
> > into one of the most important pieces of screen real estate we have just
> > because some application developers simply cannot live without their
> > application icons being visible at all times.
>
> Is that a joke?


No.


> On a default gnome install on any modern screen, only
> about 25% of the top bar contains any information at all. It can't be
> "the most important real estate" and be so underutilized.


It's important because it's the UI element that is *always visible* at all
times.

Not every square millimeter of your screen need to be lit up by something
that can be interacted by the user.


> Same reasoning
> why it is rare to have a park in the middle of downtown.
>

I literally have no idea what this even means.


> That said, notification icons are literally the most useful information
> points for the many applications I have running in the background. So
> they deserve prominent placement.
>

If an application is in the background, why do you need to see an icon all
the time?

If the application needs to notify you of any state change while it's
hidden, it can use a notification; if you need an icon to interact with a
background application, you can literally re-launch it from the dash or
from the applications grid, and you'll get an application window.

If there are no state changes and you don't need to interact with it, then
the icon is pointless waste of space.

You think "application developers simply cannot live without their
> application icons being visible at all times"? That's why Windows lets
> you hide them. Problem solved. Like, since XP in 2001.
>

It's so much solved by Windows that tray icons are discouraged there as
well, and are generally left for legacy applications or custom hardware
settings.

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: I believe we should reconsider our sys-tray removal

[Emmanuele Bassi via desktop-devel-list]

On Mon, 25 Mar 2019 at 10:39, Daniel Mustieles García via
desktop-devel-list  wrote:

> Can't GtkStatusIcon be modified to show icons in the top bar?
>

No.

GtkStatusIcon encodes the XEMBED-based tray icon specification; this means
that the application code is responsible for:

 - sending icon data over the wire (no HiDPI, and transparency is a hack
that breaks every other release)
 - responding to pointer and keyboard events

The latter part means that applications that show a menu are responsible
for creating and managing the menu window and placing it at the right
coordinates—which simply does not work in a compositor and in Wayland,
respectively. The menu would also be styled by the toolkit, instead of
being styled by the compositor.

The only way to integrate "status icons" inside the shell UI is to move to
a purely descriptive format:

 - send the icon name from the theme
 - send the description of the menu over the wire

This would let the compositor display the icon using the appropriate
resolution and transparency, and it would let the compositor build and
display the menu. Sadly, this means a complete API change, which makes the
point moot: applications would need to be changed.

In any case, we do have API to achieve this—it's GMenu, and we used it for
the application menu and for integration inside Unity for the global menus;
it's also not used outside of GTK3 applications, and even then people do
like using GtkMenu so much, so the point is still moot.

The appindicator API/StatusNotifier specification comes close to this, but:

 - appindicator is a deprecated and unmaintained API, which still falls
back to the XEMBED protocol
 - it's also a hack that takes a GtkMenu, serialises it, and sends it over
the wire
 - the StatusNotifier specification is all kinds of terrible, and basically
the only implementation (appindicator and the KDE one) are normative
because, according to the letter of the StatusNotifier specification,
implementations that didn't do anything, or sent your status icons to Alpha
Centauri and waited for user input there, are perfectly conformant


> Permanently adding the extension code to the shell (which, if I've
> undesrtood properly, "moves" icons from tray to topbar) will be a dirty but
> effective solution.
>

Which would achieve nothing except, once again, shoving icons and menus
into one of the most important pieces of screen real estate we have just
because some application developers simply cannot live without their
application icons being visible at all times. If you want to do that, use
the extension. It's there for a reason.

The tray icons were designed and meant for system status notifications:
network state connectivity, volume level, battery level, IM status (when it
was a thing). They were hijacked by application developers to have panel
applets that would work across desktop environments. It was a bad idea
then, and nothing has changed in that regard.

Maybe we should maintain top-icons inside gnome-shell-extensions, so that
it doesn't fall into disrepair because its maintainers are busy or bored.


> I think, from my deep lack of knowledge about how it works, thak
> GtkStatusIcon could be modified to show icons in the topbar, so
> applications will keep calling to it without modifications, but icons would
> appear in the topbar instead of in the tray.
>
> If this is technically impossible just forget about it :-)
>

Believe me, I would *love* if people "forgot about it"; but it seems this
things have to be explained every six months, on every forum in existence,
until the end of time, so here we are.

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: What is the status of developer.gnome.org and help.gnome.org?

[Emmanuele Bassi via desktop-devel-list]

On Wed, 20 Feb 2019 at 17:27, Petr Kovar  wrote:


> > There's also a group of people wanting to do something else for the
> > developer site. I went to some of their meetings, but haven't had time
> > to keep up. I don't know their status.
>
> Same here. I think if the developer site group chooses at some point to
> go for the same solution as the user help site, they can just do it by
> re-using parts of the infra setup, though from what I understood the
> group's goal was to switch to a Drupal-like CMS. Any updates there?
>

There are two categories of content for the developers website:

 - API references
 - guides, tutorials, white papers, …

A CMS makes sense for the second category; we could literally run a
WordPress installation on developer.gnome.org *today*, and with minimal
effort port the existing content there.

On the other hand, though, the API references are, and will continue to be
for the foreseeable future, built from the code in the repository of each
module; a CMS makes little sense in that case. That's why I was proposing
to use the CI infrastructure to build API references from repository
events, like tagging a release, or pushing to a branch—or even pushing to a
MR, if we want to get an immediate render of the documentation changes it
introduces.

The problem with generating documentation from CI is that publishing it is
kind of complicated. When using GitLab pages, the CI will blow away
everything on deploy, which means you can only publish the latest tip of
the latest branch. This prevents us from having separate API references for
each branch/MR/tag. I've only seen GitLab CI used to deploy artifacts to S3
buckets, so I don't know if we can rsync CI build artefacts to some place
on the gnome.org infrastructure (I'd rather avoid involving an S3 bucket,
at this point, unless we can afford it for the future); it's something that
the GNOME sysadmins would need to investigate/set up. Publishing build
artefacts has the added bonus that we could finally get rid of the release
tarballs for projects, and just generate the dist archive when pushing a
(signed) tag, thus removing a pain point from the maintainers plate—but
that has nothing to do with the documentation.

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: What is the status of developer.gnome.org and help.gnome.org?

[Emmanuele Bassi via desktop-devel-list]

Hi Joanne;

the switch to Meson for various libraries broke the expectations of
library-web, which is used to populate developer.gnome.org. The scripts
expect the HTML for the API reference to be in the release tarballs, but
that’s not the case for Meson-generated dist archives.

GTK and GLib use a separate location to manually upload documentation
tarballs; this needs configuration changes in library-web, and manual
documentation generation on the maintainers side.

Given the state of library-web’s maintenance and resources, I’m actually
trying to figure out a way to use Gitlab’s CI to build the documentation
and put it somewhere else; I still have to investigate how to achieve this
on the GNOME infrastructure. In the meantime, you could check in the
Infrastructure/library-web repository for the configuration changes needed
to use an external tarball for the documentation, and open a merge request
to enable it for ATK and other libraries.

Ciao,
 Emmanuele.

On Fri, 15 Feb 2019 at 19:53, Joanmarie Diggs  wrote:

> Hey guys.
>
> I was about to file a bug against a browser asking them to implement
> some new ATK API, but that API isn't showing up on developer.gnome.org.
> Furthermore, looking at https://developer.gnome.org/atk/, I see the
> latest version is 2.28.1 even though 2.31.90 was released two weeks ago.
>
> The AT-SPI2 docs are similarly out of date:
> https://developer.gnome.org/libatspi/.
>
> And now that I look, I've added documentation to Orca that's not showing
> up on help.gnome.org.
>
> So Did we accessibility folks miss a memo somewhere and need to be
> doing things differently?
>
> Thanks in advance, and apologies if there is need something we should
> have known but didn't.
>
> --joanie
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
-- 
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: GNOME 3.32 milestone review

[Emmanuele Bassi via desktop-devel-list]

On Wed, 30 Jan 2019 at 09:20, Allan Day via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:


> Carlos Soriano  wrote:
> ...
> > gnome-screenshot, retire app menu - Part of the GNOME initiative to
> remove app menus. There is a MR, needs some review. Deadline 4th February,
> UI freeze.
>
> The thing we're missing here is participation from a maintainer. Is
> gnome-screenshot actually maintained nowadays? If not, can assign a
> new maintainer?
>

Cosimo is probably way too busy, these days, so finding a new maintainer is
probably a good plan regardless.

I'd be happy to help with code reviews and the occasional release.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Mon, 28 Jan 2019 at 11:40, Debarshi Ray  wrote:

> On Sun, Jan 27, 2019 at 12:13:26PM +0000, Emmanuele Bassi wrote:
> > Again, not a huge deal; sure, Documents is actually useful to navigate
> > through the Google Drive contents???the Drive web UX has become
> shockingly
> > bad over the years, unsurprisingly since its a fate that befalls every
> > Google application???but we can live without it, and it seems it's a
> niche
> > usage to begin with.
>
> GTK3 and GTK4 don't have a credible list or grid widget. We literally
> don't have anything to implement 90% of the GNOME Documents UI. There's
> no way Google's web UI can be worse than that.
>
>
Oh, trust me: it's worse.


> Also, porting GNOME Documents to GTK4 involves LibreOffice work.
>

Indeed, that is a problem that is not easy to solve without dropping
functionality from Documents. It's probably a justification alone from
dropping Documents from the release, and archiving it, assuming we ever
want to port Documents to GTK 4.


> > Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else
> > aren't used either.
>
> Whether it's used or not is only a part of the story. It's death by a
> thousand paper cuts.
>
> I already provided a list of issues GNOME Documents elsewhere.
>
>

And I already told you that I'm not advocating for Documents to be kept on
life support, or that you should keep the Documents integration in GOA
because of reasons.

I told you that removing things is perfectly okay, as long as we
communicate this upfront.


> > Who knows, we don't have metrics, right?
>
> We have metrics, yes.
>

No, we really don't, I'm sorry.


> We have enough metrics to gauge if:
> (a) an application has more than an infinitesimally small number of users
> (b) an application has an active enough contributor community
>
> Both (a) and (b) were coming out false for an extended period of time for
> GNOME Documents.
>
> Sitting behind multiple bug trackers (in my case GNOME, Fedora and RHEL)
> provides enough indication about (a). Insights into the RHEL customer and
> user base is another. RHEL 8 dropped GNOME Documents around the same time
> as both Fedora and RHEL 8 adopted GNOME Photos. You might not believe it,
> but I played almost no role there.
>

Bug trackers are an awful metric, with a clear and demonstrable bias.

Unless you have instrumented the session in RHEL to give you numbers on how
many people launch Documents and how much time they spend on it, then
looking at the installation numbers in RHEL paints only a very limited
picture.

Nevertheless, as I said: I don't *care* about Documents. I care about the
fact that we've added and removed things from GOA without establishing even
a scrap of a process.

If you stopped from lashing out at everyone you think is questioning your
ability to do your job for just *five minutes* you'd have realised that
this thread could have ended 80 emails ago; you just needed to open a wiki
page and write down what the process for adding a new service and removing
an existing service in GOA works, and what are applications supposed to do
in either case.

We do not have an exact measure of the number of active human users from
> Flathub, but we do have the number of times an application has been
> downloaded. Those numbers are influenced by the number of people who
> bothered to install the application or had it offered by their distributor,
> that's (a), and the frequency of updates to the Flatpak, that's (b).
>

Again, those numbers do not give you an accurate representation of use.
Downloads are *one* metric, and one that's not even very good. Before 3.30
we didn't have automatic Flatpak updates, which means downloading manually
whenever you remember to do so; with 3.30 we have automatic updates, which
means unless people actively uninstall an app, it'll still appear in the
stats. We don't know how many people install an application once; how long
does a session last; what kind of interaction there is; if it's used for
remote work or not.


> >  - we do have a user base, and we need to communicate changes effectively
> > so that we don't spend cycles constantly defending our decisions; that
> > stuff is exhausting.
> >  - we have a software development platform, and we'd like for app
> > developers to use it; we need to have processes in place to communicate
> our
> > expectations with second/third parties.
>
> Except, all that you accomplished in this thread is to scare the Deja
> Dup community into believing GNOME or GOA or whatever is actively
> harmful or hostile to them.
>

You must have read a very different thread from the one I read, beca

Re: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Sun, 27 Jan 2019 at 10:27, Debarshi Ray  wrote:


> The tl;dr here is that a lot of people care about political arguments
> but nobody shows up to bear the burden of dealing with the code.
>

"Political" in the sense that you're not maintaining a leaf node in the
dependency graph, that can come and go, but a service that has
repercussions on other projects.

The issue is not that Documents is going away; the problem is that
Documents is, by design, heavily dependent on a session service, and that
it can't be easily moved from that to its own implementation.

Again, not a huge deal; sure, Documents is actually useful to navigate
through the Google Drive contents—the Drive web UX has become shockingly
bad over the years, unsurprisingly since its a fate that befalls every
Google application—but we can live without it, and it seems it's a niche
usage to begin with.

But…

GNOME has various core applications that depend on the same mechanism. We
actually made a point of integrating with remote services, because
apparently that's a thing. We don't really have a policy for moving
applications from second/third party to core, but if that policy existed,
"integrating with the Online Accounts platform" would be on it. For
applications that migrate from second/third parties to core, that would be
an additional feature; for first party application, we would *only* have
that kind of integration.

The "political" issue I'm trying to raise is that not only we lack the "how
do we move an app into core" policy, but we also lack the "how do we move
an app out of core" one, especially when it comes to services integration.
Second/third party apps that integrate with web services can be moved out
of core by ripping the GOA integration, and falling back to their own—if
they still have it. First party applications that never had anything else
don't have that fallback path in place.

Again: maybe Documents isn't used. Maybe Photos, Music, and whatever else
aren't used either. Who knows, we don't have metrics, right?

Nevertheless, removing platform functionality without an adequate process
for it is problematic in many ways, a shockingly small amount of which are
technical:

 - we told people to use Flatpak for core applications; Flatpak doesn't
really like it when session services change, because session services are
part of the system API that cannot be sandboxed. Sure, GOA is almost an
outlier, but we have a bunch of services that are more than cavalier in
attitude when it comes to changing their features; how do we deal with that
happening?
 - we do have a user base, and we need to communicate changes effectively
so that we don't spend cycles constantly defending our decisions; that
stuff is exhausting.
 - we have a software development platform, and we'd like for app
developers to use it; we need to have processes in place to communicate our
expectations with second/third parties.
 - we have a set of potential core applications and not enough people
writing them; if our platform isn't stable enough for first parties, if our
expectations about what can happen to it aren't communicated well enough
*amongst ourselves* then we can pack our bags, and go home, because we're
done.

So, yes: we have to deal with "political" issues, here, because we are a
complex project with maintainers that have the right/tendency to do
whatever they want.

I do think that GNOME is better served caring about a small subset of
> providers and services - those that we are serious about supporting,
> and have (or will have) high quality applications offering the user
> facing features. We should evolve the design and code in whichever
> direction that takes us.
>
> What we shouldn't do is get into architecture astronauting and
> political arguments about getting everybody's favourite logo into the
> Online Accounts panel.
>

I hope you realise that my objections in this thread are not about
astronauting things, outside of a side note about I always found GOA a
missed opportunity to build our platform; I'm more concerned about the lack
of process that seems to plague GNOME (from time immemorial, I might add)
and the fact that every time this is brought up, people scream "stop
energy" or "architecture astronauting" or "maintainer rights" or "what
would YOU do", instead of understanding that GNOME is a complex project and
the only way we can make it work is to communicate plainly and honestly
what people need to know in order to be a part of it.

By all means: work on making GOA smaller and more maintainable. If the
process to achieve that goal is that we should archive applications, then
it's absolutely fine to say so, write it down on the wiki, and point people
to it. What should *not* happen is telling people that apps will be dropped
from the release, and that's all there is to it, because that sets up the
wrong expectations that you can still build the application, distribute it,
or use it, and it'll work the same way—it just won't be part of th

Re: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Sun, 27 Jan 2019 at 09:24, Debarshi Ray  wrote:

> On Thu, Jan 24, 2019 at 11:00:58AM +0100, Bastien Nocera wrote:
> > I don't think that feature requests should be treated on the same level
> > as existing, merged, features
>
> I can't change my theme, I can't change my fonts, no minimize button,
> no wallpaper options, my laptop insists on suspending ...
>
> Can I have those back?
>

Install Tweaks.

See, that's kind of the difference between removing infrastructure and
removing UI for it.

Even if you're removing infrastructure, we do have mechanisms and policies
for transitioning between the initial and final points: versioned
interfaces, soname bumps, new dependencies, deprecations.

What I've been asking is to come up with a process that lets us move an
application from core to third party, so that we can communicate this
appropriately to users and app developers alike. Because today is
Documents, and tomorrow is Music, and the day after that is Photos.

I understand that you're pissed because it seems we're doing backseat
driving on your maintainer role, but you're doing something that affects
the whole of the project, and that might happen again, so it's better to
have a process in place the first time—otherwise it *will* happen again and
we won't have a process at all.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 18:36, Debarshi Ray  wrote:

> On Wed, Jan 23, 2019 at 02:49:55PM +0000, Emmanuele Bassi via
> desktop-devel-list wrote:
> > On Wed, 23 Jan 2019 at 14:21, Allan Day  wrote:
> > > If apps could provide their own keys that would certainly change the
> > > picture (I didn't actually know it was a possibility.) It would also
> > > change the nature of Online Accounts of course; it's always been
> > > designed as part of the system, that's used by the system and the core
> > > apps. Might take a little thought.
> > >
> >
> > We had a key store for web services API keys in Moblin/MeeGo, as part of
> > libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> > keys, and OEMs didn't want to make their key public either. :-)
> >
> > Re-implementing that would not be hard, especially if we make it a
> > prerequisite that new services must come with their own key.
> Additionally,
> > it would let downstream vendors ship their own keys, if they are so
> > inclined.
>
> I don't understand.
>
> Say, we had a GNOME API key for Google and another for application
> Foo.  For all intents and purposes, those would need to be presented
> separately to the user. The user would have to sign in separately to
> GNOME and Foo and grant permission to each key, and so on. That's just
> how the services work.
>

If the "GNOME" API key is marked as the "system" key, then we only show the
GNOME key; if the system key does not exist, we show the Foo application
key.

It's already feasible for a downstream to replace all the default
> GNOME upstream keys shipped with GOA with their own using the build
> flags. For example, Fedora could do that, as long as they are careful
> enough to configure their keys properly.
>

I'm proposing adding run time discovery on top of build time.


> What isn't possible is to mix and match API keys with account types at
> run-time. That doesn't seem trivial to implement - neither from a code
> nor a design perspective. Possible, sure; trivial, no.
>

I didn't say "trivial", but I didn't expect this to be hard. You, of
course, know better than me how hard it would be, so I'll defer to your
assessment.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 17:55,  wrote:

> On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera 
> wrote:
> > It is what is happening in GNOME Online Accounts in general. Pocket is
> > disabled in Fedora 29, and there's a good chance that the mail
> > configuration bits will be disabled in Fedora 30.
> >
> > I don't know whether those changes will also be done upstream, but the
> > result will be the same, it won't be possible for applications shipped
> > through Flatpak to know that certain configuration options will be
> > available in GNOME Online Accounts.
>
> Thing is, we don't have any email apps in core. It just doesn't make
> sense to have email settings in gnome-online-accounts when none of the
> core apps (the apps installed by default) actually use those settings.
> It's just going to confuse users with settings that don't do anything.
>
> I don't really have strong opinions on the future of
> gnome-online-accounts, but unless there are major design changes along
> the lines that have been suggested in this thread, then yes, I would
> certainly advise against using it outside of the core apps.
>

This position is fundamentally at odds with the statement that we should
move towards containerised (flatpak/snap) core apps.

If the system service that provides single-sign-on for web services is not
stable—i.e. it can drop capabilities across minor releases—then we cannot
tell people to use Photos, Music, or whatever else as flatpaks/snaps.

Again, this is fine if we *explicitly* say that people can only use core
GNOME apps as part of the system; since we've been saying something else
entirely, we cannot use the fig leaf of "users will be confused" because I
can guarantee you that users will be much more confused (and angrier) if
they install an application, update the OS, and suddenly the application
won't work any more, which is something we *explicitly* said would not
happen.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 16:41, Allan Day  wrote:

> Emmanuele Bassi  wrote:
> ...
> >> > This is because we never specified a way to get third party keys
> stored inside GOA as part of a process to get third party modules to it.
> >>
> >> If apps could provide their own keys that would certainly change the
> >> picture (I didn't actually know it was a possibility.) It would also
> >> change the nature of Online Accounts of course; it's always been
> >> designed as part of the system, that's used by the system and the core
> >> apps. Might take a little thought.
> ...
> > We had a key store for web services API keys in Moblin/MeeGo, as part of
> libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
> keys, and OEMs didn't want to make their key public either. :-)
> >
> > Re-implementing that would not be hard, especially if we make it a
> prerequisite that new services must come with their own key. Additionally,
> it would let downstream vendors ship their own keys, if they are so
> inclined.
>
> Thinking about this idea a little more, I wonder what the value would
> be for users, over apps implementing online auth themselves.
>
> The original goal of Online Accounts was single sign-in: it was to
> avoid users having to repeatedly log into the same account, and to
> avoid multiple apps from carrying the UI to do so. If apps provide
> their own keys, then I assume that users will have to authenticate for
> each key, so the main advantage to users wouldn't apply.
>

The way this was designed in Moblin was not for apps to ship secret keys
for web services, but to have a semi-centralised way of shipping secrets
for system integrated services; then you could get your single-sign-on
platform. Think of it as a gsettings-desktop-schemas kind of scenario: a
repository of the secrets, with the ability to override them on a
per-OEM/per-installation basis.

Of course, if GNOME decided to remove a service, apps would still fall
over; but for that case we could move the secret to a separate "external"
repository that apps can depend on in a new release.

Alternatively, we could have priorities dictated by search paths, and apps
could always install their secret at a lower priority than the system one;
this way, if GNOME removes a service from GOA, it will fall back to the
application's own secret without degrading the user experience further than
"you now have to authenticate yourself when you use this app". This would
also work for sandboxed apps, because then they could avoid the API break
when the system's GOA changes capabilities.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 14:21, Allan Day  wrote:

> [Responding selectively, this thread is getting long.]
>
> Emmanuele Bassi  wrote:
> ...
> >> The main factor has always been about how we handle identity. If we
> >> give online accounts access to 3rd party apps, we're giving them
> >> access to the GNOME keys. They appear as "GNOME" to online providers
> >> and their access is bundled up with our own. As a result, we lose the
> >> ability to ensure that the GNOME keys are being used in accordance
> >> with providers' terms and conditions.
> >
> > This is because we never specified a way to get third party keys stored
> inside GOA as part of a process to get third party modules to it.
>
> If apps could provide their own keys that would certainly change the
> picture (I didn't actually know it was a possibility.) It would also
> change the nature of Online Accounts of course; it's always been
> designed as part of the system, that's used by the system and the core
> apps. Might take a little thought.
>

We had a key store for web services API keys in Moblin/MeeGo, as part of
libsocialweb, mostly because we couldn't have OEMs ship with Intel OTC
keys, and OEMs didn't want to make their key public either. :-)

Re-implementing that would not be hard, especially if we make it a
prerequisite that new services must come with their own key. Additionally,
it would let downstream vendors ship their own keys, if they are so
inclined.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 12:26, Allan Day  wrote:

> Emmanuele Bassi  wrote:
> ...
> >> This approach isn't new, and you can read more detail here:
> >> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
> >>
> >
> > I know the rationale. I never particularly agreed with it, because it
> felt like an ex post rationalisation about not having third party modules,
> and getting people to commit functionality upstream. ...
>
> I don't think that was the reason. At least, it's not what's been on
> my mind, and I don't remember others putting that view forward.
>

"It felt like".


> The main factor has always been about how we handle identity. If we
> give online accounts access to 3rd party apps, we're giving them
> access to the GNOME keys. They appear as "GNOME" to online providers
> and their access is bundled up with our own. As a result, we lose the
> ability to ensure that the GNOME keys are being used in accordance
> with providers' terms and conditions.
>

This is because we never specified a way to get third party keys stored
inside GOA as part of a process to get third party modules to it.

>From a design perspective that's never been something we've wanted to
> do, both from a branding and identity perspective, as well as from a
> "oh shit we can't access Google any more, because some random app did
> something they didn't like".
>

We can communicate that a key has been revoked by a service in the same way
we communicate that the user needs to re-authenticate themselves.


> > What I'm objecting to is the wishy-washy approach of telling people:
> "Sure, you can keep working on Documents, it's just not going to be
> installed any more" without telling the whole story.
> >
> > If Documents is removed, then all the Documents integration within GNOME
> is also removed, which means that the project *in its current incarnation*
> should just be archived. People should be encouraged to fork it, if they
> find it useful, and implement that integration inside Documents itself.
> This gives the proper context and communicates the proper expectations to
> people willing to maintain the Documents code base.
>
> If you think something can be done better, just suggest how it can be
> done better.
>
>
I believe I just did that: make the consequences of picking up Documents—or
any other core application we decide to drop because the design is fuzzy,
or the resources are too few to make a design work—explicit. Do not say:
"we are simply dropping Documents from the release", or "we are removing
Documents integration from GOA because we're dropping Documents"; instead,
explain what that means for somebody picking up a former-core application.
An even more explicit action is: archive the Git repository after removing
Documents from the release, and tell people to fork it and rename it.

Create a process for moving apps from "core" to "external".

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Wed, 23 Jan 2019 at 10:39, Allan Day  wrote:

> Emmanuele Bassi via desktop-devel-list 
> wrote:
> ...
> >> We have a rule though: the account types exposed in
> >> gnome-online-accounts must be used by at least one core application.
> >> It's a good rule because it doesn't make sense to have settings in
> >> control-center for apps that aren't installed by default.
>
> From a UX perspective I think this makes sense. It's a bit strange if
> we have an out of the box experience where the switches in the online
> accounts settings don't do anything.
>
> This approach isn't new, and you can read more detail here:
> https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals
>
>
I know the rationale. I never particularly agreed with it, because it felt
like an ex post rationalisation about not having third party modules, and
getting people to commit functionality upstream. To be honest, I think it
was a bad idea not to provide a proper platform for this kind of
integration for third party applications and let people reimplement things
in their own silos; but given the constant lack of resources to the
platform, the lack of commitment never actually surprised me.

In any case, I'm not objecting to the rationale at all, nor at removing
Documents, or removing the Documents integration with GOA.

What I'm objecting to is the wishy-washy approach of telling people: "Sure,
you can keep working on Documents, it's just not going to be installed any
more" without telling the whole story.

If Documents is removed, then all the Documents integration within GNOME is
also removed, which means that the project *in its current incarnation*
should just be archived. People should be encouraged to fork it, if they
find it useful, and implement that integration inside Documents itself.
This gives the proper context and communicates the proper expectations to
people willing to maintain the Documents code base.

There's no point in calling it "GNOME Documents" if it's not a) part of
core and b) integrated with the facilities GNOME provides to its core
applications.

>> So unless we
> >> reverse course and add gnome-documents back to core, the documents
> >> account configuration settings should move from control-center to
> >> gnome-documents itself.
> >
> > So you're asking that an application with known resource problems
> re-implements functionality that was offloaded to a GNOME component in the
> first place. This work, by the way, may or may not be dropped in case we
> change our minds, and find a use case for Documents to be in the core apps
> in the future.
> >
> > At this point it would be much more honest to come forward and say:
> "GNOME Documents is no more. If you want to work on it, fork it and call it
> whatever".
>
> I don't think it's fair to make accusations of dishonesty. Michael and
> Debarshi have been open about what's happening and the consequences,
> and I think that's to be commended.
>

I didn't say it was malicious. I said it wasn't honest in the sense that
we've spent the whole thread justifying dropping Documents, and picking up
a new maintainer, and nobody explicitly communicated the fact that if you
want to work on Documents from now on you'll be doing it as a third party
developer, because there's no integration within GNOME any more.

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: GNOME Online Accounts 3.34 won't have documents support

[Emmanuele Bassi via desktop-devel-list]

On Mon, 21 Jan 2019 at 16:32,  wrote:


> We have a rule though: the account types exposed in
> gnome-online-accounts must be used by at least one core application.
> It's a good rule because it doesn't make sense to have settings in
> control-center for apps that aren't installed by default. So unless we
> reverse course and add gnome-documents back to core, the documents
> account configuration settings should move from control-center to
> gnome-documents itself.
>
>
So you're asking that an application with known resource problems
re-implements functionality that was offloaded to a GNOME component in the
first place. This work, by the way, may or may not be dropped in case we
change our minds, and find a use case for Documents to be in the core apps
in the future.

At this point it would be much more honest to come forward and say: "GNOME
Documents is no more. If you want to work on it, fork it and call it
whatever".

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: Documents and core apps

[Emmanuele Bassi via desktop-devel-list]

On Thu, 17 Jan 2019 at 16:59,  wrote:


> Release and design teams also don't want redundant apps in core, and
> there is interest in somewhat reducing the number of apps in core. We
> had been planning for several years to remove eog (obsoleted by
> gnome-photos and to remove evince with gnome-documents. Now it looks
> like gnome-photos and evince will be the winners instead. (eog is a
> very nice app, but once gnome-photos gains the ability to handle
> images, it becomes kinda redundant, right? I only hesitate due to
> nomenclature: not all images are photos. Maybe gnome-photos needs a
> rename.)
>

Removing Evince would have been slightly complicated even if Documents were
developed more heavily than it is because Evince is used for the print
preview in every GTK application, and nobody ever considered writing the
equivalent functionality for Documents in the first place.

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: GNOME Mastodon Instance?

[Emmanuele Bassi via desktop-devel-list]

On Wed, 31 Oct 2018 at 10:27, Alexandre Franke  wrote:

> On Mon, Oct 15, 2018 at 3:20 PM Emmanuele Bassi via desktop-devel-list
>  wrote:
> > Just to be clearer: once the GNOME Mastodon instance gets into a
> federation, it'll need somebody to moderate
> > the graph to block instances and users from other instances in the
> fediverse. I'm not (overly) worried about people
> > with an @gnome.org address on the GNOME instance, and for those we do
> have the Code of Conduct committee
> > (and, hopefully soon, a new code of conduct).
>
> Thanks for the clarification, I was indeed puzzled by your first
> reply. Can you expand a bit on what that instance blocking would
> entail? Would e.g. a Foundation member still be able to follow someone
> from a blocked instance?
>

Blocking an instance means that all messages coming from that instance
would be blocked before they reach the Foundation's mastodon instance.

Given that anyone can set up a Mastodon instance, blocking would be for
spamming purposes, or with moderation/purposes/goals completely opposite to
what we'd expect GNOME members to have, given our code of conduct:

  https://github.com/dzuk-mutant/blockchain

The spamming/porn cases are the trivialest to handle—and likely the least
controversial ones.

For a less trivial case: let's say that a "GNOME haters" group sets up a
Mastodon instance, and starts spamming @mastodon.gnome.org users;
administrators of the mastodon.gnome.org instance would need to block the
whole "gnomehaters" instance.

For an even less trivial case: if the fedyverse gets a mastodon instance
full of nazi/alt-righters/4channers every N weeks, we'd need somebody to do
instance blocking on those as well.

There are block lists, like these:

 - https://github.com/dzuk-mutant/blockchain/blob/master/list/list.md
 - https://github.com/tootcafe/blocked-instances

But Mastodon's moderation tools are still quite primitive, and it's unknown
whether they will improve over time:


https://nolanlawson.com/2018/08/31/mastodon-and-the-challenges-of-abuse-in-a-federated-system/

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: This video is dedicated to all of you

[Emmanuele Bassi via desktop-devel-list]

On Wed, 17 Oct 2018 at 18:30, Bastien Nocera  wrote:

> On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via desktop-
> devel-list wrote:
> > https://youtu.be/
>
> How is this person still allowed to post on d-d-l?
>

Yes, can we please enable some moderation? Not only this stuff is obnoxious
trolling, but people are replying to it. I dontyreally want this stuff in
my inbox.

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: GNOME Mastodon Instance?

[Emmanuele Bassi via desktop-devel-list]

Just to be clearer: once the GNOME Mastodon instance gets into a
federation, it'll need somebody to moderate the graph to block instances
and users from other instances in the fediverse. I'm not (overly) worried
about people with an @gnome.org address on the GNOME instance, and for
those we do have the Code of Conduct committee (and, hopefully soon, a new
code of conduct).

Ciao,
 Emmanuele.

On Mon, 15 Oct 2018 at 14:17, Emmanuele Bassi  wrote:

> Hi Richard;
>
> I wouldn't be opposed to have a mastodon.gnome.org instance for GNOME
> foundation members, but I'm not entirely sure about the security/moderation
> side of things: who's going to moderate the instance? We have people
> moderating mailing lists and a some level of moderation on IRC, but we'd
> need moderation for a new service like Mastodon. Do you have someone in
> mind?
>
> Ciao,
>  Emmanuele.
>
>
> On Tue, 9 Oct 2018 at 19:04, Richard Hughes via desktop-devel-list <
> desktop-devel-list@gnome.org> wrote:
>
>> Hi all,
>>
>> Now that Google+ is declared officially dead, I wondered if GNOME
>> would consider hosting a Mastodon instance. There's a bug already
>> open, https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/23
>> -- but I guess this needs someone to drive this and actually do the
>> work. I know I would trust a GNOME instance more than a random server,
>> both from a privacy point of view and security/moderation point of
>> view. It seems a shame to loose all the useful geeky connections with
>> people in the Open Source community, as people scatter to Twitter,
>> Facebook and all the other non-free places. Maybe now is the perfect
>> time to promote Mastodon and GNOME?
>>
>> Richard.
>> ___
>> desktop-devel-list mailing list
>> desktop-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>


-- 
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: GNOME Mastodon Instance?

[Emmanuele Bassi via desktop-devel-list]

Hi Richard;

I wouldn't be opposed to have a mastodon.gnome.org instance for GNOME
foundation members, but I'm not entirely sure about the security/moderation
side of things: who's going to moderate the instance? We have people
moderating mailing lists and a some level of moderation on IRC, but we'd
need moderation for a new service like Mastodon. Do you have someone in
mind?

Ciao,
 Emmanuele.


On Tue, 9 Oct 2018 at 19:04, Richard Hughes via desktop-devel-list <
desktop-devel-list@gnome.org> wrote:

> Hi all,
>
> Now that Google+ is declared officially dead, I wondered if GNOME
> would consider hosting a Mastodon instance. There's a bug already
> open, https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/23
> -- but I guess this needs someone to drive this and actually do the
> work. I know I would trust a GNOME instance more than a random server,
> both from a privacy point of view and security/moderation point of
> view. It seems a shame to loose all the useful geeky connections with
> people in the Open Source community, as people scatter to Twitter,
> Facebook and all the other non-free places. Maybe now is the perfect
> time to promote Mastodon and GNOME?
>
> Richard.
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>


-- 
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: Documentation - language default

[Emmanuele Bassi]

On 5 April 2018 at 14:36, Michael Hall  wrote:

> On 04/04/2018 05:35 PM, Emmanuele Bassi wrote:
>
>> You can have the best documentation in the world — but if you don't have
>> people working on the tooling and the actual integration between the
>> language and the platform, then you don't have anything that other people
>> can use.
>>
>
> Indeed, and the intention behind Sri's email was to get input from the
> wider GNOME dev community about the state of the tooling so we can build
> documentation around the language and platform capable of giving the best
> app developer experience.
>
>
You are asking the *wrong* people.

The "wider GNOME dev community" already knows how GNOME works, and it's
obviously skewed towards it; it cannot tell you what the pain points are,
because they are either used to work around them, or they don't know them
to begin with, as they learned GNOME first and another, non-C language
later.

If you want to know the pain points of writing a Python application
targeting GNOME, you have to go ask the Python community.

If you want to know how node.js developers can write an application
targeting the GNOME platform, you have to go ask the node community.

To give a little context, we didn't approach this with a goal of promoting
> Javascript. We started by asking which one language would be the easiest
> for an app developer to use to build a new application for GNOME desktops.
> This covered both the difficult of the language itself, the developer
> community around it, the GNOME specific tooling that would be used, and the
> documentation already available. We decided that, from what we knew,
> Javascript was probably the best option across all of these considerations,
> but we weren't sure, so Sri brought it up on this list to get wider input.
>
> So, to reiterate, the goal is not to promote Javascript on GNOME. The goal
> is to pick one language to use in promoting application development on
> GNOME.
>

This effort is doomed to failure because GNOME is *not* a single language
platform — unless that language is C, considering that our core platform is
written, documented, and developed for that language. Since we're not
talking about rewriting, say, GTK and GNOME Builder in JavaScript, C is
going to be the target of the GNOME platform development efforts.

More effort should be spent into understanding how to make GNOME an
enticing platform for other communities to target; what kind of tooling do
Python, Perl, JavaScript developers *already* use, and how can we make that
work as a first class citizen of GNOME? In order to do that, you have to
ask outside of the GNOME community, because otherwise the answers you're
going to get are not going to apply outside of the GNOME community itself.

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: Documentation - language default

[Emmanuele Bassi]

On 4 April 2018 at 19:39, Sriram Ramkrishna  wrote:

> Some of you may be aware that we have started a documentation effort in
> order to give application developers a proper set of documentation for them
> to write applications.
>
> We need to optimize for one language rather than promoting all the
> languages.
>

This was the conclusion of the 2013 DX hackfest:

  https://treitter.livejournal.com/14871.html

and we all know how that turned out:

 - people (correctly or not) equated the "we chose to concentrate on
JavaScript" as "everyone should use JavaScript for GNOME"
 - the messaging of "we chose to concentrate on JavaScript" pissed off
every other language community that had a sizeable presence in GNOME
(Python, most of all)
 - the announcement was made without resourcing, in the *hope* somebody
would turn up
 - we had to publicly backtrack on the messaging for the following 5 years

But, hey: we got a good JavaScript experience, right?

Well, not really.

  In the past, we have promoted javascript above all else.  We haven't seen
> as much movement in  javascript allegedly because the toolchain has not
> been as robust as the other languages.
>

Mostly because "promoting JavaScript" from a documentation point of view
isn't related to toolchain improvements.

The people that can write documentation are not the ones that are going to
hack on

 - the documentation platform
 - the JS engine
 - the plethora of tooling necessary to work and debug applications

Even with the first item we've failed. We've had, what? 4 or 5
documentation hackfests in the past 5 years, and all of them have a line
item about having better documentation platforms for our *C* API reference.

I really don't want to take a dig at anybody at the DX and documentation
hackfests — they are all volunteers and they work *really* hard. The job is
daunting in the best case scenario of somebody actually paying for this
stuff; that we have documentation already is kind of a miracle.

Since this conversation could easily get derailed,
>

That's probably the understatement of the year — *but* I think we'd be
better served by actually going a bit deeper than just "let's evaluate a
single language for our platform".


> what I would like to focus on is using javascript as the default computer
> language for developing 3rd party apps on the GNOME platform.  We would
> like to validate what the current state of javascript is for writing
> applications and whether we now have good support in flatpak, debugging
> toolchains (eg gjs and builder) and other factors we might have not
> considered but should be identified.
>
>
What does "validate" mean? You want to write an application? What kind of
an application?

What does "good support in Flatpak" mean?

What does "debugging toolchain" mean?

More importantly: what are you planning to do if you find issues?

Let's say that JavaScript fails to clear some arbitrary bar you defined —
and I'd really like to see how you define these bars to be cleared first —
what are the contingencies? Launch a D20 and choose another language?


> Any input in this regard would be well appreciated to drive good
> documentation to write applications for the GNOME platform.
>
>
While good documentation is a necessary stepping stone towards a decent SDK
and application development experience, it's nowhere near sufficient.

You can have the best documentation in the world — but if you don't have
people working on the tooling and the actual integration between the
language and the platform, then you don't have anything that other people
can use.

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: Check your default window size!

[Emmanuele Bassi]

On 20 March 2018 at 17:35, Ernestas Kulik  wrote:

> On Tue, 2018-03-20 at 18:29 +0100, Alexandre Franke wrote:
> >
> > Somewhat related, since not too long ago (I’d say 3.26, maybe 3.24)
> > Nautilus randomly forgets it’s size and will open a very small window
> > (with the sidebar displayed, the content area fits slightly less than
> > a row in height and than 2 icons in width).
>
> Hmm, we’ve actually received reports of a different issue - restoring
> window *position* in multi-head environments was unreliable. I’ve fixed
> it up a little, but removed that feature altogether from the
> development branch. Any issues with restoring sizes are unexpected and
> I’d appreciate a ticket. :)
>

Restoring the window position should never be left to applications — first
and foremost because, on Wayland, you don't have access to the global
coordinate space, so you cannot position your windows anyway. Even the
sizing is kind of problematic, because the window manager is, ultimately,
the one with the complete view of the constraints applied to a top-level
window, so the toolkit (and applications) can only do so much.

We're still lacking a good way to handle session and application lifetime,
including restoring window position, size, and state for each application
top-level window. I've been working a bit on a design, but will probably
take a bit of time, and will definitely need some discussion with the Shell
and Wayland developers, as it'll need some additional protocol extension to
allow the compositor and toolkit to know which window is which, in an
application.

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: Let's kill gnome-common!

[Emmanuele Bassi]

On 13 February 2018 at 11:17, Milan Crha  wrote:
> On Tue, 2018-02-13 at 09:33 +, Philip Withnall wrote:
>> porting the build systems of those modules to Meson is another
>> legitimate way to port away from gnome-common. It would be the better
>> choice in the long run for modules we are going to be maintaining for
>> a while.
>
> Hi,
> I do not want to steal the thread, but when talking about ports to
> Meson, would it make sense to finally fix the infrastructure to work
> with other than automake files too [1]? It's when generating the
> content for developer.|help.gnome.org. Considering that plenty of
> projects already use Meson, either exclusively or as an alternative for
> autotools scripts, then it would be a good idea, from my point of view.
> I'd help myself there, but I do no speak pythonish. I guess someone
> with the knowledge would have that fixed relatively quickly.

Work is in progress to let maintainers upload tarballs with the
generate API reference for developer.gnome.org; I assume
help.gnome.org would follow the same pattern — but of course we only
have one Frederic, so help is indeed welcome.

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

[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 update: Moving to the next step

[Emmanuele Bassi]

On 11 December 2017 at 15:51,   wrote:
> On Sun, Dec 10, 2017 at 10:04 AM, Michael Catanzaro 
> wrote:
>>
>> I was providing my opinions on which issues should be blockers for GNOME.
>> I'm not issuing demands here... Carlos is running this show.
>
>
> I updated a tracker bug today:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=776514
>
> How will that be migrated?
>
> Without issue dependencies, keeping track of related tasks is going to be a
> lot harder

That's what tags are for, given that "dependencies" and "blockers" in
Bugzilla are flat lists of bug numbers — unlike, say, Phabricator's
trees of issues.

The BZ migration script will take the "depends_on" and "blocks"
fields, and will list them with links to the original Bugzilla bug, as
part of the issue description, to avoid hitting the database too often
during the migration, but it should be easy to check if the bug was
already moved, and replace the link to the equivalent issue on GitLab.

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: g_object_ref() now propagates types

[Emmanuele Bassi]

On 8 December 2017 at 11:26, Philip Withnall  wrote:


> If anybody encounters any problems with this, please comment on the bug
> report:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=790697

As a side note: I've started a full Continuous rebuild, so if there
are projects that indeed break with this change, we should be notified
pretty quickly.

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 17:01, Milan Crha  wrote:
> On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote:

> a) See the second comment of
>https://gitlab-test.gnome.org/mcrha/test/issues/2
>It shows like three lines of text (one line, then empty line, then
>third line). When you edit that comment you'll see I made it
>several lines, not only three - the interface is ignoring my
>Enter-s. Am I supposed to use some crazy tag when I want to divide
>paragraphs and/or write simple lines?

The comment format is Markdown; you break paragraph by adding an empty line.

> b) How do I reply to a comment?

Select the text in the comment you wish to reply to, hit 'r'; it'll
put the selection, already quoted, in the comment area.

> c) my current work flow with bugzilla involves having opened *one* tab
>in the browser with a search which contains a list of bugs changed
>since some date for four different products. I refresh it in the
>morning to see newly added bugs and eventually react to them (I
>know, that's a silly idea to take care of newly added bugs where
>reporters are active the most). How do I do the same in
>gitlab, while: 1) the space will not be wasted, because I dislike
>scrolling when it's unnecessary (and here it is); 2) it will not
>be four different tabs in the browser?

I cannot help you, there. If you expect the workflow to be exactly the
same, I strongly suggest you never switch away from Bugzilla.

> d) I cannot set labels on my test project for some reason.

You need to have the appropriate permissions to do so; it's probably a
test instance issue.

> I know you can easily RTFM me, but do you know what? I didn't read any
> single word of the bugzilla manual and I've been able to work with it
> with no problem.

I seriously doubt you were born with innate knowledge of Bugzilla -
even though Bugzilla's feature set is basically limited to what you
see in the page.

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 17:19, Michael Catanzaro  wrote:
> On 12/07/2017 11:01 AM, Milan Crha wrote:
>>
>> b) How do I reply to a comment?
>
>
> This one should be a blocker to migrating any more projects.

> (1) Canned replies. I would rather stay with Bugzilla forever than give up
> canned replies.

Can we please drop this hyperbolic tone of "oh my god this new
platform doesn't work exactly like Bugzilla so we need to stop
everything until we replicated the subset of Bugzilla I like",
repeated for a bunch of maintainers with different subsets?

This is entirely not constructive.

You were not born with innate knowledge of Bugzilla, and even
Bugzilla's features that we use (the ones that survived the various
rebases) have been implemented over the years. I'm sure we can
re-implement stuff while we migrate, instead of expecting everything
to be as it was as a precondition for the migration.

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 14:17, Allan Day  wrote:
> Emmanuele Bassi  wrote:
> ...
>> This raises the question of who is going to review the currently
>> insufficient-bordering-on-useless code of conduct that we have for
>> GNOME online services and, more generally, for the community?
> ...
>
> As you know, I'm also on the Foundation Board of Directors. I'd like
> to reassure you that the board takes these issues very seriously and
> has recently been discussing the best way forward.

Thanks, Allan.

> I'm also currently chairing the Code of Conduct Working Group. While I
> can't speak for that group, from a personal point of view I think it
> makes sense to try and wrap up the Events Code of Conduct before
> looking at the one for online behaviour. Thankfully we're on the cusp
> of having that done, and much of the work that we've done in that area
> may well be transferable to online conduct, so we should hopefully be
> in a good position to move forward.

That's good to know, and I look forward to see the conclusion of the
code of conduct work for GNOME events.

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 13:28, Allan Day  wrote:
> Emmanuele Bassi  wrote:
> ...
>> And, yes: diversity is still an issue that we need to tackle [insert
>> subtle reminder here about the code of conduct rework that the board
>> is still working on and that I hope I'll see in my lifetime].
> ...
>
> Small clarification - it's the working group [1] that's working on the
> code of conduct, not the board. Also, it's an events code of conduct,
> not one for online behaviour.

Thanks for the clarification about the scope — even though this is not
what I was led to believe the *many* times I raised this issue with
the board. Well, clearly my fault.

This raises the question of who is going to review the currently
insufficient-bordering-on-useless code of conduct that we have for
GNOME online services and, more generally, for the community?

I want to have something like the freedesktop.org code of conduct[0]
apply to all the services we have in GNOME — mailing list, IRC, Git
repositories, and issue tracking. Since two of those services are now
being coalesced into a single platform, I think we should be
exceedingly clear about what we support and, especially, what we don't
condone.

The "Bill & Ted" code of conduct we currently have is woefully
inadequate to the modern realities of what the Internet is.

Ciao,
 Emmanuele.

[0]: https://www.freedesktop.org/wiki/CodeOfConduct/

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 12:18, Germán Poo-Caamaño  wrote:

>> And, yes: diversity is still an issue that we need to tackle [insert
>> subtle reminder here about the code of conduct rework that the board
>> is still working on and that I hope I'll see in my lifetime].
>
> I did read it, and I found it unfortunate. The reason to remove
> GamerGate was because of spam(!).

Well, the repository *was* in violation of the ToS for gitlab.com.

> And the wording did not help that much either:
>
> "The worst thing is that there seems to be systematic harassment of
> people (especially women) by this campaign. If so this is terrible and
> something that we absolutely condone."
>
> They absolute "condone" harassment? I think the right word was
> "condemn". But not clarification either.

Or, possibly, "we do not condone". In any case, have you thought about
reaching out to GitLab?

We should definitely raise this as a point with them — but, again:
this is *our* hosting, and we decide *our* rules.

I don't want to dismiss this at all, but the context here is
important. We are using their software, but we have our own servers
and our own code of conduct — as lightweight as it is.

>> On the other hand: we're self-hosting our own GitLab instance, so we
>> get to be as inclusive as we can, without necessarily depending on
>> some other project to make the rules.
>
> It may backlash GNOME either way, unfortunately.

I don't think so — any more that the fact that we don't get backlash
when the FSF does something dumb, or when Linus insults people — and
yet we still release our software under a FSF license, and run our
software on Linux.

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 update: Moving to the next step

[Emmanuele Bassi]

On 7 December 2017 at 11:57, Germán Poo-Caamaño  wrote:


> Have you considered the backlash to GNOME that it may cause?
> https://twitter.com/Amorelandra/status/938444347506180096
>
> I just learned about it.

You should probably read the whole thread.

https://twitter.com/puppetmasterd/status/938577068803088384

And, yes: diversity is still an issue that we need to tackle [insert
subtle reminder here about the code of conduct rework that the board
is still working on and that I hope I'll see in my lifetime].

On the other hand: we're self-hosting our own GitLab instance, so we
get to be as inclusive as we can, without necessarily depending on
some other project to make the rules.

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: Meson support in Continuous

[Emmanuele Bassi]

On Fri, 1 Dec 2017 at 18:57, Jeremy Bicha  wrote:

> On Fri, Dec 1, 2017 at 9:39 AM, Emmanuele Bassi  wrote:
> > On 29 November 2017 at 21:12, Emmanuele Bassi  wrote:
> >
> >> The build bot is currently busy rebuilding the whole of the manifest,
> >> and I'm going to babysit it for a little while, so don't start
> >> removing build-api wrappers or patches from the gnome-continuous
> >> repository just yet; once the build runs through, I'll give the all
> >> clear.
> >
> > All clear; you can start removing the `configure` build API wrappers
> > from your projects, if you have them.
>
> What about removing the gnome-continuous build-api patches? Are you
> going to remove those or would you like maintainers to help remove
> them?


I’m in the process of removing them; I already have a local commit that
does it, but I didn’t have time to push it today. I’ll do it as soon as I
have 5 minutes to double check that it doesn’t wreck the build.

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: Meson support in Continuous

[Emmanuele Bassi]

On 29 November 2017 at 21:12, Emmanuele Bassi  wrote:

> The build bot is currently busy rebuilding the whole of the manifest,
> and I'm going to babysit it for a little while, so don't start
> removing build-api wrappers or patches from the gnome-continuous
> repository just yet; once the build runs through, I'll give the all
> clear.

All clear; you can start removing the `configure` build API wrappers
from your projects, if you have them.

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

Meson support in Continuous

[Emmanuele Bassi]

Hi all;

I finally had time to work on this, and today I landed Meson support
inside Continuous.

This means that you won't need a downstream patch, or a build-api
wrapper script any more.

Additionally, if you have a dual build system Autotools/Meson in your
project, the Meson build will be picked up by default — though I've
added an escape hatch for those projects with experimental Meson
ports, like the X server.

The build bot is currently busy rebuilding the whole of the manifest,
and I'm going to babysit it for a little while, so don't start
removing build-api wrappers or patches from the gnome-continuous
repository just yet; once the build runs through, I'll give the all
clear.

Thanks for your patience.

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: Meson feedback as a user

[Emmanuele Bassi]

On 27 November 2017 at 09:56, Tomas Popela  wrote:
> On Mon, Nov 27, 2017 at 10:49 AM, Richard Hughes 
> wrote:
>>
>> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>> >  - Drop the "enable" from --enable-foo boolean options; Meson has
>> > boolean values, so -Denable-foo=true would read as redundant, and
>> > -Denable-foo=false would read as contradictory. Use -Dfoo=true or
>> > -Dfoo=false instead
>>
>> I'm guilt of this, I'll fix up my projects, but before I do is there
>> any list of best practices? e.g. should it be
>>
>> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?
>> * -Dintrospection=true or -Dgobject_introspection=true?
>> * -Dman=true or -Dman_pages=true
>> * -Dconsolekit=false or -DConsoleKit=false
>
>
> And what about  an option about enabling Vala bindings? In libsoup I use
> -Denable-vala, but if I would like to change it to -Dvala, then:
>
> Option name vala is reserved.
>
> or another logic one -Dvala_bindings:
>
> Option name vala_bindings is reserved.
>
> Any opinion?

You'll have to ask the Meson developers about this.

You could also have `generate_vapi` or `build_vapi` as options.

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: Meson feedback as a user

[Emmanuele Bassi]

On 27 November 2017 at 09:49, Richard Hughes  wrote:
> On 24 November 2017 at 14:49, Emmanuele Bassi  wrote:
>>  - Drop the "enable" from --enable-foo boolean options; Meson has
>> boolean values, so -Denable-foo=true would read as redundant, and
>> -Denable-foo=false would read as contradictory. Use -Dfoo=true or
>> -Dfoo=false instead
>
> I'm guilt of this, I'll fix up my projects, but before I do is there
> any list of best practices? e.g. should it be

It would be great if Meson modules would also be able to define
options, so we would not need to deal with gtk-doc and
gobject-introspection. Until that happens, though, I kind of trust the
judgement of GNOME maintainers.

> * -Dgtk_doc=true, -Dgtkdoc=true or -Ddocs=true?

It depends if you're gating other kind of documentation, like man
pages, using the same option.

Personally, I prefer `docs` as a catch-all.

> * -Dintrospection=true or -Dgobject_introspection=true?

Up to you. I have a slight preference for `introspection`.

> * -Dman=true or -Dman_pages=true

You can use `man`, or you could gate both API references and man pages
under the same option. In many cases, man pages are generated from the
same DocBook XML format anyway.

> * -Dconsolekit=false or -DConsoleKit=false

That's kind of esoteric; it's up to you, but think of the people that
need to type this out. ;-)

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: Meson feedback as a user

[Emmanuele Bassi]

Hi Michael;

On 4 November 2017 at 01:59, Michael Biebl  wrote:
> Hi there
>
> 2017-09-05 19:48 GMT+02:00 Emmanuele Bassi :
>> On 5 September 2017 at 18:40, Michael Biebl  wrote:
>
>>> Has there been some effort to consolidate the names?
>>
>> We're still in the process of migrating projects. The migration was
>> slowed down for the release of GNOME 3.26.
>>
>> I fully expect this to become a goal for the 3.28 development cycle,
>> while we migrate more projects to Meson; I'll make sure to add a
>> sub-page for the porting effort under
>> https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
>
> Afaics there is no such page yet which documents the list of preferred
> build switch names or am I simply not finding it?

A couple of weeks ago I updated the Wiki page on the Meson port[0]
with some of the best practices:

```
If your project has configuration options for the Autotools build make
sure to port them all to the Meson one, following these style
guidelines

 - Drop the "enable" from --enable-foo boolean options; Meson has
boolean values, so -Denable-foo=true would read as redundant, and
-Denable-foo=false would read as contradictory. Use -Dfoo=true or
-Dfoo=false instead
 - Similarly, you should drop "with" from --with-bar options
 - Use a consistent separator character for multi-word options,
preferably the underscore _, like cert_file or cups_print_backend
 - Try to avoid automatic feature detection; this makes it harder for
distributors and continuous integration systems to identify the
dependencies needed to build your project
 - Do not add "enable debug" options to inject pre-processor symbols
into the build, or control the presence of debugging messages; you
should use Meson's own buildtype option
 - Do not add "enable -Werror" options to make warnings fail the
build; you should use Meson's own --werror build option
```

It would be good if maintainers that are in the process of porting to
Meson would follow these guidelines; for projects already ported, it
would be good to file bugs.

Ciao,
 Emmanuele

[0]: https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

-- 
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: gjs 1.51.2

[Emmanuele Bassi]

On 14 November 2017 at 03:20,   wrote:
> On Mon, Nov 13, 2017 at 4:41 AM Michael Catanzaro 
> wrote:
>>
>> On Sun, Nov 12, 2017 at 10:44 PM, Philip Chimento
>>  wrote:
>> > From now on we'll be taking GitLab merge requests instead of Bugzilla
>> > patches. If you want to report a bug, please report it at GitLab.
>>
>> The Bugzilla product is still active... this needs to be disabled, or
>> people will continue to use it.
>
>
> I assume it's possible to disable new bugs being reported while keeping the
> old ones open?

Yes, it's the default behaviour on GNOME's Bugzilla instance.

Just close the product for new bug reports, and edit the description
to point to the GitLab issues page.

Alberto's script will do this automatically when moving bugs from
Bugzilla to GitLab.

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: User account for migrating Bugzilla issues to GitLab

[Emmanuele Bassi]

Thanks, Philip: this is much appreciated.

Since Alberto won't likely have time to work on this for a while, and
since this code should live in GNOME's own GitLab instance, how about
we create a new repository there?

Ciao,
 Emmanuele.

On 13 November 2017 at 00:14,   wrote:
> Hi,
>
> I've spent the weekend hacking on Alberto's Bugzilla-to-GitLab migration
> script and I've made some nice improvements in the readability/friendliness
> of the automatically generated issues, in my opinion. With everything in
> this merge request [1] I've got it in a state where I'm happy to start
> migrating issues for GJS from Bugzilla to GitLab.
>
> I also have a couple of GJS-specific changes which are here [2] in case
> anyone else is interested in copying them.
>
> One thing I'd like to check before I do that is whether it would be possible
> to do the migration logged in as a "bugzilla-migration" user on GitLab, for
> which I've opened an issue [3]. It would be a nice bonus to not have myself
> auto-subscribed to every issue that is migrated :-) It seems like it should
> be possible for a GitLab admin to create this account and, for example, give
> out a time-limited access token to a maintainer who wanted to run the
> migration script.
>
> If the bugzilla-migration user had admin permissions, it looks like the
> script could even post comments as the user who originally made the comment
> on Bugzilla, if that GitLab user exists. (On the other hand, it seems risky
> to hand out access tokens, even time-limited ones, to an admin account.)
>
> Any GitLab gurus have thoughts on this?
>
> Here are some examples of what the tool's output now looks like, on the
> GitLab test instance:
> - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/75
> - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/77
> - https://gitlab-test.gnome.org/ptomato/gjs-test/issues/70
> The full list is here [4].
>
> Regards,
> Philip C
>
> [1] https://gitlab.com/aruiz/gitlab-gnome-tools/merge_requests/9
> [2] https://gitlab.com/ptomato/gitlab-gnome-tools/compare/master...gjs
> [3] https://gitlab.com/aruiz/gitlab-gnome-tools/issues/20
> [4] https://gitlab-test.gnome.org/ptomato/gjs-test/issues?state=opened
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: Proposal for reducing the number of unremovable apps in GNOME Software

[Emmanuele Bassi]

On 6 November 2017 at 11:07, Bart Marien  wrote:

> Guys, if i may just add the following:
>
> We use gnome extensively in a live e-learning context(+1000 installs).
> We've had some minor abuse of the screenshot feature where students would
> take screenshots of the teacher (video conference) and do all kinds of
> stuff with it.
> Currently we have the feature disabled.
>
> So for us it's important that we can uninstall (or at least disable) the
> feature.
>

Of course; locked down environments should be an important consideration
for any feature that can be abused, but it's not really what we're talking
about here.

For your specific case, you probably want to look at:


https://help.gnome.org/admin/system-admin-guide/stable/user-settings.html.en#lockdown

and disable the screenshot shortcuts. Additionally, you probably want to
override the gnome-screenshot desktop file.

You should also file a bug to add a lockdown setting to disable taking
screenshots under /org/gnome/desktop/lockdown, so that gnome-shell can
ignore the screenshot shortcuts, and thus gnome-screenshot will fail
gracefully even if it's installed.

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: Proposal for reducing the number of unremovable apps in GNOME Software

[Emmanuele Bassi]

On 6 November 2017 at 10:46, Florian Müllner  wrote:
> On Mon, Nov 6, 2017 at 11:26 AM, Carlos Soriano  wrote:
>> I actually had no idea about the shortcuts until recently, specifically for
>> screenshoting an area, so I would be slightly against this. If we had the
>> shorcuts window in GNOME Shell and the initial setup would show it as it's
>> planned then I would probably be fine with the removal.
>
> That's an argument for keeping it installed by default (or rather: in
> the set of apps we recommend distros to install by default). I agree
> that this makes sense, but installed by default is not the same as
> unremovable - I don't see why users shouldn't be allowed to uninstall
> the screenshot app in Software if they want to.

For two main reasons:

1. Because nobody will ever remove it, thinking that gnome-screenshot
is the utility that actually provides the screenshot functionality.
Yes, *we* all know this whole functionality has been moved to the
compositor, and that gnome-screenshot is just a glorified UI around a
DBus interface at best, or at worst a pure X11 application that pokes
at the contents of the root window. I'm pretty sure, though, that
posed in front of the question "should I remove this screenshot
application", people that aren't us won't press "uninstall" in fear of
losing the ability to take a screenshot.

2. The user cannot install any other screenshot tool, unless they are
also using X11 only, given that there is no unified screenshot
interface for Wayland. So even if they removed gnome-screenshot in
order to install something else, users would be constrained to the
gnome-shell screenshot shortcuts.

This does not mean that gnome-screenshot should be made unremovable,
but it definitely needs some additional thought.

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: GitHub mirror creates contribution problems

[Emmanuele Bassi]

On 13 October 2017 at 13:54, Bastien Nocera  wrote:

> I'm now getting comments on commits which are really bug reports, like
> this one:
> https://github.com/GNOME/gdk-pixbuf/commit/c2a40a92fe3df4111ed9da51fe3368c079b86926#commitcomment-24951987

That's a first.

> Do we have any control over what's allowed on our mirrors, or do we
> need to accept this as yet another source of bug reports, like forums,
> blog post comments and Twitter/Facebook/Google+ questions?

Pretty much. If there's a comment box, you'll very likely get a
comment that almost looks like a bug report.

At most, you can be clear on where to file bugs, but playing
whack-a-mole with the whole Internet ends in disaster.

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: Meson feedback as a user

[Emmanuele Bassi]

On 5 September 2017 at 18:40, Michael Biebl  wrote:
> 2017-07-02 16:21 GMT+02:00 Sam Thursfield :
>> On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet  wrote:
>>> Out of curiosity, let's look at other GNOME-related modules that use
>>> gtk-doc. What is the name of the option that enables gtk-doc?
>>> - pango:enable_docs
>>> - gtk+: enable-documentation
>>> - graphene: enable-gtk-doc
>>> - atk:  enable_docs
>>
>> We should indeed work to make these names consistent across GNOME
>> modules. Having a page on the wiki where we list standard option names
>> for Meson build systems would be a good start.
>
> Has there been some effort to consolidate the names?

We're still in the process of migrating projects. The migration was
slowed down for the release of GNOME 3.26.

I fully expect this to become a goal for the 3.28 development cycle,
while we migrate more projects to Meson; I'll make sure to add a
sub-page for the porting effort under
https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting

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: New upstream repo for json-glib

[Emmanuele Bassi]

With the migration of the open bugs from Bugzilla, and with the
redirects in place, the move is now complete.

JSON-GLib is now available at: https://gitlab.gnome.org/GNOME/json-glib

Start your merge requests! :-D

Ciao,
 Emmanuele.


On 10 July 2017 at 16:28, Emmanuele Bassi  wrote:
> Hi all;
>
> JSON-GLib authoritative Git repository has been moved to the Gitlab
> instance on gitlab.gnome.org:
>
>   https://gitlab.gnome.org/ebassi/json-glib/
>
> as part of the pilot for the Gitlab migration.
>
> I will also move the issue tracker from Bugzilla to Gitlab itself, as
> soon as I have a full test run of the migration. In the meantime, feel
> free to keep using Bugzilla.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]



-- 
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: Application name strings consistency

[Emmanuele Bassi]

On 4 September 2017 at 13:34, Matthias Clasen  wrote:

>> I disagree. For some time I've argued that we should drop the "GNOME".
>> Reasons for this:
>>
>> 1. App names should be consistent.
>> 2. We generally don't expect users to know what GNOME is.
>> 3. There are other, better, places we can advertise the project, if that's
>> what we want to do.
>>
>
> But names also need to sufficiently identify the named item. Ending up with
> 5 "Clocks" and 4 "Maps" in gnome-software isn't really the best user
> experience.

And, before you ask: filtering for GNOME core apps would require a
black/white list inside every single app store, which is a solution
that does not scale. :-)

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: GNOME Mobile, or "GNOME on Purism's Librem 5"

[Emmanuele Bassi]

On Sun, 3 Sep 2017 at 20:06, Sriram Ramkrishna  wrote:

> Hi Matthias!  Exciting news indeed!  I personally would love to see our
> platform on a phone!
>
>
> On Sun, Sep 3, 2017 at 8:48 AM Matthias Klumpp 
> wrote:
>
>> Hi!
>>
>> 2017-09-03 17:27 GMT+02:00 Alberto Ruiz :
>> > [...]
>> >> Did anyone try to use GNOME on a smaller, phone-sized display already?
>> >
>> > Well, yes, Nokia did Maemo 10+ years ago and it was all Gtk+ based:
>> > https://en.wikipedia.org/wiki/Maemo
>> >
>> > The TL;DR of that story is... messy. They created a set of separate
>> > widgets, hildon, that didn't have a good story as to how they would
>> > make it upstream. Maemo's shell was stylus and keyboard driven and
>> > once the iPhone appeared everything changed...
>> >
>> > One thing they got right was making a product widely available to
>> > GNOME developers (N770, N800, N900...).
>> >
>> >> Is there interest in the community in actually making a "GNOME Mobile"
>> >> a reality (of course, Purism would help with that)?
>> >
>> > I think many of us would love to see that happening. But my take on it
>> > is that it will only happen if people step up to do the work.
>>
>> Yeah, I remember that good old times :-) Reviving Maemo is not really
>> an option, fortunately ;-) GNOME is much different now, and phones are
>> as well.
>>
>
> So apparently according to this thread -
> https://talk.maemo.org/showthread.php?s=7563791c558716a865ed741b04137a86&t=96800&page=18
> there is an active port to gtk3 for Hildon that might be worth observing.
> Frankly though they should be speaking to us as well since I believe there
> are still people here who have worked on hildon in the past for Nokia.
>

Let's leave Hildon where it belongs, please.

Additionally, I would try to push for gtk4 adoption and improvements; the
GTK team wants more drivers to deliver a better performance profile and
features, whereas we can't touch gtk3 any more, in terms of API.

Building a mobile extension toolkit on top of GTK is a great way to ensure
you're never going to ship anything remotely useful; working upstream so
that the GLES rendering pipeline for GTK is efficient and performant gives
a much better ROI in the medium to long term, and does not split the
community and engineering effort. That much we learned during the Nokia
days.


>> I am looking forward to your replies!
>> >
>> > I am not sure what you are trying to achieve with this email. Are you
>> > just trying to assess if the community would welcome a GNOME Mobile
>> > initiative? Because the response depends a lot on the specifics of how
>> > you want to do things.
>>
>> Yes, pretty much that was the intent. At the moment, we do not know
>> yet how many resources we will have (if any at all, depending on the
>> crowdfunding) to make the phone and GNOME Mobile a reality, but
>> figuring out what would need to be done and how any such effort would
>> be received by the community is very valuable to know in advance.
>>
>
> One possible idea is to create a hackfest and get some of the consultancy
> companies to help sponsor it and sell it as a way to open a new market for
> them.  After all, a successful phone means a new application market of
> which they could make money on consulting because they would know and
> understand the underlying stack.
>
> Absolutely you should come to the Libre Application Summit and work with
> us to get the right people there as another alternative.  Finding and
> attracting developers is probably a good first step.  You might also look
> at the Tizen stack in terms of toolchain and what not.  It already has a
> number of GNOME/GTK+ libraries already.
>

Again, leave Tizen where it belongs: on the trash heap of history.

If you want to create a platform, concentrate on the underlying vision, not
on the stack diagram. We have had far too many of those littering the side
of the road.

There are plenty of infrastructures that can deliver you an OS for a given
hardware platform and architecture; whatever you ship to make your main UX
should also be the underpinnings of your app development story, to minimise
the impedance mismatch between what you have to optimise in your OS and
what you have to optimise in your SDK.

> For example: are you going to be setting up a wikipage in
>> > wiki.gnome.org or are you going to have an in-house
>> > documentation/development process?
>> > Are you going to start writing
>> > mobile friendly widgets/apps in git(lab).gnome.org or are you going to
>> > host/bugtrack things yourselves? Are you going to start writing GNOME
>> > Shell extensions and patches for a mobile shell and contributing them
>> > upstream? Are you going to start profiling and improving GNOME Shell's
>> > performance on slow I/O?
>>
>> If we do anything, it will be done upstream, as per Purism's vision.
>> So, developing an inhouse solution based on the GNOME stack wouldn't
>> be an option for us.
>>
>
> That's appreciated. :)
>
>
>>
>> > These are a few ideas on how y

Re: Updating GNOME Goals?

[Emmanuele Bassi]

Before committing to tons more search providers, I'd like to see a bug
and some development effort dedicated to make the providers we already
ship more efficient.

Right now each search provider needs to be activated via DBus — and in
some cases these search providers are just an application in a
window-less mode; then every single application needs to be queried
every 150 milliseconds for results, regardless of whether they make
sense or not.

If we keep adding more search providers without evaluating the
performance implications then we'll end up with users and, more
importantly, OSVs disabling most of them out of the box.

Ciao,
 Emmanuele.

On 1 September 2017 at 12:20, Allan Day  wrote:
> I have a list of about 12 apps that don't have search providers and probably
> should. I'd love for us to make some progress on that - would it make a good
> goal?
>
> Allan
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: Build system change GTK's master branch

[Emmanuele Bassi]

On 15 August 2017 at 04:09, Chun-wei Fan (范君維)  wrote:
> Hi,
>
> Thanks to Emmanuele for giving me the credit here :)

Absolutely well earned.

> Emmanuele Bassi 於 2017/8/15 上午 05:46 寫道:
>>
>> The change means that GTK+ master now has a build-time dependency on:
>>
>>- Python 3.x
>>- Meson - http://mesonbuild.com
>>- Ninja (though Meson also supports Visual Studio out of the box)
>>
>> Building GTK+ is now a matter of calling:
>>
>>$ meson $builddir $srcdir
>>$ ninja -C $builddir
>>$ sudo ninja -C $builddir install
>
>
> I should also mention that there are a few bugs underway to make the Meson
> build experience on Windows/Visual Studio better/working for the stack,
> which includes:
> GLib: 783270 and 784995
> ATK: 785802
> Pango: 783274
> GDK-Pixbuf: 785767
> GTK+-4.x/3.9x: 785210 (Meson), 773299 (sources)
>
> Any comments in those bugs are really appreciated, and thanks to all who
> have given pointers there, including Emmanuele, Bastien, Alejandro and
> Ignacio (and to those who I may have missed, sorry!)

I'll make sure to review those bugs, thanks.

> Please also note that there is a PR on Meson to fix introspection builds of
> GTK+ on Windows[1] due to the 8192-character-per-command limit on Windows,

We should modify the introspection scanner to allow taking a list of files.

If the Python setup/teardown cost weren't so high, I'd even look into
running g-ir-scanner on individual files, generate intermediate
introspection data, and then have a "link" phase to generate the XML;
that would also immensely help with incremental builds.

> and Visual Studio 2008 support is not quite there for projects that still
> support it (i.e. for Python 2.7.x support, as that is built with Visual
> Studio 2008 for Windows), as we need to embed SxS manifests with 2008
> builds.

Supporting Visual Studio pre-2015 is going to be hard; various modules
are trying to standardise on a C99 pipeline, and I'd rather move away
from nearly ten year old development environments if that involves
work on our side.

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

Build system change GTK's master branch

[Emmanuele Bassi]

Hi all;

executive summary: the master branch of GTK+ now builds with Meson,
and the Autotools build system files have been dropped.

The documentation has been updated to reflect the new build system —
as well as, in some cases, the past 10 years of development.

The change means that GTK+ master now has a build-time dependency on:

  - Python 3.x
  - Meson - http://mesonbuild.com
  - Ninja (though Meson also supports Visual Studio out of the box)

Building GTK+ is now a matter of calling:

  $ meson $builddir $srcdir
  $ ninja -C $builddir
  $ sudo ninja -C $builddir install

(where $builddir is the build directory you want to use, and $srcdir
is the directory with the GTK+ sources)

The main change is that now GTK+ takes about ⅓ of the time to build
compared to the Autotools build, with likely bigger wins on older/less
powerful hardware; the Visual Studio support on Windows should be at
least a couple of orders of magnitude easier (shout out to Fan
Chun-wei for having spent so, so many hours ensuring that we could
even build on Windows with Visual Studio and MSVC); and maintaining
the build system should be equally easier for everyone on any platform
we currently support.

Of course no migration is going to be perfect at the first try, even
though we have been building GTK+ master using Meson on the GNOME
continuous integration pipeline for a while, now. Please, report any
issue you may find.

Additionally, the following dependencies of GTK+ have added a Meson
build side-by-side with Autotools:

  - GLib
  - Pango
  - GdkPixbuf
  - ATK
  - libepoxy

There are no plans for using Meson exclusively, or even side-by-side
with Autotools, on the 2.24 and 3.22 branches — at least for the
foreseeable future.

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 migration status and roadmap

[Emmanuele Bassi]

Considering that large repos on gitlab.com — like, say,
https://gitlab.com/gitlab-org/gitlab-ce/commits/master — are faster
than gitlab.gnome.org, I think the issue is on our end, unless
GitLab's enterprise edition is more optimised than the community
edition.

Ciao,
 Emmanuele.

On 14 August 2017 at 11:18, Richard Hughes  wrote:
> On 14 August 2017 at 10:02, Jens Georg  wrote:
>> I'm currently massively underwhelmed by the overall performance and
>> snappiness of the web interface, even for a small project with not that
>> much commit history.
>
> Right; I also found that when sitting In London browsing
> https://gitlab.gnome.org/GNOME/json-glib -- is the machine hosting the
> GitLab instance a proper server in a datacenter somewhere or is the
> demo being run from a test machine under someones desk? I don't want
> people's first reaction to be "this is kinda slow".
>
> Richard.
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: developer.gnome.org and meson

[Emmanuele Bassi]

On 9 August 2017 at 20:57, Sébastien Wilmet  wrote:
> On Wed, Aug 09, 2017 at 03:20:38PM +0100, Emmanuele Bassi wrote:
>> After all, Linux
>> distributions rebuild the documentation when building the binary
>> packages anyway
>
> I see that in the gspell-doc package on Fedora 26, some html pages have
> links to /home/seb/jhbuild/... (a problem with the gtkdoc-fixxref
> config). That's my home directory :-) so definitely Fedora didn't
> re-generate the docs

That's all kinds of broken — that's why distro re-generate the docs, typically.

> (and it would be painfully slow, it takes several
> hours on my machine to generate the GTK+ docs).

Distributions typically use something slightly more beefy than a
typical PC hardware for their builds.

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: developer.gnome.org and meson

[Emmanuele Bassi]

In the medium-to-long term, I'd really appreciate if
developer.gnome.org stopped trying to extract documentation from
random locations inside tarballs, munge the cross-references, and
published the HTML on a static website. This would avoid having to
generate documentation at all, except when needed. After all, Linux
distributions rebuild the documentation when building the binary
packages anyway, so shipping documentation in release tarballs is
pretty much for the benefit of developer.gnome.org to begin with.

Ideally, with the switch to Gitlab, we'd be able to run CI targets for
each module; that would allow us to build the API reference (and any
other documentation we deem worthy of publishing), ensure that the
cross-references pointed to a well-known URL prefix as part of the
build itself, and publish them when pushing a release tag.

Additionally, GitLab pages[0] would ensure that any module with
documentation would have it published, without necessarily teaching
developer.gnome.org how to do it.

Ciao,
 Emmanuele.

[0]: https://about.gitlab.com/features/pages/


On 9 August 2017 at 15:12, Bastien Nocera  wrote:
> On Wed, 2017-08-09 at 08:33 -0500, mcatanz...@gnome.org wrote:
>> Hi,
>>
>> developer.gnome.org is going to have some problems because for meson
>> modules 'ninja dist' does not include generated gtk-doc files in the
>> tarball. At least one maintainer is working around this by manually
>> generating tarballs with gtk-doc included instead of using 'ninja
>> dist'. I don't recommend doing that since that's equivalent to
>> skipping
>> distcheck. It's better to use meson's dist target.
>> developer.gnome.org
>> is just going to have to learn to build docs itself.
>>
>> Is anybody working on developer.gnome.org? Anyone interested in
>> taking
>> on this task? Otherwise it is going to be stuck with outdated docs.
>
> I filed this:
> https://github.com/mesonbuild/meson/issues/2166
>
> I don't know whether that's something we'd want longer term, but it's a
> win short-term.
>
> Cheers
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: JHBuild

[Emmanuele Bassi]

On 1 August 2017 at 09:16, Alberts Muktupāvels
 wrote:

> is there anything that could be done to make building with JHBuild better?

Maintainers taking ownership of the things in the modulesets would help.

> jhbuild build
> This command I use at least few times in week and almost always there are
> problems. :(

Well, yes: you are, effectively, doing CI on GNOME infrastructure.

We should have a better CI story, at this point.

Additionally, this week most of the maintainers community in GNOME is
at GUADEC, and connectivity has been spotty, so I'd still consider
this week an outlier.

> This time it failed quite fast with build failure in pango. New source files
> was added to Makefile.am, but not to meson.build. If project has decided to
> support both then please test build with both build systems.

Pango is build with Meson on Continuous, and I noticed you fixed the
build when it failed. I'm completely up for dropping Autotools, but
yes: potential breakage of having two build systems in parallel is to
be expected until we can do per-module CI and build with both.

> Fixing that did not help a lot... Now colord fails to build. It is ported to
> meson, but no one has updated jhbuild modulesets. Can someone please update
> it?

I can, but now I can't build colord because the Meson port does not
follow the Autotools base, which means some things are forcibly
required and not disabled.

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: New upstream repo for json-glib

[Emmanuele Bassi]

Thanks Carlos, very much appreciated.

I think it'd be good to have those guidelines — which are, in essence,
the same guidelines that exist today for creating a new repo on
git.gnome.org — published on the wiki.

Ciao,
 Emmanuele.


On 10 July 2017 at 19:26, Carlos Soriano  wrote:
> Hey all,
>
> With permission of Emmanuele and following the guidelines we wanted,
> json-glib is part of the GNOME group now. So the url is
> https://gitlab.gnome.org/GNOME/json-glib
>
> Best,
> Carlos Soriano
>
> On Mon, Jul 10, 2017 at 5:30 PM, Emmanuele Bassi  wrote:
>>
>> Before somebody asks: yes, I'll keep pushing to both the old repo on
>> git.gnome.org and the new one on gitlab.gnome.org until the former
>> gets moved to the attic.
>>
>> Ciao,
>>  Emmanuele.
>>
>> On 10 July 2017 at 16:28, Emmanuele Bassi  wrote:
>> > Hi all;
>> >
>> > JSON-GLib authoritative Git repository has been moved to the Gitlab
>> > instance on gitlab.gnome.org:
>> >
>> >   https://gitlab.gnome.org/ebassi/json-glib/
>> >
>> > as part of the pilot for the Gitlab migration.
>> >
>> > I will also move the issue tracker from Bugzilla to Gitlab itself, as
>> > soon as I have a full test run of the migration. In the meantime, feel
>> > free to keep using Bugzilla.
>> >
>> > Ciao,
>> >  Emmanuele.
>> >
>> > --
>> > https://www.bassi.io
>> > [@] ebassi [@gmail.com]
>>
>>
>>
>> --
>> 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
>
>



-- 
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: New upstream repo for json-glib

[Emmanuele Bassi]

Before somebody asks: yes, I'll keep pushing to both the old repo on
git.gnome.org and the new one on gitlab.gnome.org until the former
gets moved to the attic.

Ciao,
 Emmanuele.

On 10 July 2017 at 16:28, Emmanuele Bassi  wrote:
> Hi all;
>
> JSON-GLib authoritative Git repository has been moved to the Gitlab
> instance on gitlab.gnome.org:
>
>   https://gitlab.gnome.org/ebassi/json-glib/
>
> as part of the pilot for the Gitlab migration.
>
> I will also move the issue tracker from Bugzilla to Gitlab itself, as
> soon as I have a full test run of the migration. In the meantime, feel
> free to keep using Bugzilla.
>
> Ciao,
>  Emmanuele.
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]



-- 
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

New upstream repo for json-glib

[Emmanuele Bassi]

Hi all;

JSON-GLib authoritative Git repository has been moved to the Gitlab
instance on gitlab.gnome.org:

  https://gitlab.gnome.org/ebassi/json-glib/

as part of the pilot for the Gitlab migration.

I will also move the issue tracker from Bugzilla to Gitlab itself, as
soon as I have a full test run of the migration. In the meantime, feel
free to keep using Bugzilla.

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: Meson feedback as a user

[Emmanuele Bassi]

On 2 July 2017 at 17:02, Philip Withnall  wrote:
> On Sun, 2017-07-02 at 15:37 +0000, Emmanuele Bassi wrote:
>>
>> On Sun, 2 Jul 2017 at 16:29, Sébastien Wilmet 
>> wrote:

>> There is a subset of warnings you want for C - and those should go in
>> Meson's warning_level option. Differently projects have very
>> different requirements: there is no "one size fits all" or alias for
>> an ever changing set of warnings - otherwise we'd all run with
>> -Wextra and -Werror.
>
> The statements
> “There is a subset of warnings you want for C”
> and
> “there is no "one size fits all" or alias for an ever changing set of
> warnings”
> seem to be incompatible.

I was on my phone, so there's a missing "small" from "there is a subset".

The minimal subset of warnings is basically -Wall, considering that
GCC tends to promote new warnings in there across versions, as well as
adding them to -Wextra. Anything else is negotiable, and needs to be
validated against the current project code base on different
platforms, compilers, and versions of the compiler, before toggling
it.

If you want to have a blanket option, use Meson's 'warning_level=2' or
'warning_level=3', and then be prepared to battle against compiler
changes, as well as dependency changes.

> AX_COMPILER_FLAGS is meant to provide that
> ‘subset of warnings you want for C’. If you think the set of warnings
> it enables is incorrect, please bring that up with me (in a different
> ML thread, I don’t want to take this one off topic).

I don't think we are ever going to agree on the usefulness of
AX_COMPILER_FLAGS, so I'd rather not waste anybody's time.

My point is:

 - use 'warning_level' in Meson to enable different compiler warnings
 - if you want to add compiler flags to Meson, submit a patch for the
existing 'warning_level' option so that the options are per-platform,
per-compiler, and per-language
 - considering the amount of compiler flags that are per-project, and
the maintenance burden they impose on maintainers, newcomer
developers, and CI, I'd rather you figured out the list of warnings
*you* need and, especially, that *you* are willing to commit to,
instead of a blanket option that requires disabling for everyone while
you figure out how to fix a code base

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: Meson feedback as a user

[Emmanuele Bassi]

On Sun, 2 Jul 2017 at 16:29, Sébastien Wilmet  wrote:

> On Sun, Jul 02, 2017 at 03:21:51PM +0100, Sam Thursfield wrote:
> > On Sun, Jul 2, 2017 at 1:27 PM, Sébastien Wilmet 
> wrote:
> > > Out of curiosity, let's look at other GNOME-related modules that use
> > > gtk-doc. What is the name of the option that enables gtk-doc?
> > > - pango:enable_docs
> > > - gtk+: enable-documentation
> > > - graphene: enable-gtk-doc
> > > - atk:  enable_docs
> >
> > We should indeed work to make these names consistent across GNOME
> > modules. Having a page on the wiki where we list standard option names
> > for Meson build systems would be a good start.
>
> To make the names consistent, the best way is to write the name in only
> one place, i.e. in meson itself or a meson function/macro. Not in each
> individual modules.
>
> Like the GTK_DOC_CHECK Autotools macro.


Currently, Meson modules cannot define options, but it's something that
would be useful, and AFAIR there's an issue opened about it.

>
> The same for compiler flags, with the Autotools there is the
> AX_COMPILER_FLAGS macro. With meson it seems that the flags are listed
> in each GNOME module.


On the other hand, having a common set of warnings is broken and it
demonstrably does not work, as I've found after having to fix the various
modules that were moved to AX_COMPILER_FLAGS.

There is a subset of warnings you want for C - and those should go in
Meson's warning_level option. Differently projects have very different
requirements: there is no "one size fits all" or alias for an ever changing
set of warnings - otherwise we'd all run with -Wextra and -Werror.

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: Pilot GitLab program

[Emmanuele Bassi]

Please, let's stop this fetish about non-ff merges.

If you like non-ff merges and linear history it's entirely up to your
taste. Nothing "gets confused" about merge commits, and if your
tooling gets confused then I strongly urge you to get better tools —
which is the whole point of switching to GitLab.

Ostensibly, the whole GitHub userbase gets along with it just fine,
and that is larger than the GNOME contributors base by many, many
factors of ten.

Let's not confuse a personal maintainer preference with a technical difficulty.

Ciao,
 Emmanuele.


On 27 June 2017 at 14:08, Michael Catanzaro  wrote:
> On Tue, Jun 27, 2017 at 3:54 AM, Carlos Soriano  wrote:
>>
>> Expect Nautilus and librsvg (with Federico) to move to the pilot program
>> this week.
>
>
> Cool. I would just suggest making sure that your interns are careful not to
> push a non-ff merge (i.e. not to use merge requests), since that will
> confuse nautilus's git history until the end of time. A server hook to block
> this would be useful, since I expect the number of projects that want linear
> history is much higher than the number of projects that want to allow merge
> commits.
>
> Michael
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: Proposal to deploy GitLab on gnome.org

[Emmanuele Bassi]

On 23 May 2017 at 13:21, Felipe Borges  wrote:

>> At least with GitHub and Gogs [1] it's possible to create merge requests from
>> a branch *in the same repository* (I use branches named 
>> “/”
>> now and then). If everybody who is a maintainer is going to have push access
>> in the GNOME GitLab instance, they can just push their branch to repository
>> and create the merge request from there — without needing to fork the
>> repository into their user space.
>
> Sure, but this creates a distinction between maintainers and other
> contributors, as I think Bastien mentioned before.

I honestly don't understand what the fuss is all about. This
"difference" already exists.

Either you have a Git account on git.gnome.org, in which case:
congrats, you can already push to a branch on GitLab without requiring
a forked repo; or you don't have it, in which case, *right now* you
need to create a separate public repo on some other hosting, or you
need to create a patch from a local clone and attach it somewhere.

With GitLab, on the other hand, in either cases you'll have a forked
repo on the *same* infrastructure.

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: Proposal to deploy GitLab on gnome.org

[Emmanuele Bassi]

On 16 May 2017 at 16:17, Germán Poo-Caamaño  wrote:

> Another potential pain point: in Bugzilla, one can move bugs between
> products. This happen when the bug has been reported to the wrong
> product, or when triaging the bugs the developers know the bug is
> somewhere else in the stack.
>
> Gitlab does not allow moving bugs between products. It is expected to
> be in 8.6 [1], but that is not for sure.

You can move issues between projects on the same instance, even with
the community edition.

The issue you link was closed a year ago after the merge. Release
8.6.0 of the community edition was released around the same time.

The latest 8.x release is 8.17.6, and the latest 9.x release is 9.1.6,
with 9.2.0 being in release candidate stretch.

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: Proposal to deploy GitLab on gnome.org

[Emmanuele Bassi]

On 16 May 2017 at 15:38, Alexandre Franke  wrote:
> On Tue, May 16, 2017 at 3:22 PM, Allan Day  wrote:
>> In recent months we have got together to examine the possibilities for
>> GNOME’s development infrastructure. We’ve spent a lot of time on this,
>> because we want the community to have faith in our conclusions. If you are
>> interested in this, you can read our research on the wiki [1].
>
> Excellent. I think most will agree it’s time we implement such changes.
>
>> The outcome of this evaluation process is that we are recommending that
>> GNOME sets up its own GitLab instance, as a replacement for Bugzilla and
>> cgit.
>
> This mail mentions Gitlab as the only alternative. I know some people
> suggested to consider Phabricator, yet your proposal doesn’t mention
> it and by the looks of the wiki pages your research has been focused
> around Gitlab. Now I know very little about both Gitlab and
> Phabricator so I won’t push or block anything, but I’m a bit worried
> that this wasn’t given enough scrutiny.

Phabricator was thoroughly investigated; the wiki page has whole
sections on it, including why we think it's not what GNOME needs. :-)

I use Phabricator at work (for issue tracking) and I honestly gave my
personal position about it, balanced against GitLab; additionally, we
consulted with Daniel Stone, who handled the transition between
Bugzilla and Phab at Collabora and on the FreeDesktop.Org
infrastructure. We even had Phacility very kindly provide us with a
test instance to play with.

The main issues with Phabricator is that its code hosting is kind of
primitive, and its workflow is heavily patch-oriented. You have to
create patch files and "attach" them to issues, instead of creating
branches and asking the maintainer to merge them.

From an issue tracking and project management perspective, Phabricator
is a winner in my eyes — but the requirements from GNOME are
definitely more oriented towards the code hosting and integration. As
much as I like working with Phab, I don't think it's a good fit for
GNOME.

This, of course, does not mean that we wouldn't be able to add a
Phabricator instance in the future; it would probably be easier to
migrate a pure GitLab set up to a GitLab + Phabricator, in any case.

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: For projects switching to Meson *only*

[Emmanuele Bassi]

Replying to both Michael's and Iain at the same time, to reduce the
amount of email.

On 27 April 2017 at 15:04, Michael Catanzaro  wrote:
> On Thu, Apr 27, 2017 at 4:11 AM, Iain Lane  wrote:
>>
>> As it happens I interacted with this script (in gnome-software)
>> yesterday. I hadn't got a new enough jhbuild - the one I had was trying
>> to call ./configure instead of meson directly.
>>
>> The script AFAICS ignores unknown arguments. In particular, I was
>> interested in passing some --enable/--disable flags to select features
>> but I didn't find out how to do that short of explicitly extending it
>> with those particular options. If you expect distributors to be using
>> this, or if this is interesting for users of the build API, is having
>> some support for ./configure <-> meson_options integration a reasonable
>> request?

Each module has its own set of options with their own name and
semantics; the build-api only defines a specific subset, so if you
want to have a `configure` script to paper over the Meson switch, you
also get to add the options you want to port over.

Mostly because if I end up patching this script into Continuous, then
I get to be the one who decides which options get ported over and
which one don't; maintainers of a project are usually best suited at
that.

For instance, the libinput maintainer has started dropping all
auto-detection checks and now the build relies on specifying all
options; a worthy goal, and I'd actually hope more modules followed
suit. If he also switched to Meson-only, I'd have to write a patch for
Continuous that manually ported over the build options as a
compatibility layer; I would do this only for the options Continuous
supports, though, and it would take me slightly more time than just
copying the file over.

>> Otherwise, and this is what happens now that I upgraded jhbuild, using
>> meson directly works fine. But if a goal of this is to smooth the
>> transition path and avoid a requirement for tooling to be updated, maybe
>> it would be useful.

Of course.

> This compatibility issue seems like a very good argument for shipping the
> "compatibility" script in Continuous patches rather than application
> repositories.

As I said, this takes me (in the absolute simplest case) about 90
seconds of my life, so I don't mind doing a patch.

I'd be happier, though, if maintainers that are planning to drop
autotools also dropped me a line so that I don't wake up to a string
of failed builds and then have to figure out whether or not this was a
planned break, or just general CI failure. *Especially* if the
maintainer also fixes the jhbuild moduleset.

So, I guess the real question is: communicate these changes
beforehand, instead of pushing to master and then going home without
looking at the explosion?

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: For projects switching to Meson *only*

[Emmanuele Bassi]

The issue is not writing a simple patch: it takes me about 90 seconds
of my life to copy the file, create a commit, format-patch it, and add
the patch to gnome-continuous.

The whole point would be to avoid adding a patch to Continuous.

Additionally, conforming to the build-api is a nice transitional tool
for distributors that are still trying to catch up to Meson.

Ciao,
 Emmanuele.


On 27 April 2017 at 09:48, Carlos Soriano  wrote:
> Hello Emmanuele,
>
> Would be fine if the maintainer does the patch for continuous instead of
> doing the build-API?
>
> Carlos Soriano
>
>  Original Message 
> Subject: For projects switching to Meson *only*
> Local Time: 27 April 2017 10:45 AM
> UTC Time: 27 April 2017 08:45
> From: eba...@gmail.com
> To: Desktop Development List 
>
> Hi everyone;
>
> since maintainers have started switching to Meson for the development
> cycle (awesome!) I'd like to ask for a favour: if you're dropping
> autotools entirely, could you please add a `configure` wrapper script
> that conforms to the build-api[1] that GNOME Continuous uses?
>
> A simple script is available here[2], and it has nice properties, like
> being able to work with a simple:
>
> ./configure
> make
> sudo make install
>
> which makes distributors and integrators happy.
>
> Before you ask: yes, I'm looking at adding Meson support to
> Continuous, as part of a larger rework of the manifest file to adapt
> to the Flatpak builder manifest format; that will take time, though,
> so in the interim it'd be great if we didn't have to ship a patch for
> every project, when the alternative is simply dropping a script into
> the project's top-level.
>
> Ciao,
> Emmanuele.
>
> [1]: https://github.com/cgwalters/build-api
> [2]: https://github.com/ebassi/graphene/blob/master/configure
>
> --
> 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
>
>



-- 
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

For projects switching to Meson *only*

[Emmanuele Bassi]

Hi everyone;

since maintainers have started switching to Meson for the development
cycle (awesome!) I'd like to ask for a favour: if you're dropping
autotools entirely, could you please add a `configure` wrapper script
that conforms to the build-api[1] that GNOME Continuous uses?

A simple script is available here[2], and it has nice properties, like
being able to work with a simple:

  ./configure
  make
  sudo make install

which makes distributors and integrators happy.

Before you ask: yes, I'm looking at adding Meson support to
Continuous, as part of a larger rework of the manifest file to adapt
to the Flatpak builder manifest format; that will take time, though,
so in the interim it'd be great if we didn't have to ship a patch for
every project, when the alternative is simply dropping a script into
the project's top-level.

Ciao,
 Emmanuele.

[1]: https://github.com/cgwalters/build-api
[2]: https://github.com/ebassi/graphene/blob/master/configure

-- 
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

Removing libgdict from GNOME Dictionary

[Emmanuele Bassi]

Hi all;

this is an advance warning: I'm planning to make libgdict a private
library in GNOME Dictionary, and not install it any more.

It's been more than 10 years, and nobody has been using it anywhere;
additionally, a DICT protocol client is clearly of little use in 2017.

I plan to drop libgdict starting from GNOME Dictionary 3.25.1, which
is the current master branch.

If you maintain a distribution package for GNOME Dictionary, you'll
want to ensure that installing GNOME Dictionary ≥ 3.25.1 will also
remove any libgdict package.

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: Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

On 3 April 2017 at 19:38, Nicolas Dufresne  wrote:
> Le dimanche 02 avril 2017 à 14:59 +0100, Emmanuele Bassi a écrit :
>> Yes, I know: this would be slightly more easier if Continuous warned
>> about build breakages via email (though I'm pretty sure email would
>> still be a high latency medium that tends to be ignored);
>> nevertheless, joining the #testable IRC channel *today* to get a
>> notification of build failure is *not* a heavy burden — especially
>> now
>> that we have the Matrix bridge and you don't even need an IRC client
>> running at all times.
>
> Is this important for projects that already have their own CI system ?
> (notably GStreamer). It does seems like an overhead to track two CI, I
> do believe that build breakage due to warning should be quite rare in
> GStreamer case. Please let us know.

If you have your own CI then, by all means: keep watching your own CI. :-)

GStreamer is fairly well-behaved, and it's rare that I have to hunt
down people on IRC, or file a bug for it.

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: Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

On 2 April 2017 at 19:20,   wrote:

> My understanding was the objection was against using Werror as the default
> while _not_ paying attention to the CI notifications. Please correct me if
> I've misunderstood this.

That is correct.

If the goal of:

 - enabling -Werror by default when building from Git
 - passing --disable-Werror by default for new jhbuild users

is relying on a CI/CD pipeline to proactively fix build issues caught
by -Werror, then people opting into this by using autotools macros
should *really* be looking at the Continuous pipeline state. We have
old school "push notifications" in the form of the #testable IRC
channel (and the build state gets also relayed to #gnome-hackers on
success/failure transitions).

If you don't care about this kind of things then, by all means:
disable errors by default in your modules.

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: Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

On 2 April 2017 at 18:16, Michael Catanzaro  wrote:
> On Sun, 2017-04-02 at 15:59 +0100, Emmanuele Bassi wrote:
>> Adding:
>>
>>   disable_Werror = False
>>
>> to your jhbuildrc should do the trick.
>
> Ah, but nobody wants to do that for all modules locally... I only want
> it for Epiphany.

Adding this:

```
module_autogenargs['epiphany'] = '--disable-Werror'
```

should work, assuming Epiphany uses the m4 macros that add `--disable-Werror`.

Maybe jhbuild could have a:

```
module_disable_Werror['epiphany'] = True
```

but at this point we're sliding into diminishing returns, as it
doesn't buy you much.

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: Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

On 2 April 2017 at 16:44, Sébastien Wilmet  wrote:
> On Sun, Apr 02, 2017 at 03:59:39PM +0100, Emmanuele Bassi wrote:
>> The point of my email was, though, that people should be keeping an
>> eye on their modules on the CD pipeline.
>
> It's easier to keep an eye on our local compilation output, and rebuild
> from time to time the dependencies in jhbuild.

Sure, it's "easier" for some people: out of sight, out of mind.

It's also broken, because it relies on humans to do the work of machines.

> GNOME Continuous is useful to detect as early as possible real build
> breakages (a FTBFS *with* --disable-Werror).

> Or determining the culprit
> commit when a unit test starts to fail (and possibly cross-modules, e.g.
> a commit in gtk that makes an app unit test to fail).

You seem to misunderstand what a continuous delivery/continuous
integration pipeline is for.

The whole point of CD/CI is to detect issues early, even before unit
testing fails. Compilation warnings are just a prelude to additional
issues down the line. Otherwise, why using them at all? You can build
with all the compilation warnings turned off already and not care at
all.

If you specifically enable compilation warnings, and then go to the
extra length of enabling -Werror by default, then it means you do care
about them. Caring about them, though, does not stop at the boundary
of your Git repository; that's why we have a continuous delivery
platform: to figure out the impact of changes between modules, and to
ensure that a whole set of modules builds correctly.

Disabling -Werror in Continuous would make *my* life easier — I
wouldn't have to file bugs or tag modules; it would also defeat the
point of having Continuous in the first place.

So, *please*: be proactive, and use the notifications from the
Continuous builder to know if your module is affected, instead of
waiting on a bug to be filed.

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: Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

On 2 April 2017 at 15:53, Michael Catanzaro  wrote:
> On Sun, 2017-04-02 at 14:59 +0100, Emmanuele Bassi wrote:
>> I know that the effort to use -Werror by default is well-intentioned,
>> and ordinarily I'm in favour of maintainers catching errors locally
>> before pushing code to the public repository.
>>
>> In practice, though, this effort has been insufficient, when not
>> misguided. In order to appeal to newcomers, and to avoid pain to new
>> contributors, jhbuild builds with --disable-Werror; again, entirely
>> in
>> favour of this approach. The rationale given for this was that we
>> would catch errors through the Continuous pipeline — especially when
>> these errors are caused by modules early in the dependency chain.
>
> So with Epiphany the desired behavior is:
>
>  * Developers (by default, anyone using a git checkout) get -Werror
>  * Users (by default, anyone using a tarball or JHBuild) don't
>
> I like it, but it's not perfect because in practice all developers use
> JHBuild, and all my attempts to re-enable Werror from jhbuildrc have
> failed.

Adding:

  disable_Werror = False

to your jhbuildrc should do the trick.

> So I think the only people getting -Werror by default are
> people who actually don't want it.
>
> Simplest solution would be for Continuous to just pass --disable-Werror
> to configure.

Which is what I would rather not do at all, because then *nobody* will
actually fix compiler warnings.

I would probably add:

  -Wno-error=deprecated-declaration

to the default flags, especially during development, considering that
deprecations are not an immediate issue to be fixed, but that would
likely have the fallout of nobody fixing deprecation warnings; not
that it matters much: we still have various bits of our platform using
GSimpleAsyncResult instead of GTask, and that has been deprecated for
more than 2 years.

The point of my email was, though, that people should be keeping an
eye on their modules on the CD pipeline.

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

Do not use -Werror by default in your modules without joining #testable

[Emmanuele Bassi]

Hi all;

I know that the effort to use -Werror by default is well-intentioned,
and ordinarily I'm in favour of maintainers catching errors locally
before pushing code to the public repository.

In practice, though, this effort has been insufficient, when not
misguided. In order to appeal to newcomers, and to avoid pain to new
contributors, jhbuild builds with --disable-Werror; again, entirely in
favour of this approach. The rationale given for this was that we
would catch errors through the Continuous pipeline — especially when
these errors are caused by modules early in the dependency chain.

This, by and large, has *not* happened. Maintainers do not realise
things break when they build locally, and since they do not keep an
eye on the Continuous build, they are completely unaware of breakage
further down the line.

Yes, I know: this would be slightly more easier if Continuous warned
about build breakages via email (though I'm pretty sure email would
still be a high latency medium that tends to be ignored);
nevertheless, joining the #testable IRC channel *today* to get a
notification of build failure is *not* a heavy burden — especially now
that we have the Matrix bridge and you don't even need an IRC client
running at all times.

If you decide to automatically enable -Werror in your modules by
following this wiki page:

  https://wiki.gnome.org/Projects/GnomeCommon/Migration

Then, *please*: keep an eye on the Continuous build by joining the
#testable IRC channel on irc.gnome.org. The channel only contains
build messages (and the occasional discussion/rant about CD/CI), so
you don't even need to keep a close eye on it. Just ensure you notice
if your module builds correctly; I will typically ping you, just in
case.

Please, ensure that we can keep GNOME building correctly for everyone
at all times.

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: Brasero shouldn't look for dvdcss_inerface_2

[Emmanuele Bassi]

Thanks Jeremy; I left a comment there.

Ciao,
 Emmanuele.

On 26 March 2017 at 14:22, Jeremy Bicha  wrote:
> On Sun, Mar 26, 2017 at 9:19 AM, Emmanuele Bassi  wrote:
>> thanks for the patch. Would it be possible for you to attach it to a
>> bug on Bugzilla?
>
> The tracking bug is https://bugzilla.gnome.org/show_bug.cgi?id=744916
>
> Thanks,
> Jeremy Bicha



-- 
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: Brasero shouldn't look for dvdcss_inerface_2

[Emmanuele Bassi]

Hi;

thanks for the patch. Would it be possible for you to attach it to a
bug on Bugzilla?

You can use:

  https://bugzilla.gnome.org/enter_bug.cgi?product=brasero

As far as I can see, the code always looked for the
`dvdcss_interface_2` symbol since its inclusion in the repository, but
since the DVDCSS plugin dlopen()s the library instead of linking
against it (and since lots of distributions cannot ship libdvdcss in
order to comply with legal requirements), nobody noticed the breakage.

Ciao,
 Emmanuele.


On 26 March 2017 at 10:12, Que Quotion  wrote:
> I am aware that brasero has been left unmaintained for quite some time. It
> still happens to be a very useful program with the exception of one
> bug--failing to find libdvdcss because it checks for a symbol,
> dvdcss_interface_2, which was dropped from libdvdcss about three years ago.
> https://code.videolan.org/videolan/libdvdcss/commit/8331d8da6392b993f7b0ffa223d8d7a3ccd7f0ae
>
> Several distributions are already patching around this in their packaging:
> Ubuntu -
> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/1577268/comments/4
> Debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800833#12
> Fedora - https://bugzilla.redhat.com/show_bug.cgi?id=1193628I
>
> If anyone has a moment, and the authority, to patch this in it would be
> much appreciated.
>
> --- brasero-3.12.1/plugins/dvdcss/burn-dvdcss.c
> +++ brasero-3.12.1/plugins/dvdcss/burn-dvdcss.c
> @@ -95,8 +95,6 @@
>  if (!module)
>  goto error_doesnt_exist;
>
> -if (!g_module_symbol (module, "dvdcss_interface_2", &address))
> -goto error_version;
>
>  if (!g_module_symbol (module, "dvdcss_open", &address))
>  goto error_version;
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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

JSON-GLib changed build system in master

[Emmanuele Bassi]

Hi all;

today I branched off JSON-GLib; the stable branch is json-glib-1-2 and
the latest release is 1.2.8.

The master branch is 1.3.1, and will become 1.4.0 at some point in the
future. Additionally, the maste branch now builds only with Meson and
Ninja. I've added a simple `configure` script wrapper that takes care
of the build-api[0] compatibility layer (mostly for Continuous).

The last couple of releases in the 1.2.x series have been used to
verify that the build generated via Autotools and the one generated
via Meson will be equivalent, but if you have automated tools that
complain about changes feel free to open bugs against json-glib, and
I'll make sure to fix them.

Ciao,
 Emmanuele.

[0]: https://github.com/cgwalters/build-api

-- 
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: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)

[Emmanuele Bassi]

Thanks ever so much for this work, Matthew. It's really a great
addition to the communication channels for GNOME, and hopefully people
will start using Matrix much more. :-)

Ciao,
 Emmanuele.

On 2 March 2017 at 19:32, Matthew Hodgson  wrote:
> On 03/02/2017 15:57, Matthew Hodgson wrote:
>>>
>>> On 3 Feb 2017, at 13:00, Alexandre Franke 
>>> Matthew, anything blocking the bridging on our side?
>>
>>
>> Nothing blocking at all; it's all on our side, which has ended up
>> blocked on FOSDEM - we've had to prioritise a sprint to ship new
>> releases for FOSDEM and are currently all on trains to Brussels. It's
>> top of the IRC bridging backlog and we should get to it early next
>> week. Sorry for the delay...
>
>
> Hi all,
>
> We've finally set up a bridge hosted by matrix.org that links GIMPNet into
> Matrix (as per the earlier bits of this thread).  Sorry that it took so long
> to happen: FOSDEM ended up being even crazier than we expected, and we've
> spent the last month handling the traffic increases and operational
> excitements that came off the back of it.
>
> The bridge has been set up to provide access to all of GIMPNet through
> matrix room aliases of form:
>
>  #_gimpnet_${channelname}:matrix.org
>
> e.g.
>
>  #_gimpnet_#gtk+:matrix.org
>
> The easiest way to use the new bridge is probably through Riot, the current
> flagship Matrix client: URLs for direct access to a room via riot-web are of
> the form:
>
> https://riot.im/app/#/room/#_gimpnet_#gtk+:matrix.org
>
> You can also join using "/join #_gimpnet_#gtk+:matrix.org" style syntax, or
> using the graphical room directory (button linked from the bottom left).
>
> We haven't turned on guest access on the bridge, so users are forced to
> register an account (and go through a captcha) before joining channels.
>
> You can spot folks connecting via Matrix as by default they have a [m]
> suffix on their nickname.
>
> Feedback very welcome!  We are still in beta, and very interested in making
> sure it fits the bill for communities like GNOME :)
>
> Matthew
>
> --
> Matthew Hodgson
> Matrix.org
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
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: GNOME goal candidates

[Emmanuele Bassi]

On 1 March 2017 at 13:26, Michael Catanzaro  wrote:
> It sounds like most everyone else supports installed tests. OK, then.
>
> On Wed, 2017-03-01 at 10:22 +, Philip Withnall wrote:
>> I agree that developers need to be engaged with adding more unit
>> tests
>> and code coverage if such a goal is to be useful. I wonder if making
>> it
>> a goal would kick-start some people to do that? I don’t think we can
>> ever expect the majority of maintainers to care about (or have enough
>> time to care about) code coverage and unit testing — but GNOME goals
>> have been useful catalysts in the past. I guess a suitably well
>> publicised and tutorialised blog post would work just as well though.
>>
>
> This is the other thing. The goals should be achievable, something we
> can look at in a year or two and say "all apps meet the goal" and close
> it, not a longstanding epic that stays open forever. The installed
> tests and coverage goals do not really qualify. Even though more tests
> are definitely desirable, I don't think it's reasonable to use the
> GNOME Goals project for this, even if it would be nice to see as many
> projects as possible adopting it.
>
> Maybe I am being too negative here. It does seem odd to say that doing
> something desirable should not be a goal. But a longstanding pie-in-
> the-sky project is very different from existing goals. Switching to
> g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
> all apps should be able to accomplish easily. Adding a comprehensive
> testsuite, not so much. And adding just one or two installed tests,
> while a good starting point, is not very useful on its own.

At some point, Gnome Goals become "best practices for GNOME projects"
— especially because new projects should conform to these goals by
default.

I'm all for taking all the present and past GNOME Goals pages on the
wiki and turning them into "Best Practices for GNOME projects" — where
applicable. Additionally, every cycle we can evaluate where we are on
the completion of every goal, and if the completion rate passes a
certain threshold we simply close the goal and move the page to the
"best practices" section.

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