Let's update our doaps!

[mcatanzaro]

Hi,

Please take a moment to look through your .doap files and remove any 
old/inactive maintainers, or switch them from  tags to 
 tags. There seem to be many projects just adding new 
maintainers but never removing old ones, as if in fear of perhaps 
offending the former maintainers. But it would be helpful for release 
team to keep the doap updated.


Thanks,

Michael

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

Re: Changes: GNOME 3.35/3.36 release schedule

[mcatanzaro]

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

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


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


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


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


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


Michael


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

Re: Changes: GNOME 3.35/3.36 release schedule

[mcatanzaro]

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

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

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


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

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


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


Michael


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

Re: GNOME 3.33.92 (GNOME 3.34rc2) RELEASED

[mcatanzaro]

On Fri, Sep 6, 2019 at 6:56 PM, Javier Jardón  
wrote:

the final release is scheduled next Wednesday!


Oops, it will really be Thursday, September 12. The release was 
originally scheduled for Wednesday because I'm bad at picking good 
dates. You might still have stale calendar events scheduled for 
Wednesday; please disregard them.



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

Re: Epiphany memory corruption problem

[mcatanzaro]

On Tue, Sep 3, 2019 at 6:45 AM, Bastien Nocera  
wrote:

Maybe release 3.32.x as a 3.34 instead if that's the problem?


We absolutely could, but have no way to know where the memory 
corruption was actually introduced.


It could be an Epiphany regression (not unlikely). But it could also be 
a WebKit regression (more likely) or even a GTK regression (less 
likely). Re-releasing Epiphany 3.32 won't solve anything unless we're 
sure it's an Epiphany problem, and I think the chances of that are only 
~40% (just guessing).


Since the memory corruption is not reproducible, we can't easily 
determine where the problem is without actually catching it in 
valgrind/asan.


There's actually multiple problems, at least one in the UI process, and 
a different memory corruption problem in the web process (which is 
less-likely to be Epiphany's fault, but still could be).


Really, without being able to catch the problem with valgrind/asan, 
it's too hard to know.


Michael


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

Re: Epiphany memory corruption problem

[mcatanzaro]

On Sat, Aug 17, 2019 at 4:41 PM, mcatanz...@gnome.org wrote:
The bug report shows valgrind crashes on startup. I've tried to get a 
working asan build of Tech Preview, but haven't been successful.


If anyone is willing to help with asan, that would be great. 
Unfortunately we never solved this and our 3.34 is going to be crashy 
and bad. :( The only hope I see is to deploy asan in our Tech Preview 
stream.



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

Hard code freeze is here ❄

[mcatanzaro]

Hi developers,

As of 45 minutes ago, we are now in hard code freeze for GNOME 3.34.0! 
No further code changes may be made without permission from release 
team.


The goal of this freeze is to improve the quality of GNOME 3.34. If you 
think a code change will improve quality, has low risk of regression, 
and is important enough that it shouldn't wait until 3.34.1, then 
please don't hesitate to mail  to ask for an 
exception. We don't bite. (Usually. ;)


Now go take a break from developing! You've earned it! Just don't 
forget the 3.34.0 tarball deadline on next Monday, September 9.


Thanks for making GNOME 3.34 great,

Michael


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

Re: Epiphany memory corruption problem

[mcatanzaro]

Eh, perhaps bad timing, but I was just running valgrind over geary 
after a geary crash, and noticed:


https://bugs.webkit.org/show_bug.cgi?id=199295

which I had totally forgotten about.

I don't know whether that's our problem or not, but probably no sense 
in worrying about mystery memory corruption before fixing the problem 
we know about. Sorry for the noise.



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

Epiphany memory corruption problem

[mcatanzaro]

Hi,

Epiphany 3.34 is going to be a pretty crashy release, because we've 
developed a memory corruption problem that seems almost impossible to 
debug:


https://gitlab.gnome.org/GNOME/epiphany/issues/876

The bug report shows valgrind crashes on startup. I've tried to get a 
working asan build of Tech Preview, but haven't been successful.


So I'm out of ideas. I really hate memory corruption. I'm afraid the 
solution here might be to give up, but if anyone has any ideas, I'm all 
ears.


Michael


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

Re: Proposal: earlier tarball deadlines

[mcatanzaro]

On Fri, Aug 16, 2019 at 10:39 pm, Alexandre Franke  
wrote:

Indeed. Moreover, in my experience, many maintainers consciously leave
that time for translators and check the status of their module on
Damned lies to see if there’s any team currently working on it and
whether they need to wait just a tiny bit longer for that language to
land in time. Kudos to all of those who do that, it is greatly
appreciated.


Hm. We could solve this problem with a "translation deadline" set, say, 
two or three days before tarball deadline. Maintainers shouldn't 
release until after the translation deadline is passed, so any 
translations committed by that date would be guaranteed to get in. E.g.:


Wednesday: translation deadline
Thursday: first day to release
Saturday: tarball deadline
Wednesday (week two): overall release deadline

This wouldn't be needed after the .0 release (since we're in string 
freeze) or for early development releases... maybe only for the .0 
release? Or from [.90-.0]? I guess we could have it for every release, 
but that makes the schedule significantly more complex.


Just brainstorming.


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

Re: Proposal: earlier tarball deadlines

[mcatanzaro]

On Fri, Aug 16, 2019 at 7:31 pm, Alexandre Franke  
wrote:

Weekends are usually the time when most translations get done. If you
remove this opportunity, I guess we should consider freezing earlier
too so that translators basically get the same amount of time to do
their job.


I'm a bit confused by this argument, because Monday is only the 
deadline, the last-possible day to release, not a recommended day. I'm 
going to do my 3.33.91 releases today most likely, or maybe tomorrow. 
Waiting until the deadline is very stressful IMO.


Personally, my favorite time to release is right after the release 
reminder gets sent out (Thursday night in America). But of course any 
time before the tarball deadline is fine for release team.



Weekends are usually the time when most translations get done. If you
remove this opportunity, I guess we should consider freezing earlier
too so that translators basically get the same amount of time to do
their job.


Yeah the freezes would surely move with the tarball deadline. There's 
no need to change that.


Michael


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

Proposal: earlier tarball deadlines

[mcatanzaro]

Hi,

I'd like to propose moving tarball deadlines for the 3.36 cycle one 
business day earlier, from Mondays to Fridays, while leaving the 
overall release deadline on Wednesday. That way, we can have the 
weekend for trying to build the release. This will allow release team 
more time to resolve build failures, hopefully making the job less 
stressful for us. It should also help us avoid late releases. Currently 
we're not able to begin building the release before Monday night 
(American timezones) or Tuesday morning (European timezones), which has 
led to several late releases on Thursday, Friday, and occasionally even 
later. Managing a release is usually a full-day task at least, and 
doing this on business days is very difficult for some of us. There's 
some more motivation for this discussed at [1].


An alternative proposal would be to use Saturday instead of Friday as 
the tarball deadline, which might be nicer for maintainers who prefer 
to release over the weekend. That would still allow release team to 
build the release on Sunday.


Please, if you have any concerns, let us know. Also let us know if you 
have a preference between Friday and Saturday. Remember that the 
deadline still occurs at 23:59 UTC on the day specified.


Michael

[1] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/131


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

Re: Games in need of maintainers

[mcatanzaro]

On Tue, Aug 6, 2019 at 10:20 AM, mcatanz...@gnome.org wrote:

So that leaves just Quadrapassel and Tali in need of help:


We have a volunteer for Quadrapassel too, so every game is now 
assigned. Thanks all!


Although gnome-klotski, gnome-robots, and gnome-tetravex are assigned, 
these are still available in that if anyone wants one of these, it 
would reduce the workload of Arnaud or myself.


Michael


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

Re: Games in need of maintainers

[mcatanzaro]

On Tue, Aug 6, 2019 at 1:17 PM, Mart Raudsepp  wrote:

I can try my hand on Tali, if needed, as long as it remains written in
C. I don't feel strongly about it at all, just to help, so basically 
if

no-one else steps up..
Was going to offer for both, but then found that the other one is 
vala.


Oooh, thanks!


If I end up with Tali, I'll need to figure out the ftpadmin release
stuff.


I can help with this on IRC. If you already have a GNOME account then 
we just need to get you the right permission.



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

Re: Games in need of maintainers

[mcatanzaro]

On Tue, Aug 6, 2019 at 5:07 AM, Arnaud Bonatti 
 wrote:

Yes, I’ve by two times tried to avoid some work for translators in
original ways, and some of them have been not happy with that. We’ve
already discussed about that, and I’ve understood in the process 
that

nothing is really doable here more than what I already do by
commenting the translations, even when I’m dissatisfied with the
result. So I’m just following the standard procedures now, as 
already

stated and since passed release cycle.


Yes, I trust you will continue to leave the translations alone; that's 
certainly a requirement. Thanks for volunteering, Arnaud. And since 
Alberto has volunteered for Mahjongg, you can have Klotski and Tetravex 
in addition to Four-in-a-row.


Since you've taken Klotski and Four-in-a-row off my hands, and Iulian 
has just volunteered to resume Nibbles releases, I think I will 
continue to care for Robots. So that leaves just Quadrapassel and Tali 
in need of help:


https://wiki.gnome.org/MichaelCatanzaro/GamesReleases

To be clear about expectations: they are not much. Just reading 
incoming issue reports (rare), reviewing incoming merge requests 
(rare), and making releases when there are interesting changes would 
suffice. Any individual game is a small effort. It's just that when we 
each have 4-5 different games to care for, release days become really 
annoying.


Michael


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

Re: Games in need of maintainers

[mcatanzaro]

On Tue, Aug 6, 2019 at 4:59 AM, Alberto Ruiz  wrote:
I can take care of mahjongg, although not before next week as I am on 
vacation and won't have access to a computer.


Thanks Alberto!


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

GNOME 3.33.90 released

[mcatanzaro]

Hi developers and testers,

GNOME 3.33.90 is now available, slightly ahead of schedule for a change!

This is the first beta release for GNOME 3.34. To ensure the quality of 
the final release, we have entered feature freeze, UI freeze, and API 
freeze, so now is a good time for distributors planning to ship GNOME 
3.34 to start testing the packages.


If you want to compile GNOME 3.33.90, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of your host system:


https://download.gnome.org/teams/releng/3.33.90/gnome-3.33.90.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.33/3.33.90/NEWS

The source packages are available here:

https://download.gnome.org/core/3.33/3.33.90/sources/

WARNING!

This release is a snapshot of development code. Although it is 
buildable and usable, it is primarily intended for testing and hacking 
purposes. GNOME uses odd minor version numbers to indicate development 
status.


For more information about 3.33, the full schedule, the official module 
lists and the proposed module lists, please see our 3.33 wiki page:


https://www.gnome.org/start/unstable

Michael


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

Freezes in effect

[mcatanzaro]

Hi developers!

It's that time of the year again: a new stable release, 3.34, fast 
approaching. That means it's time to lock down our feature set and go 
into bugfixing mode. As usual, the following freezes are now in effect:


* API/ABI freeze
* Feature freeze
* UI freeze
* String change announcement period

If you need to break API/ABI freeze, feature freeze, or UI freeze for 
some compelling reason, you may seek approval from 
. We're more likely to grant freeze breaks 
closer to the start of the freeze period (i.e. now) rather than later.


For string changes, please announce your changes to 
.


Let's make 3.34 amazing!

Michael


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

Games in need of maintainers

[mcatanzaro]

Hi,

I'm trying to find new maintainers for the following games:

four-in-a-row, gnome-klotski, gnome-robots, gnome-mahjongg, 
gnome-tetravex, quadrapassel, tali


The first three in the list used to be lightly maintained by me, but I 
don't want to keep releasing them. I'll continue to care for two or 
three other games.


The other four used to be maintained by Mario, but I fear he's long 
since moved on to bigger and better things. :)


If you're interested, get in touch please. Thanks a bunch!

Michael


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

Re: Some nigthly flatpaks are failing to build

[mcatanzaro]

On Fri, Aug 2, 2019 at 5:51 PM, Michael Gratton  wrote:
Is there any way to get notification for build failures here? I 
frequently don't end up seeing the build failures. Email sent to 
people listed in the project's DOAP maybe?


Unfortunately there's currently no way to be notified of build failures.

Until there is, I think that means there is no expectation that 
projects actually build. :)


Michael


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

Re: GNOME 3.33.4 RELEASED

[mcatanzaro]

On Wed, Jul 24, 2019 at 5:19 AM, Javier Jardón  
wrote:
Little reminder: "The Freeze" is only a week and a half away (5th of 
August),

so please be sure to finish on time all those awesome features you
have been working
on this cycle


Hi all,

To help the next release go smoother, I'd encourage you to please make 
sure your tarballs are ready before the Monday, Aug 5th deadline. 
Please DO NOT wait until Tuesday or Wednesday, Aug 6th or Aug 7th to 
release. Next Thursday or Friday, Aug 1st or 2nd, are both good days to 
release. There is no need to wait until the Monday deadline.


I know this is a very short timeline between 3.33.4 and 3.33.90, but 
the .4 was pretty hard and I think we want to get back onto the 
originally-planned schedule.


Thanks,

Michael


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

Re: GNOME 3.33.4 unstable tarballs due (responsible: jjardon)

[mcatanzaro]

Hi,

This release will be delayed, probably until next week. We're still 
working out problems with dependencies.


Michael


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

Re: Heads-up: possible breakage in the master flatpak runtime

[mcatanzaro]

On Fri, Jun 28, 2019 at 9:36 AM, mcatanz...@gnome.org wrote:
Bug is 
https://mail.gnome.org/archives/desktop-devel-list/2019-June/msg00018.html


Sorry: https://gitlab.gnome.org/GNOME/gnome-software/issues/723


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

Re: Heads-up: possible breakage in the master flatpak runtime

[mcatanzaro]

Hi again,

We've discovered that updating with GNOME Software will break your 
flatpak apps. You must update with the flatpak CLI to fix this, not 
with GNOME Software. Everything should be in good shape after you do a 
one-time update using the CLI.


Bug is 
https://mail.gnome.org/archives/desktop-devel-list/2019-June/msg00018.html


Michael


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

Re: Heads-up: possible breakage in the master flatpak runtime

[mcatanzaro]

On Wed, Jun 26, 2019 at 9:04 AM, mcatanz...@gnome.org wrote:
Now Abderrahim has fixed the problems with the last attempt and we 
are trying to upgrade to 19.08 again.


Also Tristan. Thanks Tristan!


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

Re: Heads-up: possible breakage in the master flatpak runtime

[mcatanzaro]

On Fri, Jun 21, 2019 at 3:16 AM, a.kitouni--- via desktop-devel-list 
 wrote:
Nightly apps may be broken (as in refuse to start) for up to 24h 
until they're rebuilt against the new ABI, so if you depend on a 
nigtly app don't update today.


Hi,

I wound up reverting back to the 18.08 runtime due to some problems. 
Now Abderrahim has fixed the problems with the last attempt and we are 
trying to upgrade to 19.08 again. The same warning applies: nightly 
apps may be broken for a day or two. Thanks for your patience.


Michael


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

Re: Heads-up: possible breakage in the master flatpak runtime

[mcatanzaro]

Hi,

It looks like the runtime is going to be broken for a couple days due 
to https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/181.


You can downgrade to the last good version with:

$ flatpak update 
--commit=4935b45d02b85cf5ab09a7ec28f851fcc850f28f0e9b9911808f002c49aee6eb 
org.gnome.Platform//master


Michael


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

Re: System-wide dark mode

[mcatanzaro]

On Wed, Jun 5, 2019 at 1:14 PM, Alexander  wrote:
Since WebKit supports Apple's dark mode now, I wonder if mail clients 
(and also Devhelp/Builder) will be able to provide styles for dark 
mode with that.


Well we really don't, not yet. That's what I've been trying to say

Once we do, mailers could add color-schemes to the CSS to indicate 
support for dark mode. That will be automatically supported once 
WebKitGTK supports the color-schemes property. If Apple Mail already 
supports this, as I suspect, then mailers will start using it soon.


Like Milan says, it will never be safe to use for arbitrary HTML mails. 
HTML is always going to need to opt-in.


Michael


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

Re: System-wide dark mode

[mcatanzaro]

On Wed, Jun 5, 2019 at 1:44 AM, Tristan Van Berkom 
 wrote:

Are you saying that WebKitGTK interprets the system theme and CSS to
render the HTML content ?


Yes, as does Firefox.


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

Re: System-wide dark mode

[mcatanzaro]

On Mon, Jun 3, 2019 at 5:40 AM, Allan Day  wrote:
If the size of the theme is the issue, do we know what size is 
acceptable?


For WebKit to be able to handle this, the required performance 
improvement would be measured in orders of magnitude. I don't know 
about Firefox.


Without changes in GTK to allow us to use multiple themes at once, or 
instantaneously switch between themes, we can either give you broken 
dark mode (the status quo in both WebKit and Firefox), or we can give 
you light mode (my recommendation).


Michael


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

Re: System-wide dark mode

[mcatanzaro]

On Thu, May 30, 2019 at 4:15 AM, Allan Day  wrote:

How does this relate to the dark mode in WebKit?

I was hoping that Web would follow the system-wide dark mode 
preference, and expose it to websites...


The ideal, desired behavior is to enable dark mode on any websites that 
opt-in to dark mode, if and only if the user has selected the dark mode 
preference. We can't implement that without design changes in GTK since 
for that we need the ability to *very quickly* switch between different 
themes in the same process, and that's currently too slow.


The current behavior, in our current world where there is no dark mode 
preference, is that if you select a dark theme, a ton of websites 
break, because most websites are not prepared for dark mode and will 
draw e.g. dark text on dark backgrounds. So if we make dark mode an 
officially-supported option, the very least we need to do is force 
light mode on all websites, even if dark mode is enabled, to avoid this 
breakage. That's already sort of possible to do using heuristics, e.g. 
removing "dark" from the end of the theme name and hoping it makes a 
valid theme, but that's hardly a good solution. A more official control 
would be better. Notably, it *will not* be possible to do if dark mode 
is controlled by a gsetting, since we can't change the value of a 
gsetting for just a single process.


Michael


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

Re: System-wide dark mode

[mcatanzaro]

On Wed, May 29, 2019 at 8:35 AM, Allan Day  wrote:
Therefore, before we get too far into planning and implementing this 
feature: does anyone know of any serious obstacles they'd face, if we 
were to support a dark mode?


WebKit is having trouble with this now:

https://bugs.webkit.org/show_bug.cgi?id=126907

We need help from GTK developers to make it possible to use multiple 
themes in the same process without large performance penalties. 
Otherwise we need to change WebKit to try to switch to a light theme 
always. Currently it uses the current theme even if it's dark, and 
websites are broken, making it impractical to actually choose a dark 
system theme.


Michael


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

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

[mcatanzaro]

On Sat, May 4, 2019 at 4:22 AM, Bastien Nocera  
wrote:

The person you quoted is a troll. In fact, I'm not sure there's any
comments on that issue that aren't trolls (apart from the OP and the
repository owner).


Ah OK then, fooled me because he took a such strong plausibly-sincere 
stance against "master" in [1].


[1] 
https://github.com/ContributorCovenant/contributor_covenant/issues/569#issuecomment-423285329



This is the sort of comment that person made on another platform:
https://dev.to/rkfg/comment/6bj4
(yes, they're so useful that they just get removed, you can see
snippets of the transphobic nature of them in the full thread if you
want to read)

I don't think you want to align yourself with this person.


I actually don't see any non-removed comments from him there, but I'll 
take your word for it. Clearly not.



The rest of
your interactions in this thread and the original thread are coming 
out

as disruptive for the sake of it. Is changing the default git branch
really something you feel strongly about?


Well clearly I'm very unimpressed by the proposal and don't want to do 
this, yes, but I don't think I have anything more to add to the 
discussion at this point, so I guess I'll stop "disrupting."


Michael


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

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

[mcatanzaro]

On Fri, May 3, 2019 at 5:57 PM, Bastien Nocera  
wrote:

Seriously Michael, you’re embarrassing yourself.


I don't feel very embarrassed. Your suggested alternative name, "main," 
is clearly considered to be offensive by at least one of the very same 
people who don't like "master," and who amazingly appears to be sincere 
about this, so does it really still seem like a good option? We're not 
going to accomplish much if we replace one apparently-offensive branch 
name with another.


Keep trying... eventually we'll find something that is inoffensive. I 
don't think anybody has complained about "trunk" yet. At least I don't 
think elephants will be contributing to GNOME anytime soon.


Michael


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

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

[mcatanzaro]

On Fri, May 3, 2019 at 5:09 AM, Bastien Nocera  
wrote:

- And to what?

A few possible names were mentioned/used. "mainline" was thought to
have strong connections to drug use, "release" (use in the contributor
covenant) seems to restrictive (we also do releases from other
branches). I like "main" because it keeps 2 letters from "master" so
diminishes the need to retrain your muscle memory. "trunk" definitely
makes sense when talking about branches but doesn't have the "ma"
advantage.


"main" seems like it should be safe, yet since you linked to 
https://github.com/ContributorCovenant/contributor_covenant/issues/569 
it seems fair to quote the second comment there:



"Main" suggests inequality, I'm against that.


So good luck finding an inoffensive name for the, er, primary branch. 
(I probably shouldn't say "primary," though, since primacy also 
suggests inequality)


Michael


___
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

[mcatanzaro]

On Wed, May 1, 2019 at 6:08 AM, Michael Gratton  wrote:
This has already been covered in the original proposal under 
objection (1) "It doesn't matter". As has already been discussed, 
what actually doesn't matter is what you or I think, it is the people 
who have been affected by the language we use that matter. These are 
the people who won't contribute to GNOME because of these terms, and 
it is the project that loses out in the end.


You've yet to provide any evidence for this. We're asking for evidence 
because it is *extremely* difficult to believe. You're losing us here.


To address some of your points directly however, this censorship in 
as much as the CoC is censorship, and as much as you already 
self-censor when choosing names for things in projects you 
participate in. That is to say, not actually censorship at all. In 
fact, you can see this proposal as simply aiming to extend the CoC to 
our documentation, API, and development infrastructure.


Michael, the events CoC is a reasonable CoC written by reasonable 
people designed to ensure we treat each other reasonably well. It has 
broad support -- perhaps not universal, but at least pretty broad -- 
from the GNOME community because we mostly all agree it is reasonable.


What you're proposing is not reasonable. It's really not. There's no 
way you're going to convince the community that we should avoid 
commonly-used words that are generally considered inoffensive, just 
because a small minority might feel otherwise (which, in this case, is 
hard to believe, but I suppose people are not always reasonable).


If you want to help make the GNOME community more inclusive in a more 
productive way, you could, for example, work on generalizing the events 
CoC to apply to all GNOME community interactions, like this mailing 
list, rather than just specific in-person events. I would suspect that 
would have broad support.


Michael


___
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

[mcatanzaro]

On Wed, May 1, 2019 at 12:22 AM, Tristan Van Berkom 
 wrote:

We should also not show favoritism of one set of cultural values over
another, I feel that censorship to this degree is a very western
concept which we should not lend any credit to. Ask has already 
pointed
out that the possible offensiveness of the word 'master' on it's own 
is
even more particular to the USA, I cannot speak to the veracity of 
this

but I do suspect that this is pandering specifically to US
sensitivities, which I also do not agree with.


It's not a "US sensitivity," it's really not. I assure you this 
proposal is wildly farfetched by US standards. I know it is intended as 
a serious proposal, but it reads more as joke or parody and as such 
it's really, really hard to take seriously.


Michael


___
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

[mcatanzaro]

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


From https://www.merriam-webster.com/dictionary/git:

British
: a foolish or worthless person

Or from https://www.thefreedictionary.com/git:

n. Chiefly British Slang
An unpleasant, contemptible, or frustratingly obtuse person.

n.
1. a contemptible person, often a fool
2. a bastard

Shall we install our own inclusive symlink for git now, to avoid 
potentially-unpleasant connotations? Or maybe just all switch to bzr? 
The main branch in bzr is called trunk anyway, no slavery there, 
clearly more inclusive. Better not get too cozy with GitLab. Or git too 
cozy, if you're from the American south.


Michael


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

Re: GNOME 3.33.1 RELEASED

[mcatanzaro]

On Fri, Apr 26, 2019 at 2:43 AM, Samuel Thibault 
 wrote:
I guess I am missing something in the process of releasing a version? 
Or

is accerciser perhaps just not part of a desktop package set?


Only GNOME core elements are included in the release. accerciser is in 
world, not core.


Michael


___
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

[mcatanzaro]

Hard to believe this is a serious discussion that we're actually having.

On Thu, Apr 25, 2019 at 7:02 AM, jtojnar--- via desktop-devel-list 
 wrote:
On Thu, 25 Apr, 2019 at 11:21 AM, Daniel Playfair Cal via 
desktop-devel-list  wrote:

"master/slave" -> "leader/follower"


Please note that leader/follower terms are commonly associated with 
exploitation of people by cults and should be avoided as well.


Since it's impossible to tell what the intended tone here is: was this 
a serious request to avoid the terminology, or a joke intended to make 
a point? (I'm guessing the later?)



___
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

[mcatanzaro]

This should go without saying, but master branches are not a reference 
to slavery, rather to canonicity. The master branch is the canonical 
branch, the primary copy. The relevant dictionary definition here 
(Merriam-Webster) is "an original from which copies can be made." As 
was pointed out by Ask on GitLab, this is about as much a reference to 
slavery as Jedi Master. We should go to reasonable lengths to avoid 
offending reasonable people, but if someone is offended by innocuous 
phrases like Master's degree, master plumber, Masterpiece Theater, or 
the word "masterful," then I'd suggest rethink why and consider that 
it's probably not reasonable.


Your first reference doesn't even mention slavery, but complains that 
the language is gendered, based on an archaic definition (little boy, 
"young master"). This was true 200 years ago. It's rarely ever used 
today.


Naming your primary branch something other than the 
universally-accepted default branch name is going to confuse and 
irritate an awful lot of developers for almost no benefit.


Michael


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

Re: Gnome 3.32 Bugs

[mcatanzaro]

On Sun, Apr 7, 2019 at 6:38 PM, Ty Young via desktop-devel-list 
 wrote:
If any of these aren't known and reported yet I can report them. I'm 
using Arch/Fedora 30 Beta Silverblue.


I'd recommend reporting separate bugs for all of these.


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

Re: Upcoming evolution-data-server API changes (libical-glib + more)

[mcatanzaro]

On Thu, Apr 18, 2019 at 12:29 PM, Milan Crha via desktop-devel-list 
 wrote:
One thing, with the prepared merge requests [which will need changes 
in

the version reference (they reference libecal-2.0 as 3.33.1, while
it'll be a different version)], should I contact respective 
maintainers

anyhow specifically, other than through the gitlab and this mailing
list, thus they know about the change? And once the eds changes are
committed, should I still wait for them for an approval, or should I
just commit, at least for those projects which are related to GNOME
Continuous and other services, which will break once the evolution-
data-server changes are committed? I do not want to touch their code
without them knowing about it, I do not like it myself, thus I'm
looking for some advice how to make it smooth and coordinated. There's
plenty of time, probably 3 weeks, and the merge requests are quite
fresh, I didn't expect any quick reaction on them (even I did receive
one, which was impressing), but I like to be prepared and behave like 
a

good citizen.


Please commit all the changes to folks, gnome-calendar, and gnome-shell 
at the same time as evolution-data-server to avoid breaking 
gnome-build-meta.



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

GNOME 3.32.1 released!

[mcatanzaro]

Hi,

GNOME 3.32.1 is now available. This is a stable release containing four 
weeks' worth of bugfixes since the 3.32.0 release. Since it only 
contains bugfixes, all distributions shipping 3.32.0 should upgrade.


If you want to compile GNOME 3.32.1, you can use the official
BuildStream project snapshot:

https://download.gnome.org/teams/releng/3.32.1/gnome-3.32.1.tar.xz

The list of updated modules and changes is unavailable for this release 
due to technical difficulties, but the source packages are available 
here:


https://download.gnome.org/core/3.32/3.32.1/sources/

Enjoy the new stable release,

Michael Catanzaro
GNOME Release Team


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

Re: 3.32 applications still missing icon changes

[mcatanzaro]

On Sat, Mar 30, 2019 at 11:32 AM, Leslie S Satenstein 
 wrote:

Monday April 4th???  Is your desktop calendar set to February?


Good catch. I meant Monday, April 8 and Tuesday, April 9.


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

3.32 applications still missing icon changes

[mcatanzaro]

Hi,

I'd like to proposal a global freeze exception to encourage all 
applications to feel free to belatedly update to Jakub's new app icons, 
to improve consistency. This freeze exception would expire Monday, 
April 4 when 3.32.1 tarballs are due.


Two core apps are still missing Jakub's new app icons in 3.32: Cheese 
and Simple Scan. The icons have been committed to git, but not yet 
released. Please fix this before Monday, April 4. Thanks! Cheese is 
also still missing a git tag for 3.32.0. Please fix that too. The 
release team can help out on April 5 if still needed.


Michael


___
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

[mcatanzaro]

On Mon, Mar 25, 2019 at 12:33 PM, Florian =?iso-8859-1?q?M=FCllner?= 
 wrote:

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").

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]).

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.


Since this spec is the closest we have to something workable, I think 
it would be productive to define the technical changes GNOME would want 
to see in order to support something close to it. Seems like our 
designers are willing to consider design changes, and the technical 
problems with the status notifier spec look like the biggest hurdles 
currently.


I don't think it's hugely problematic if our solution for status 
notifiers is not backwards-compatible with existing applications. KDE 
can be changed. So can libappindicator. Third-party apps like Dropbox 
will eventually be updated once Ubuntu adopts an hypothetical upstream 
GNOME solution for status notifiers, even if it takes a couple years. 
We don't have to solve everything overnight.


Michael


___
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

[mcatanzaro]

On Sat, Mar 23, 2019 at 1:06 PM, Britt Yazel  wrote:
I believe that there is an elegant solution to handling sys-tray 
icons without sacrificing our core goals, one idea being to 
incorporate it into the Dash.


I wonder if there's been any serious design consideration of this 
proposal? The dash seems like it might be a safer place to put things 
than allowing applications to clutter the precious top bar.


On the other hand, we might just walk into user complaints that the 
icons are not visible enough there.


Michael


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

Re: Extension review

[mcatanzaro]

On Mon, Mar 25, 2019 at 6:16 AM, Neil McGovern  wrote:

Just to confirm though, is this for working on the extension review
infrastructure, or actually doing reviews? That may change the answer
:)


Actually doing reviews, I think. Dunno, I'll pass him on to you.


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

Extension review

[mcatanzaro]

Hi devs,

I found a volunteer who's interested in helping out with shell 
extension review. Who should he talk to?


Michael


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

Re: Update your libhandy submodules (and packages)

[mcatanzaro]

Yeah, a new libhandy release ASAP would be appreciated.

Affected applications:

epiphany
gnome-bluetooth
gnome-contacts
gnome-control-center
gnome-games

I think libhandy has reached the point that it's time to start thinking 
about making it a system dependency so we don't have to enter panic 
mode to update a bunch of different places whenever there's a bug like 
this. (There will be more bugs.)


On Fri, Mar 1, 2019 at 4:06 AM, Bastien Nocera  
wrote:

For the release-team:
Did the definition and acceptance criteria change for external
dependencies? libhandy is a library hosted on a 3rd-party server which
some core applications have a dependency on.


We don't really have any formal rules for external dependencies, I 
think not since the GNOME 2 days.


Michael

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

Re: API stability for Meson configuration options

[mcatanzaro]

On Sun, Feb 17, 2019 at 8:55 AM, Sam Thursfield via desktop-devel-list 
 wrote:
Do we have a policy for if/when we can do breaking changes to Meson 
configuration API? If this was a change to the C API, we'd delay it 
until the next major release (in this case Tracker 3.0).


If gnome-build-meta or gnome-continuous use those options, then they 
need to be updated at the time you make the change. If you touch 
gnome-build-meta, be sure to release a new tarball before the next 
scheduled tarball deadline. (And ask Garnacho about tarball problems 
specific to tracker.) In this particular case, it looks like 
gnome-build-meta is fine but gnome-continuous will need to be updated 
to not use the -Ddocs= option.


I'd consider avoiding such changes after the .90 release, but there's 
no strict policy, other than keep GNOME building.


Thanks,

Michael

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

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield  
wrote:
1. require every user of the software to contact Google and obtain 
their own client ID, which they provide at runtime to any desktop 
software that needs to interact with Google APIs at


Ha ha.

2. require distributors and people who build their own software to 
contact Google and obtain a client ID, which they provide at build 
time


We could require that our distributors provide their own API keys, but 
they're still going to be embedded in the public (open source) build 
definitions (RPM, deb, whatever) so that fails.


3. continue distributing a "GNOME key" with the source code, and hope 
that Google don't mind


I suggest we don't continue to willfully violate Google's terms of 
service now that the issue has been brought to our attention. The only 
reasonable option seems to be to shut down our Google integration. Not 
just from g-o-a, but also the Safe Browsing support in Epiphany.


Michael

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

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list 
 wrote:

A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can 
be

done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique position in the landscape, though it allows for 
GNOME

to control the build process in such a way that build secrets become
possible.

Though if this is the way it goes, be sure to be prepared for all the
"GNOME forbids people to build their software stack" headlines,
followed by a "actually the reason is that they needed to handle
secrets in their builds in order to support client keys for the 
various

integrations in the software" in the third paragraph.


Well yeah... but distros will never allow that.

Michael

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

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


Turns out it's a new restriction that took effect on January 16, 2019. 
So probably we've only been in violation for one month now. (You can 
see the previous version of the terms of use are from 2011 and do not 
include that requirement.)


Anyway, we can't have secrets in the build, so we don't have a lot of 
options. Maybe not any options. At least, I don't see any.


Michael

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

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry  
wrote:
“Developer credentials (such as passwords, keys, and client IDs) 
are intended to be used by you and identify your API Client. You will 
keep your credentials confidential and make reasonable efforts to 
prevent and discourage other API Clients from using your credentials. 
Developer credentials may not be embedded in open source projects.”


It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


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

GNOME 3.31.90 released

[mcatanzaro]

Hi developers and testers,

GNOME 3.31.90 is now available. This is the first beta release for 
GNOME 3.32. To ensure the quality of the final release, we have entered 
feature freeze, UI freeze, and API freeze, so now is a good time for 
distributors planning to ship GNOME 3.32 to start testing the packages.


If you want to compile GNOME 3.31.90, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of your host system:


https://download.gnome.org/teams/releng/3.31.90/gnome-3.31.90.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.31/3.31.90/NEWS

The source packages are available here:

https://download.gnome.org/core/3.31/3.31.90/sources/

WARNING!

This release is a snapshot of development code. Although it is 
buildable and usable, it is primarily intended for testing and hacking 
purposes. GNOME uses odd minor version numbers to indicate development 
status.


For more information about 3.31, the full schedule, the official module 
lists and the proposed module lists, please see our 3.31 wiki page:


https://www.gnome.org/start/unstable

Michael

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

Re: GitLab mirror considered harmful

[mcatanzaro]

FWIW I only use our GitHub mirrors when our GitLab is running slow. But 
that happens often enough


On Mon, Feb 4, 2019 at 10:58 AM, philip.chime...@gmail.com wrote:
Could we take it all the way and just push the PR branch to 
"$github_user_name/$branch_name" in the main repository on GitLab, 
and open a merge request automatically, then instruct the auto-close 
bot to direct the person to GitLab, possibly telling them how to 
create an account as well? Also tag the maintainer's GitHub account 
(if they have one) in the auto-close message, so they get a 
notification?


Then we wind up with merge requests that the contributor cannot respond 
to, which we'll have to close manually. I'd rather just not know about 
the merge request if the contributor can't take the time to submit it 
on GitLab.


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

Re: GitLab mirror considered harmful

[mcatanzaro]

On Sun, Feb 3, 2019 at 8:59 PM, Christopher Davis via 
desktop-devel-list  wrote:
If we keep the mirrors around, then we should at the very least 
ensure that pull requests aren't able to be opened at all

on the repos.


GitHub doesn't allow disabling pull requests, that's why we have the 
auto-close bot. I believe someone from GNOME asked supporting this 
previously and they told us no.


FWIW I don't care if we leave the mirror up now that we have the 
auto-close bot.


Michael

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

Freezes incoming!

[mcatanzaro]

Hi all,

This is just a reminder that API/ABI freeze, feature freeze, and UI 
freeze begin this Monday, February 4. [1] The purpose of the freezes is 
to improve the quality of the upcoming GNOME 3.32 release. If you feel 
that breaking the freeze would allow you to improve the quality of the 
release, you may request an exception [2].


Please also remember that 3.31.90 tarballs are due by 23:59 UTC on 
Monday.


[1] https://wiki.gnome.org/ThreePointThirtyone
[2] https://wiki.gnome.org/ReleasePlanning/Freezes

___
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

[mcatanzaro]

This is a tangent of a tangent, but:

On Mon, Jan 28, 2019 at 9:29 AM, Jeremy Bicha  wrote:

Thank you for your reply. Ubuntu includes GNOME To Do by default in
18.04 LTS and still does. I guess we need to discuss whether it should
be removed by default, but we try to limit the adding and removing of
apps because of the disruption it causes to upgrading users. We added
it because we try to follow GNOME Core (for many reasons we are unable
to follow it completely) and we found the app fairly useful. We
appreciate you developing and maintaining it.


This is kinda my fault. I added To Do to core without consulting with 
design team. (I think I had consulted Georges? But it was a while ago.) 
Based on input from design team and also Fedora Workstation, we wound 
up adopting more a restrictive approach to managing the core apps, and 
subsequently removed To Do after a year or so. I think To Do was there 
by default in just one Fedora release.


The current list of core apps is here:

https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/meta-gnome-core-utilities.bst

We'll be much more careful about adding apps in the future to ensure we 
have consensus and avoid backtracking on changes again. (I think Geary 
is still a very plausible candidate, though.)


Michael

___
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

[mcatanzaro]

On Sun, Jan 27, 2019 at 6:32 PM, Nathan Graule via desktop-devel-list 
 wrote:
Given what I've read about the Google policy (and I don't know how 
much of that was added with the Jan. 15 revision), but it seems like 
the very concept of GOA as a centralized account repository goes 
against Google rules. Google wants to know by whom the OAuth key will 
be used, and how. Under an open system where any third-party can 
implement access to GOA, GNOME cannot be able to tell Google about 
the use of the key (which is part of what they're asking in their 
request, as the ansible issue presents <#2>).
Therefore GOA *needs* to change somewhat. At the very least, it 
cannot let third-party applications use the GNOME OAuth key to access 
Google APIs.


Question: the GNOME key is necessarily public, since it's open source 
and we don't have secret sauce in the build system. GNOME can't stop 
random apps from using it. Right? The g-o-a README says this is allowed:


https://gitlab.gnome.org/GNOME/gnome-online-accounts/blob/bf77325d847d2878159e8ba2677768b2fe6386a6/README#L58

So there's no way we can ever stop random applications from using the 
GNOME key and pretending to be us, right? It just works because nobody 
has decided to abuse it yet?


Michael

___
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

[mcatanzaro]

On Sun, Jan 27, 2019 at 7:29 PM, Michael Terry  wrote:
You say deja-dup has nothing to worry about. But I very much have to 
solve the problem of many of my users losing access to their backups 
(through my app at least) in three weeks. Will not inspire 
confidence. Again, my fault I guess for using GOA in the first place.


There are multiple deadlines:

"""For projects that require action, you must submit apps for 
verification before Feb 15th, 2019. If you don't, access for new users 
will be disabled on February 22nd, 2019, and existing grants for 
consumer accounts will be revoked on March 31st, 2019."""


Michael

___
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

[mcatanzaro]

On Sun, Jan 27, 2019 at 4:27 AM, Debarshi Ray  
wrote:

It so happens that we have half a dozen notifications from Facebook
and Google about our uses of their APIs at varying degrees of
seriousness. They are still on my todo list.  Thankfully, Philip
Withnall and Michael Catanzaro are on top of the Google part, but only
barely.  I am worried that most of our Facebook integration has
stopped working.


Err... well this seems like as good a time as any to mention it: Philip 
and I both noticed emails from Google warning that they'll shut us down 
unless we do a huge amount of work in a very short amount of time. 
Neither of us plan to work on this. My only use of the Google 
integration is for Safe Browsing, which doesn't use 
gnome-online-accounts at all and which I'm just hoping won't be 
affected.


If anyone wants to help, see 
https://gitlab.gnome.org/Infrastructure/ansible/issues/2. We have three 
weeks left.


Michael

___
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

[mcatanzaro]

On Thu, Jan 24, 2019 at 4:00 AM, Allan Day  wrote:

I'd personally like us to keep the path open for you and provide some
guarantees about Geary being able to use Online Accounts in the
future. I wonder if this should be part of a wider conversation about
Geary becoming GNOME Mail? :)


Seems like reasonable conversation to be having, indeed. If we add 
Geary, we could drop the discussion about whether to remove email from 
g-o-a.


On Thu, Jan 24, 2019 at 4:00 AM, Bastien Nocera  
wrote:

Mostly because the various integration points didn't exist. We (GNOME)
were pining for a sharing interface which didn't, and still doesn't,
exist, and epiphany maintainers didn't want to integrate the patch 
that

was already written.


It's been a while, but IIRC I wanted a reading list mode to not be 
totally dependent on Pocket. We could sync it to Pocket though, since 
that fits in nicely with our existing Firefox Sync support, but there 
should be local storage too.


Michael

___
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

[mcatanzaro]

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.


Michael

___
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

[mcatanzaro]

On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via 
desktop-devel-list  wrote:

Hi Rishi,

Cloud documents is an important part of where I want to move forward 
with the application,

so Online Accounts integration would still be critical.

A file previewer is definitely a priority, and an editor could be 
considered.


Regards,
Chris


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.


Michael

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

Re: Documents and core apps

[mcatanzaro]

On Thu, Jan 17, 2019 at 11:06 AM, Bastien Nocera  
wrote:

Nobody added the ability for gnome-documents to open files...


Yeah, I think it never really had much chance without that.

Music and Photos need to learn to open files, too.


I'll probably split off Books at some point in the future.


That seems advisable.

Michael

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

Documents and core apps

[mcatanzaro]

On Thu, Jan 17, 2019 at 9:25 AM, Bastien Nocera  
wrote:

I think the release team is wrong in the first place. Lack of
maintainership and bugs don't equate to removal. Otherwise there would
be plenty more applications to remove there...


These were secondary reasons. The main reason is that we never really 
figured out how Documents was intended to be used. The app was 
basically just "bad evince". Cloud integration was of limited quality 
and limited usefulness. Documents get jumbled together, not reflecting 
familiar disk layout, which was intended to be less confusing to users, 
but actually just made the app suck to use. All my attempts to use it 
wound up in my returning to evince. As best I can remember, I don't 
think I've never seen anyone, even at GNOME conferences, using 
Documents. Even Epiphany seems more popular. Removal was requested by 
the previous maintainer, Rishi, and approved by design team (albeit 
after sustained prodding).


My request to Rishi and to the designers was that we either really 
rethink the purpose, use case, workflow, and utility of Documents. And 
after a lot of thinking, we just couldn't figure out how the app really 
fit into our desktop. Maybe if a new maintainer takes over and can find 
answers to those questions, we could reconsider removing it (there's 
still time to reconsider this before 3.32 is released! the removal is 
not set in stone!) but it would really require some sustained design 
and development effort that I don't expect to materialize.


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


Maybe we should touch in on desktop-devel-list more often to make sure 
the entire community is aware of plans for core apps. Other major goals 
are to obsolete file-roller with nautilus (which we have not yet done 
only because nautilus's archive support is not yet very good) and teach 
gnome-music to open audio files (it's absurd that Videos is our default 
audio player currently).


Michael

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

Re: GitLab postmortem

[mcatanzaro]

On the whole, I'm really pleased with GitLab.

Especially really pleased with the ability to start discussions during 
reviews and mark comments as resolved. It's a bit of a shame we can't 
batch comments like on GitHub, but marking discussions as resolved is 
amazing and makes up for it.


The biggest problem by far has been Bugzilla migration. We still have 
tons of modules (e.g. gnome-shell, gnome-weather, geary, 
gsettings-desktop-schemas... just a few off the top of my head) which 
have still not completed Bugzilla migration. The very slow pace of 
migration is quite frustrating. Also, Bugzilla is quite broken right 
now, so you have to use Andre's direct links to get to the patch queue, 
bug list, etc. This would be a lot less frustrating once issues 
migrate, but in the meantime makes working with these modules almost 
impractical. Finally, it's just annoying to split discussion between 
Bugzilla and GitLab based on the time an issue was filed, or between 
patches and merge requests, for example.


I know it's a huge pain to do these migrations, but at least it's just 
a one-time cost and then we can be fully moved to GitLab.


On Tue, Dec 11, 2018 at 5:06 PM, Christian Hergert 
 wrote:
We have issue templates (although I haven't figured out how to set 
them

up for my projects), but not issue reply templates.


The issue templates are borderline useless though, because the ability 
to set a template as the default issue template is an EE feature. This 
means nobody ever looks at them. I tried these briefly but wound up 
removing them. I really want to be able to show users a short message 
or issue template before they report bugs


I really need reply templates to keep up with the number of bugs I 
need

to close after creation for a number of reasons.

 * Dups
 * Fixed in master, branch
 * Out of scope
 * User support
 * Feature requests (I take note of requests, but we do not hold bugs
   open, they only influence our roadmap).

Failure to have reply templates results in grumpier replies from yours
truly.


I really miss these canned replies too. It's just a small annoyance, 
but it would be nice to have.


Lacking some EE features is disappointing, but still, GitLab CE is much 
better than I was expecting. I'm very happy with how this has turned 
out (asides from the bug migrations). Apologies for my initial 
skepticism years ago. :)


Michael

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

Re: new GNOME Weather maintainers

[mcatanzaro]

First problems I see:




There has not yet been a GitLab migration, so bugs and unreviewed 
patches are still on Bugzilla. First responsibility of new maintainers 
is to review unreviewed patches. But there's no way to list them. To 
get to the patch list, or just to view all the open bugs, you need to 
visit 
https://bugzilla.gnome.org/page.cgi?id=browse.html=gnome-weather 
but that page is now blocked. There's no reason for it to be blocked, 
because it does not allow entering bugs. Just prevents maintainers from 
doing their job and reviewing patches. Who can fix this?


Michael

P.S. I have https://bugzilla.gnome.org/show_bug.cgi?id=777200 
outstanding but I'm sure there are many, many more waiting in the patch 
list.


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

Re: getting commit rights for / maintaining Dia ?

[mcatanzaro]

Hi Tomas,

You should have gotten an email about this from Zander. He will help 
manage this!


Thanks,

Michael

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

Re: extensions.gnome.org password resets

[mcatanzaro]

On Sat, Dec 1, 2018 at 11:43 AM, Yuri Konotopov  
wrote:

Hi, Michael

There is such feature exists. Look to screenshot attached.



Well I'll be. It's not even hidden, either. It's right there where 
you'd expect it to be. Cool.


I wonder why we get so many requests about this... or why they decide 
security@ is an appropriate contact point.


Michael

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

extensions.gnome.org password resets

[mcatanzaro]

Hi,

Most of the non-spam mail received GNOME security group is asking for 
help with extensions.gnome.org. Mostly people ask for password resets.


We ignore all these mails.

Is anyone maintaining extensions.gnome.org? It's really not OK to keep 
this website running without a password reset feature.


Michael

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

GNOME 3.31.2 released

[mcatanzaro]

Hi,

GNOME 3.31.2 is now available. This is the second unstable development 
release leading to 3.32 stable series. Apologies that it's slightly 
late: there were some technical snafus.


If you want to compile GNOME 3.31.2, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of the dependencies on your 
host system:


https://download.gnome.org/teams/releng/3.31.2/gnome-3.31.2.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.31/3.31.2/NEWS

The source packages are available here:

https://download.gnome.org/core/3.31/3.31.2/sources/

WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.31, the full schedule, the official module
lists and the proposed module lists, please see our 3.31 wiki page:

https://www.gnome.org/start/unstable

Let's go develop!

Michael Catanzaro,
GNOME Release Team

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

Re: Removing gstreamer git master from gnome-build-meta

[mcatanzaro]

On Wed, Nov 7, 2018 at 3:00 AM, Abderrahim Kitouni  
wrote:

Hi all,

We would like to remove gstreamer master from gnome-build-meta. What
this means is that the nightly flatpak runtimes will have the latest
gstreamer stable version (1.14.4 as of this writing, but 1.16 should
be released soon).

I believe this won't break anything, but if you think you really need
gstreamer master, please speak up in this issue:
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/97

Cheers,

Abderrahim


This seems like a good idea to me. If GStreamer were still using the 
GNOME release cycle, then it would be beneficial to test the version of 
GStreamer that's going to be present in the next GNOME release. But 
that hasn't been the case for several years now. I think we'd benefit 
from testing the version of GStreamer that our users are actually going 
to be running.


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

Re: GNOME 3.31.1 released

[mcatanzaro]

Thanks for your first release, Abderrahim! It's great to have you 
helping with releases.


On Thu, Oct 11, 2018 at 1:58 PM, Abderrahim Kitouni 
 wrote:

There haven't been many updates to the GNOME modules in this release,
I blame this partly on the fact that we had a problem with the script
sending the release reminder emails.


Thanks to some help from Andrea, I believe this should be fixed going 
forward.


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

GNOME 3.30.1 released!

[mcatanzaro]

Hi,

GNOME 3.30.1 is now available. This is a stable release containing 
three weeks' worth of good bugfixes since the 3.30.0 release. Since it 
only contains bugfixes, all distributions shipping 3.30.0 should 
upgrade.


If you want to compile GNOME 3.30.1, you can use the official
BuildStream project snapshot:

https://download.gnome.org/teams/releng/3.30.1/gnome-3.30.1.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.30/3.30.1/NEWS

(Don't mind the bit about removed modules: that's just a matter of 
which software gets its releases features in this NEWS file. I removed 
two that are not hosted on GNOME infrastructure.)


The source packages are available here:

https://download.gnome.org/core/3.30/3.30.1/sources/

One hiccup: please beware that a GNOME Shell update is not included in 
this release. There were a rather lot of crashes and other regressions 
in 3.30.0 that are not yet fixed in this release, so all distributions 
are encouraged to apply the first twelve patches listed here for the 
time being:


https://src.fedoraproject.org/cgit/rpms/gnome-shell.git/tree/?h=f29=bca72a442ba218e5548fdf867858525f1ba8d730

Other than that, it should be smooth sailing.

Enjoy the new release,

Michael Catanzaro
GNOME Release Team

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

Re: Retiring app menus - planning for 3.32.0

[mcatanzaro]

On Fri, Sep 21, 2018 at 2:47 PM, Bastien Nocera  
wrote:

Those are not keyboard shortcuts, they're mnemonics, used for
navigating menus using the keyboard, not launching keyboard shortcuts
without opening the menu.

Feel free to start a new discussion about those, but they're really 
not

the topic.


And we still have them (you have to press Alt).

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

Re: Retiring app menus - planning for 3.32.0

[mcatanzaro]

On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera  
wrote:

It's faster to access for users, has terser explanations (no need to
create sentences to describe actions) and it's usually better updated
as it lives in the code, as opposed to being separate in the docs.


It's also larger, well-designed, easier to read and use.

Michael

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

Re: [GitLab] Gravatar vs libravatar

[mcatanzaro]

On Tue, Sep 4, 2018 at 10:24 AM, Nicolas Dufresne 
 wrote:

So it's a gain in privacy if you want to host your own. I'm surely not
the only one that isn't going that extreme in keeping control over
couple of my pictures flying around and won't go that far.


The gain in privacy comes from disabling gravitar integration, not 
hosting your own avatar service.



That being said, for people my me, where to I upload yet another
picture ? Any free hosted services ?


Just use libravatar.org. The website design is not the greatest, but if 
you look above the orange Contribute! button there is a "Create a free 
account" link... click that, confirm your email, upload your avatar, 
done. It's just the free software replacement for Gravatar, really that 
simple. I assume you trust libravatar.org not to sell our IP addresses, 
avatar lookup history, email contact graphs, etc. to advertising 
companies.


Or just manually upload your avatar to gitlab.gnome.org. The only 
reason I bothered with libravatar.org was that it was required to set 
an avatar on Fedora infrastructure. I don't really care whether we 
enable libravatar or not, just that we disable Gravatar.


Michael

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

Re: GNOME 3.29.91 released

[mcatanzaro]

On Thu, Aug 16, 2018 at 12:11 PM, mcatanz...@gnome.org wrote:

Hi developers,

I made a mistake in our release validation process, and accidentally 
included incompatible versions of glib (2.57.1) and 
gobject-introspection (1.57.2) in GNOME 3.29.91. 
gobject-introspection 1.57.2 requires glib 2.57.2, but this version 
of glib is incompatible with GNOME 3.29.91. I properly downgraded 
glib when I noticed this, but failed to downgrade 
gobject-introspection as well. The result is that GNOME 3.29.91 is 
not buildable.


Hi developers,

Here is a corrected release, GNOME 3.29.91.1. The only difference is 
that gobject-introspection has been downgraded:


https://download.gnome.org/teams/releng/3.29.91.1/gnome-3.29.91.1.tar.xz

https://download.gnome.org/core/3.29/3.29.91.1/NEWS

https://download.gnome.org/core/3.29/3.29.91.1/sources/

Please, make sure the latest releases of your modules build against 
glib 2.57.2, so that we can update glib and gobject-introspection for 
3.29.92.


Thanks,

Michael

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

Re: GNOME 3.29.91 released

[mcatanzaro]

On Wed, Aug 15, 2018 at 5:42 PM, mcatanz...@gnome.org wrote:

Hi,

GNOME 3.29.91 is now available!


Hi developers,

I made a mistake in our release validation process, and accidentally 
included incompatible versions of glib (2.57.1) and 
gobject-introspection (1.57.2) in GNOME 3.29.91. gobject-introspection 
1.57.2 requires glib 2.57.2, but this version of glib is incompatible 
with GNOME 3.29.91. I properly downgraded glib when I noticed this, but 
failed to downgrade gobject-introspection as well. The result is that 
GNOME 3.29.91 is not buildable.


Actions:

* I'm currently working on an updated release with 
gobject-introspection downgraded to 1.56.1, to be published when 
available.
* I've updated our release procedure to require the strict build plan 
in BuildStream, to avoid this happening in the future.


Lastly, I'll remind maintainers that it would be really helpful to 
release according to our release schedule when there are build fixes 
present in your tree, so that we wouldn't have to fight so many build 
failures and downgrade so many modules. I'm still waiting on releases 
from gtk-doc, gnome-online-accounts, gnome-boxes, and gnome-software, 
all of which were broken and required workarounds to be included in 
GNOME 3.29.91.


Michael

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

GNOME 3.29.91 released

[mcatanzaro]

Hi,

GNOME 3.29.91 is now available!

If you want to compile GNOME 3.29.91, you can use the official
BuildStream project snapshot:

https://download.gnome.org/teams/releng/3.29.91/gnome-3.29.91.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.29/3.29.91/NEWS

The source packages are available here:

https://download.gnome.org/core/3.29/3.29.91/sources/

A couple informal notes. First, this was too hard. Too many build 
failures. I wound up downgrading several modules, I just removed 
gnome-boxes rather than fight to get it to build. If you know there is 
some build failure affecting your module and fixed in git, then please, 
we really need a tarball release according to schedule to avoid making 
the release process difficult for us. Second, this release marks the 
beginning of the software string freeze. String changes from this point 
out require string freeze break approval.


WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.29, the full schedule, the official module
lists and the proposed module lists, please see our 3.29 wiki page:

https://www.gnome.org/start/unstable

Happy hacking,

Michael Catanzaro
GNOME Release Team

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

Re: No app menu changes for GNOME 3.30, please!

[mcatanzaro]

On Tue, Jul 24, 2018 at 8:53 AM, Allan Day  wrote:

I'd expected there to be some discussion about the timeline and a
decision by the Release Team.

As it is, we're less than a week away from UI freeze and most apps
haven't changed their app menus. For consistency's sake, it would be
better to hold off until next release.


I agree with Allan: please don't remove your app menus until after you 
have branched for 3.30. Removing app menus is a huge deal, and we don't 
want 3.30 to be an unfinished transition.


From the lack of objections to Allan's original proposal, it's clear 
that we have consensus on removing the app menus, so I suggest we 
should feel free to delete our app menus in master after branching for 
3.30.


Michael

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

libdw

[mcatanzaro]

Hi all,

Has anybody recently added libdw as a dependency of anything in GNOME?

I'm trying to figure out what has gone wrong in 
https://gitlab.gnome.org/GNOME/gnome-sdk-images/issues/13.


Thanks,

Michael

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

GNOME 3.29.3 released

[mcatanzaro]

Hi developers,

GNOME 3.29.3 is now available.

This release is primarily notable in that all modules are buildable in 
this release, which is historically very rare for our development 
releases. This is an accomplishment! I hope we can keep this up going 
forward.


If you want to compile GNOME 3.29.3, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of your host system:


https://download.gnome.org/teams/releng/3.29.3/gnome-3.29.3.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.29/3.29.3/NEWS

The source packages are available here:

https://download.gnome.org/core/3.29/3.29.3/sources/

WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.29, the full schedule, the official module
lists and the proposed module lists, please see our 3.29 wiki page:

https://www.gnome.org/start/unstable

Michael

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

Re: GNOME 3.29.3 unstable tarballs due (responsible: mcatanzaro)

[mcatanzaro]

On Thu, Jun 14, 2018 at 8:02 PM, Federico Mena Quintero 
 wrote:

This:

http://ftp.gnome.org/pub/GNOME/teams/releng/3.29.2/versions

has librsvg 2.40.20, which is the unmaintained series.  How can I
change it to 2.43.0 for the development release?  I'd really like to
get some testing there.


We discussed this earlier today on IRC. We need to resolve these two 
issues:


https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/100
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/24

Once we have Rust working, then updating librsvg should be 
straightforward.


Michael

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

Re: New module in GNOME: gnome-internet-radio-locator

[mcatanzaro]

On Mon, May 21, 2018 at 1:16 PM, Ole Aamot  
wrote:

What else do I have to do to mark the module
gnome-internet-radio-locator for release in
GNOME 3.29.2 unstable?


Hi Ole,

For GNOME 3.28, we severely downsized what we release to just a few 
core GNOME apps and dependencies. The motivation behind this change was 
to reduce the amount of software that the release team was responsible 
for (it was just too much). Anyway, that more or less corresponds to 
[1] and dependencies. Everything else was moved off to the world 
element [2].


It's possible that we could revisit this change! But as things stand, 
I'd invite you to add gnome-internet-radio-locator to the world element 
instead. This doesn't require any approval, since world doesn't get 
officially released by release team. Just add an element file under 
elements/world, add it to the list in world.bst, and verify that it 
builds successfully. Feel free to either push directly or open a merge 
request, as you prefer.


Hope that's OK,

Michael

[1] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/core/meta-gnome-core-utilities.bst
[2] 
https://gitlab.gnome.org/GNOME/gnome-build-meta/blob/master/elements/world.bst


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

GNOME 3.29.1 released

[mcatanzaro]

Hi developers,

GNOME 3.29.1 is now available.

If you want to compile GNOME 3.29.1, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of the dependencies on your 
host system:


https://download.gnome.org/teams/releng/3.29.1/gnome-3.29.1.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.29/3.29.1/NEWS

The source packages are available here:

https://download.gnome.org/core/3.29/3.29.1/sources/

There are actually not very many changes to GNOME modules themselves, 
because not many maintainers provided updated tarballs, but there are 
new versions for a few applications and libraries. More frequent 
tarball releases would be appreciated if you have made changes in your 
modules, to ensure they receive early testing in development 
distributions. Notably, GNOME Shell was not updated in this release, 
which is a bit sad.


There have, however, been major changes in the build metadata. Thanks 
to Abderrahim Kitouni, we've switched the base system used for building 
GNOME from one based on Debian packages to one based on the freedesktop 
SDK. This is a major step towards using gnome-build-meta to build our 
Flatpak runtimes. There is one notable regression: Rust is no longer 
available, so we had to downgrade librsvg. Help in restoring support 
for Rust would be most welcome in this issue:


https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/100

Finally, zenity has been removed from this release, at long last. 
Please make sure your modules do not use it.


WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.29, the full schedule, the official module
lists and the proposed module lists, please see our 3.29 wiki page:

https://www.gnome.org/start/unstable

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

GNOME 3.28.1 tarballs due

[mcatanzaro]

Hi developers,

It looks like our automated reminder mails are not working properly 
currently. (Does anybody know how to help fix this?) 3.28.1 tarballs 
are due Monday. You all know the drill.


Thanks a bunch,

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

Check your default window size!

[mcatanzaro]

Hi,

Sometimes it's easy for a developer to forget what a new user sees when 
opening an app for the first time. Some of our apps (*cough* email 
clients *cough*) have default window sizes that are waaay too small. 
Check yours out! Increase the default window size if needed.


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

Re: Making a phone call with GNOME

[mcatanzaro]

Note the DTMF is really, really unreliable... not sure if that's a bug 
in Empathy or in Telepathy, but I'd assume the later. I reported this 
as https://bugzilla.gnome.org/show_bug.cgi?id=770709.


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

Re: Using BuildStream as a module maintainer

[mcatanzaro]

On Fri, Feb 16, 2018 at 4:15 PM, Shaun McCance  wrote:
> $ bst build --track-all --track-save core/yelp.bst
> # For some reason I have to do this too? Not sure.
> $ bst build core/yelp.bst

It's a bug (very recently fixed):
https://gitlab.com/BuildStream/buildstream/issues/236

> $ bst shell --build core/yelp.bst bash
>
> That drops me in a shell in a yelp clone. I can do the autogen.sh,
> make, make distcheck dance. (I'll catch on to meson soon, promise.)
> But
> I don't know what to do next. I can't seem to scp. The only editor I
> have for writing NEWS entries and commit messages is vi. I don't have
> my ssh keys, pgp keys, git configs, etc. I'm kind of thinking this
> sandbox isn't the place for me to be doing things.

This confused me too. The missing step is, on the host:

$ bst workspace open core/yelp.bst ~/src/yelp

where the last parameter is the path to wherever you want your git
checkout to be. Then the bst shell command will take you to that
directory, inside the sandbox. You can do make distcheck there, the
generated tarball will appear, and then you can scp it from the host.

> And what about doing general development work? I can't really do much
> inside BuildStream's shell. And even running yelp leaves it pretty
> crippled, because it doesn't have access to /usr/share or D-Bus.
>
> I need some sort of build environment to keep up with dependencies,
> but
> I feel like I'm not fully grokking how people do stuff these days.
> Could somebody shed more light on how they do things?

I don't have a good answer, other than to use JHBuild. That's not a
very great answer, since you know I sent a mail a couple weeks ago
announcing that release team wouldn't be maintaining JHBuild anymore.
(Emmanuele has since taken up that role, in addition to maintaining the
Continuous manifest.) Perhaps that was premature, because many or
perhaps even most GNOME applications are barely functional inside the
bst shell. I've reported an issue for this:

https://gitlab.com/BuildStream/buildstream/issues/223

Problem is, if we keep using both JHBuild and BuildStream, then we have
four different sets of build definitions to maintain, rather than
three, and we're worse off than before. So we'll need to discuss what
we want to do about this.

Michael

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

Re: GNOME 3.27.90 released

[mcatanzaro]

On Thu, Feb 15, 2018 at 4:37 AM, Sam Thursfield  
wrote:
Does it makes sense to create a tagged commit in gnome-build-meta.git 
for each release, instead of publishing the release metadata only as 
a tarball?


I guess that could be quite useful, if people want to  see what the 
changes are. I just hadn't considered it, because it's something we've 
never done before.


It would maybe be a bit confusing, because the commits would not be on 
any branch, but I think that's fine.


Michael

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

GNOME 3.27.90 released

[mcatanzaro]

Hi developers,

Better late than never: GNOME 3.27.90 is here, exactly one week later 
than originally scheduled.


With this release, the release team is no longer going to be building 
or releasing non-core applications. We have renamed the apps moduleset 
to world to reflect this. App developers are encouraged to test their 
applications against new versions of GNOME to make sure they are still 
building and working well.


If you want to compile GNOME 3.27.90, you can use the official 
BuildStream project snapshot. Thanks to BuildStream's build sandbox, it 
should build reliably for you regardless of the dependencies on your 
host system:


https://download.gnome.org/teams/releng/3.27.90/gnome-3.27.90.tar.xz

The list of updated modules and changes is available here:

https://download.gnome.org/core/3.27/3.27.90/NEWS

The source packages are available here:

https://download.gnome.org/core/3.27/3.27.90/sources/

Some commentary. As is typical for our development releases, I ran into 
some build issues. As usual, maintainers received either an email or a 
ping on IRC if I found an issue with your module. Unfortunately, I had 
to temporarily drop a couple modules. The gtkmm module (which is based 
on GTK+ 4, not gtkmm-3) seems to be keeping up with changes in GTK+ 4 
in git, but not making releases. Either it will need to either start 
releasing following GTK+ 4, or we'll need to drop it until GTK+ 4 
development slows down. Additionally, gnome-documents and gedit have 
been temporarily removed due to build issues.


We also have a problem with some prominent modules not getting 
releases. Notably, GNOME 3.27.90 includes GNOME Shell 3.27.1 and mutter 
3.27.1, which are the latest-available versions. This is sad. Let's do 
better next cycle, please.


As a reminder, there will be no 3.27.91 release next week due to the 
delay of 3.27.90. You'll get an automated reminder later this week; 
just ignore it.


Thanks for your hard work on GNOME 3.28. It's going to be great!

WARNING!

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.27, the full schedule, the official module
lists and the proposed module lists, please see our 3.27 wiki page:

https://www.gnome.org/start/unstable

Michael

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

[mcatanzaro]

On Tue, Feb 13, 2018 at 3:43 AM, Sébastien Wilmet  
wrote:
The list is not complete, there is for example gedit as well, I think 
it

was common to *not* list gnome-common as dependency in the jhbuild
modulesets because libraries like gtk was already depending on it.


Hm, indeed, gedit does not use gnome-autogen but it does use 
GNOME_COMPILE_WARNINGS. It must be getting pulled into the build 
environment by one of its dependencies.



Also, I think it's a bit a waste of effort to first port to
autoconf-archive macros, and then porting to meson just a few
development cycles later.


Getting rid of gnome-common takes about 10 minutes at worst, but 
porting to meson is a much larger effort!


Michael

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

Let's kill gnome-common!

[mcatanzaro]

Hi,

I want to remove gnome-common from our BuildStream projects, but a few 
modules are still depending on it: gcr, gnome-autoar, libnotify, 
adwaita-icon-theme, gnome-menus, and gsettings-desktop-schemas.


If you help fix these sad modules, you'll earn the right to say that 
you helped fix these sad modules.


Thanks,

Michael

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

Re: 3.27.90 tarball deadline extended

[mcatanzaro]

On Fri, Feb 9, 2018 at 8:36 AM, Bastien Nocera  
wrote:
It was clear from the earlier mails that the release-team would be 
using BuildStream, it really wasn't explicit that the developers and 
maintainers of individual modules were also being asked that.


To be clear, we're not asking for that. You can use whatever tool you 
want.


JHBuild was previously the easiest way to generate a release tarball 
for GNOME. Now we intend for BuildStream to fulfill that role. So, 
going forward, it will be our recommendation to use it. But you 
certainly don't have to. It's just a tool, after all.


Michael

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

Re: 3.27.90 tarball deadline extended

[mcatanzaro]

On Fri, Feb 9, 2018 at 9:14 AM, Emmanuele Bassi  
wrote:
Whatever maintainers use to build release tarballs is fine — as 
long as you ensure that you're always keeping the build of the whole 
GNOME set of modules running.


Yes, this!

Milan, feel free to do the .91 release whenever you want. Or you could 
do it now and call it .90.5, or whatever you want to call it.


The delay seemed appropriate because, having advised maintainers to 
switch from JHBuild to BuildStream, but not having any way to generate 
release tarballs with BuildStream, was not a friendly situation for 
maintainers. I had provided guidance that was not possible to follow. I 
know you're used to releasing without using JHBuild, but that can be 
difficult, and anyone who relies on JHBuild to make releases and 
followed our advice to stop doing so would have been stuck. Hence, some 
extra time to figure out what we were doing was needed.


Michael

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