This basically means ideas for tools, scripts, or functionality in some hypothetical centralized maintainer helper website or GUI/CLI program that would help save time in taking care of some of the gruntwork that gets done by maintainers right now manually or by scripts that don't get shared and re-used and generalized as much as they could.

Then afterwards I can sort through the suggestions/ideas, try to make a summary and arrange some of them to actually happen.

If things get done quicker, there is theoretically more available time, which hopefully would translate into being able to bring us back to the bleeding edge in one hand, and high quality in another.

I have intentionally left out my own ideas at start to keep everyone's mind open to various approaches to this.

Please share your thoughts and ideas as a comment here, on my matching e-mail thread to gentoo-dev mailing list or via private e-mail!

(I think with this post I prevented my blogging pause to not reach over a year by about 20 minutes )

Upgrade guide here (updated April 3rd); bugs go here of course. Praises (to the whole team, I am just one) go in comments right here or whereever we see, general complaints to /dev/null or comments as appropriate. My appreciation for the GNOME upstream goes to Planet GNOME with right this post (Thanks for the nice release!)
And now I mv /proc/self /dev/bed and hope stuff doesn't break too much.

In addition, there are rumors that I am myself now working since mid-January at Artec Design LLC as an Embedded Software Engineer.

So what was wrong you might ask?
Well, let me explain then, at least then this post might be somewhat useful to Planet GNOME readers, considering that there are some notions that other programs might be affected:

Somewhere in the 2.17 development cycle, gnome-power-manager added code to handle some special X keysyms, such as XF86XK_PowerOff. This code is realized through a callback from the gdk_window_add_filter mechanism. The documentation of it says the following:

Adds an event filter to window, allowing you to intercept events before they reach GDK. This is a low-level operation and makes it easy to break GDK and/or GTK+, so you have to know what you're doing.

If the GdkFilterFunc() callback returns GDK_FILTER_REMOVE then the processing of this event is stopped and gtk+ won't see it, if it returns GDK_FILTER_CONTINUE then it's continued and gtk+ will see it if some other filter that might be set up doesn't stop it.
When a notification area applet is ready to accept icons, it acquires ownership of the _NET_SYSTEM_TRAY_Sn (n is the screen number) X selection on MANAGER atom and GtkStatusIcon takes notice of this through a XClientMessageEvent that is listened in a GdkFilterFunc of its own to know when it can create the icon and set up some other filters for a (orientation) property and destroy notification.
Now, the gnome-power-managers filter that is set up tries to filter for keypresses to catch the power management related ones and return GDK_FILTER_REMOVE for those and any other event gets a GDK_FILTER_CONTINUE. Well, that seemed to be the plan, it's just that instead of
if (xev->type == KeyPress) { ...; return GDK_FILTER_REMOVE; } return GDK_FILTER_CONTINUE;
there was
if (xev->type != KeyPress) { ...; return GDK_FILTER_REMOVE; } return GDK_FILTER_CONTINUE;
stopping propagation of any non-keypress up to gtk+ and especially gtktrayicon-x11.c that was trying to listen to xev->type == ClientMessage type of events on the X root window for knowing about the tray manager appearing to create the tray icon into it. Whoops. No icon, no reaction to the keys.

So, lesson of the day - if you are an application or daemon with a tray icon be triple-careful if you need to use gdk_window_add_filter for some reason, or you might end up with the icon not appearing if the app is launched on startup or when the notification-area-applet (or any other notification manager) is reloaded manually or on a gnome-panel crash. You already need to be double-careful in using this mechanism and use it only when really really necessary - it's a great way to make GDK or GTK+ break, just as the documentation says.

This is already fixed on trunk in the gnome-power-manager case, as per the relevant bug. Thanks, Richard. Also many thanks to Shogun, who figured out this happens in the --enable-xevents specific code, which is also probably the reason many of the other distros weren't affected as they likely just don't use this configure switch.

And, again, if you use a workaround hack for this, please remove it after getting the revision with the fix (now or in the near future in case of a stable tree usage) as starting gnome-power-manager twice is no fun

Now that GNOME-2.20 is unleashed to ~arch in Gentoo, I can come out of hiding again and try to blog again, as all the cool guys are doing.
As this should be the first post that gets to Planet GNOME - Hello Gnome-ers! Therefore also a quick introduction might be in order:
My name is Mart Raudsepp, I'm from Estonia and I'm a member of the Gentoo Linux GNOME team. That's enough, m'kay? Oh and you might have noticed my mug in Vilanova or Birmingham.

So, coming back to the real topic, I'm intending to gather some feedback about Gnome and Gnome related packages in Gentoo.
Please put anything Gnome related that you have always wanted to see in Gentoo, but still don't, in the comments or e-mail me (leio AT gentoo DOT org).
Any cool ideas or technologies we should integrate? Any cool packages we are missing? What about GNOME development tools and Gentoo as a development platform for GNOME libraries and applications - anything we can do to help there?

Lets see what we really miss based on the comments/mails and we'll see what we can do about it
Now, go comment! I'll look forward to it and do a follow-up post later.

Now that GNOME-2.18 is stable, cleaning up of GNOME-2.14 from the tree is ongoing. This also means that linux kernel 2.4 subprofiles will loose all GNOME versions, which hopefully isn't a problem because I can't imagine why any desktop would use linux-2.4 still.
Someone please kill off these subprofiles completely, pretty please

For the short-term future my plan is to get some more 2.18.3 version bumps in and stable all the remaining 2.18 updates soon too, which shouldn't be a too big amount of packages. Also 2.20 is upon us soon, for which we will create action plans and take other measures to not slip with unmasking and stabling this time around. 2.19 is having a good life in the gnome-experimental overlay meanwhile, of course. We also have two new team members (hi!) rocking along and helping out a lot and covering times when me and/or Daniel are too busy with work, so the future looks good.
Stay tuned for some GNOME related public comment requests in some days

As I'm already in London, I will be at the Gentoo UK Meeting as well, and also at the "socializing event" the evening before (i.e, now), if welp would hurry up so we could head out
I will arrive to Birmingham for GUADEC depending on what happens after the official Gentoo Meeting schedule, I guess.

We decided to go back to stabilizing GNOME in at least two steps again.
GTK+ and co in the first step, followed by the whole of GNOME as the second step.
So there is now bug #156572 for stabling gtk+-2.10 and co. It seems that amd64 is done already

Note that when going from gtk2.8 to gtk2.10, you need to rebuild packages that provide gtk modules (librsvg, gtk-engines and so on), as the modules ABI was upgraded from 2.4 to 2.10 - the gtk ebuild gives information about this too.
Additionally there might be problems with notification daemon related stuff, as noted in the GNOME 2.16 Upgrade Guide, probably won't hurt to also do a revdep-rebuild run just to be sure.

Next step is GNOME-2.16 stabling and I hope that will happen soon...

The step after that?
Why are you asking. World domination of course.