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]

Hi all;

This email is cross-posted to Discourse:

  https://discourse.gnome.org/t/new-gnome-versioning-scheme/4235

Please, use Discourse to ask further questions or clarifications.

After various off-line/in person talks, last year I started [a
discussion][0] on Discourse about the existing version scheme of GNOME.
[This topic][1] was also raised in July, and discussed at the release team
meeting during GUADEC. Now that the GNOME 3.37 development cycle is over,
and 3.38 is out of the door, it's time to draw this issue to its conclusion.

In the interest of clarity, I'll present the conclusion first, and then try
to answer common questions. The questions summarise the feedback and
iterations of the change; feel free to read the whole topic on Discourse if
you wish to understand what led to the final form of this change.

## The new GNOME versioning scheme

The next version of GNOME, due to be released in March 2021, will be GNOME
40.

The GNOME 40 development cycle will have three releases:

 - 40.alpha
 - 40.beta
 - 40.rc

Followed by the first stable release, 40.0. Every subsequent stable release
will increment the minor component by 1, so:

 - 40.1, 40.2, 40.3, …

After the 40.0 release in March 2021, the next version of GNOME will be 41,
and will follow the exact same pattern.

To recap:

 - the new versioning scheme starts at 40
 - each new development cycle will increment the version by 1
 - each development cycle will have three releases: alpha, beta, rc
(release candidate)
 - the first stable release will have a minor version of 0
 - each stable release will increment the minor version by 1

## Adopting the new versioning scheme

The new version will be visible in the following components:

 - the "GNOME version" field of the "About" section in GNOME Control Center
 - the version of GNOME in the Tour application
 - the application version in the "About" dialog of core GNOME applications

Additionally, the version of the SDK and Platform run times will follow the
same versioning scheme, so you will depend on, for instance,
org.gnome.Platform//40.

If you maintain an application that is not in the list above, then you can
keep following your own versioning scheme.

Libraries in the platform are not expected to change their existing
versioning scheme, but they are still expected to follow the release
cadence of GNOME, with *at least* an alpha, beta, and rc releases.

If your GNOME core application provides an API—for instance, for
plugins—you can version the programming interface however you prefer, as
long as the user visible version of the application follows the GNOME
scheme.

## Frequently Asked Questions

Q: Why do we need a new versioning scheme?
A: After nearly 10 years of 3.x releases, the minor version number is
getting unwieldy. It is also exceedingly clear that we're not going to bump
the major version because of technological changes in the core platform,
like we did for GNOME 2 and 3, and then piling on a major UX change on top
of that. Radical technological and design changes are too disruptive for
maintainers, users, and developers; we have become pretty good at iterating
design and technologies, to the point that the current GNOME platform, UI,
and UX are fairly different from what was released with GNOME 3.0, while
still following the same design tenets.

Q: Why start at 40?
A: Because the next version would be 3.40, and it's a nice, round number.
The 3.38 release was the 40th release of GNOME, but this discussion came
too late in the cycle to effectively switch, so we can say that, if you
start counting at zero, the next cycle would be the 40th release of GNOME.
By using 40 as the base, we acknowledge what came before, and we don't
introduce a large discontinuity in the number progression, which is
somewhat the point of this change.

Q: Why not 4.0?
A: With GTK 4.0 being released during the next development cycle, calling
the next version of GNOME "4.0" would have unfortunate/unintended
implications about the platform, especially from an engagement and
marketing perspective. We want to decouple GNOME from deep changes in the
application development platform, so that GTK can be released more often,
and [provide "long term support" major versions][2], instead of delaying
development cycles that inevitably end up into "rewrite the world" events.
GNOME is not just a technological platform, but also a set of design
guidelines and an [ethos][3], and bumping the major version along with GTK
does not reflect that.

Q: Why not using the year/month scheme?
A: While date-based versioning schemes do make it easier to resolve the
issues of "when was this version of GNOME released" and "how old is my
version of GNOME compared to the latest one", they still rely on knowing
that the version number is, indeed, date based. Even the "gold standard" of
date-based releases, Ubuntu, has users confused about the version numbers,
as outlined in multiple topics on different user support forums.

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 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 +, 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, because
every one of your emails is a demonstration that nobody should use GOA at
all, unless it's a system service like the Shell which has no UX for
authorising access to things like the Calendar.

Not only you have been lashing out at everyone in this thread that told you
something you didn't like to the point of throwing out wild accusations of
slander 

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 

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