Matthias Clasen | 24 Oct 16:32 2014


Time flies,

and it is already time again to put out cool new features - 3.15.1
tarballs are due on Monday!
To get the 3.15 cycle underway, I've now put up the schedule here:

Please consider telling us what your plans are for this cycle, so we
can our job and manage the releases.


Release Team | 24 Oct 02:00 2014

GNOME 3.15.1 unstable tarballs due (and more) (responsible: mclasen)

Hello all,

We would like to inform you about the following:
* GNOME 3.15.1 unstable tarballs due
* Feature proposals discussion heats up

Tarballs are due on 2014-10-27 before 23:59 UTC for the GNOME 3.15.1
unstable release, which will be delivered on Wednesday. Modules which
were proposed for inclusion should try to follow the unstable schedule
so everyone can test them.  Please make sure that your tarballs will
be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
will probably be too late to get in 3.15.1. If you are not able to
make a tarball before this deadline or if you think you'll be late,
please send a mail to the release team and we'll find someone to roll
the tarball for you!

Feature proposals discussion heats up

For more information about 3.15, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.15

For a quick overview of the GNOME schedule, please see:


Automatically generated email. Source at:
(Continue reading)

Alberts Muktupāvels | 17 Oct 18:48 2014

maintainership of gnome-screensaver and notification-daemon


last releases for these modules are two years old. These modules are no longer used in GNOME, right?

Modules are still used in unofficial GNOME Flashback session so I would like take over maintainership of these modules.

I sent mail to current maintainers of notification-daemon one week ago. Till now I have not received response.

Alberts Muktupāvels
desktop-devel-list mailing list
desktop-devel-list <at>
Magdalen Berns | 17 Oct 17:37 2014

java-atk-wrapper maintainership

Hi list,

I would like to support the new java wrapper maintainer, Alejandro with the task of maintaining java-atk-wrapper since the whole module needs updating having been abandoned back in 2011 until recently when I submitted a patch to allow it to be built successfully on the latest version of GNOME[1,2]. I also updated the doap to reflect reality and conform to the latest doap standard used by GNOME[3]

The first commit since 2011, were just this week and, it's fair to say that the module has generally got a bit old and suboptimal over time.[4]

I reckon it would really be great to put a bit more brainspace and time into improving things for java(by making use of what the most current java API can offer and ensuring that the module is wrapping the latest interface methods. For example, at the moment the text interface is completely outdated and this is likely to create problems for users if it is not dealt with.[5]

Provided there are no objections, I will add myself to the doap file and maintain this module.

Many thanks,
desktop-devel-list mailing list
desktop-devel-list <at>
Alberts Muktupāvels | 17 Oct 08:22 2014

session-dependent defaults in GSettings


I have seen few commits with following message - "There are plans to add session-dependent defaults to GSettings (based on the newly standardized XDG_CURRENT_DESKTOP);"

Has someone actually started to work on this? Is there some info, page or something like that where I could get more information and follow its progress?


Alberts Muktupāvels
desktop-devel-list mailing list
desktop-devel-list <at>
Release Team | 17 Oct 02:00 2014

New feature proposals period end

Hello all,

New feature proposals period end

For more information about 3.15, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.15

For a quick overview of the GNOME schedule, please see:

Automatically generated email. Source at:

devel-announce-list mailing list
devel-announce-list <at>

Andrea Veri | 16 Oct 16:23 2014

MASS REBOOT: Saturday 18th of October, 10 AM - 11 AM CET


we'll be rebooting all the machines this upcoming saturday morning to
apply RHEL 6.6's updates.

The time window will be around 2-3 minutes of downtime per service. As
usual keep an eye at:

As a side note, this will be my latest maintenance announcement e-mail
to both desktop-devel-list and foundation-list as I'll be primarily
using infrastructure-announce [1] for such announcements from now on
after transitioning to it a few months ago. If you didn't already,
please subscribe to that list to not lose any maintenance, outage

Have a nice day!





Debian Developer,
Fedora / EPEL packager,
GNOME Infrastructure Team Coordinator,
GNOME Foundation Board of Directors member,
GNOME Foundation Membership & Elections Committee Chairman

Frederic Peters | 15 Oct 17:40 2014

GNOME 3.14.1 is out

Hello all,

Here comes our first update to GNOME 3.14, it has many fixes, various
improvements, documentation and translation updates, we hope you'll
enjoy it.

We will soon publish the schedule for our next releases, and a first
development release, 3.15.1, should soon hit the streets.

For more information about the major changes in GNOME 3.14, please
visit our release notes:

Release Details and References

The lists of updated modules and changes are available here:
  core   -
  apps   -

The source packages are available here:
  core   -
  apps   -

And if you want to compile GNOME 3.14.1 by yourself, you can use the
jhbuild modulesets available here:

See you next time!


devel-announce-list mailing list
devel-announce-list <at>

Matthias Clasen | 13 Oct 15:24 2014

Webkit2 porting


one thing that was discussed a bit here at the Boston Summit is the
situation with webkit - we are currently depending on both webkit1 and
webkit2, which is not a good situation. Unfortunately, porting to
webkit2 requires some work (in the case of geary, quite a bit of

I've started to set up a page here to track this:

It needs a lot more information - I'm not an expert on webkit, so any
help in fleshing this out would be appreciated.

Dave Airlie | 13 Oct 08:53 2014

output setup and configuration, what lives where?


So I've been looking at 4K monitors that require DP MST and present as
two screens with some tiling info in the EDID extensions, and I've
been taking a look at how to integrate these with gnome.

Just to clear things up, I tried to hide these in the kernel, the side
effects were too messy to cover up, and stuff broke in wierd ways, so
I've decided to follow Windows and push this up a few levels.

So I've built a kernel property to describe tiles, and passed it
through X to test, and hacked on mutter 3.10, so

a) windows maximize properly
b) initial mutter configuration picks a sane config.

( - will eventually have it).

Now the question is what else needs changing for this, I know I should
probably start to target master or least F21 versions and I'll
probably get to that,

I'm getting the feeling at least,

will need work, control-center will probably need design work so the
UI doesn't suck for this use-case.

I'm just not sure how things like monitors.xml fit in, who writes this
file, who reads it, is there
some stuff talking over dbus here, does gnome-session-daemon get
involved anywhere etc, so pointers/answers etc all appreciated.

Vamp898 | 12 Oct 22:08 2014

Code Quality

Since GNOME change the "Official Language" to GJS i've seen several

- Applications got started in GJS and got re-written multiple times
until they have been written in Vala or C/C++ (sometimes Python)

- Fine working applications got re-written in GJS without any advantages
so far

- Code Quality of new contributors writing JS is kinda very low

Afaik GJS was choosen for GNOME to reach more people because much more
people write JS.

Did anyone ever thought about why JS is written by more people and
studied what affect JS have on code quality? I did!

Thats because in JS its very easy to be very bad and still have workable
code. Thats all. You can be a complete noob and still write working
applications somehow because JS makes it very easy.

Not to mention CPU and Memory usage, what i care about is code quality.

The question is, is that what GNOME wants? Worse code?

I dont want any war of Langauges or something like that, but every JS
Developer can aggree when i say "Its easier to be bad in JS and get away
with it" and that is exactly what i think to notice right now.

That doesnt mean that there arent good JS Applications, the opposite
(especially the GNOME-Shell), not that it is dependend on the Language,
its all about the developers. An good developer can write excellent
(G)JS Code. Its not about the language.

I dont care about making JS bad at all! JS has a good place in GNOME
Development, what i care is about the Advertising of GJS for GNOME.

"We choosen a language every 12yo kid can write applications with, so do

Does GNOME really want all those 12yo programmer beginner who write
"throw away" code which have to be re-written multiple times until you
get an usable application?

What i especially care about is

- How much more usable Code does GNOME get since using GJS
- How much work is it to maintain the JS Bindings
- How much work is it to clean up the bad JS code
- What type of applications get written in JS and how much work would it
be to write them in Vala or Python

I think its quite clear what im targeting on. Providing GJS brought more
code, but in a lot of projects mostly more bad code, which is mostly not
re-usable and so causes, in addition to maintain GJS, a lot of
additional work.

Also Languages like Python or Vala are so easy to use, that its only a
tiny bit of more work to write them in Vala or Python. Sometimes its
even the same amount of work.

Also GJS causes more CPU and Memory load which will also increase if
more applications get written in GJS. So the overall experience for the
user decreases with heavier use of GJS.

Does this sum up in the end? Does anyone want to create an chart on
this? Maybe an RedHat Employee ;)

Quote from GNOME-Music

"The result? GNOME Music is now more stable and faster! We used
profilers to find the parts where a lot of memory and/or time is being
wasted. The code now is easier to read too."

GJS is a usable language, as said, but maybe GNOME should rethink what
their preferences are and what language meets those preferences most.

In my personal oppinion "More but worse code" should not be the
preference of a Desktop Environment. Nobody cares if GNOME only have 2
but 7 Music Players, but everyone cares if 7 of 7 are crashing and bad.