I'm collecting ideas from the wider development and contributing community on how to help maintainers and contributors get work done quicker, or rephrased - how to get more done in the limited time we have.

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 )

Yes, indeed, GNOME 2.22 is now unmasked in Gentoo and entered ~arch and the updated profiles should be on the way to a mirror near you. But only ~x86 and ~amd64 for now, as there is still some keywording work to prepare for the rest. As I'm pretty much exhausted from the intention of getting this done before sleep and it getting done past 5am, I'm gonna be short and sweet.

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.

Rumor has it that Skype might be willing to add PulseAudio support to their Linux version, as long as they get all the help necessary to make that a smooth process. A meeting is rumored to happen on that topic tomorrow, where some finger pointing to relevant and interested PulseAudio community members could be useful. As rumors have the tendency to get the facts twisted, see the linked origin if interested.

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

Yes, that's right. gnome-power-manager-2.20.0-r1 in Gentoo now shows its tray icon after GNOME startup.
So everyone using some workaround hacks (usually involving scripts with sleeps, killalls and restarts), please remove them after upgrading to this revision
As Gnome-2.20 is planned to go to stable tree quite soon, I didn't fix the 2.18 series.

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

Hello,

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.

So the long-awaited (sorry about that) GNOME-2.18 has gone stable on most of architectures now. I would like to remind the GNOME-2.18 Upgrade Guide, which I also updated half an hour ago for some minor corrections. As Daniel already noted you better upgrade with revdep-rebuild -X as this ought to fix expat breakage and upgrade GNOME/KDE at the same time, reducing pain.
I would use revdep-rebuild -X -- -va myself to see what it will do
If still some pain happens, especially related to intltool, you might want to rebuild sys-devel/gettext and dev-perl/XML-Parser manually as the first thing and do a revdep-rebuild -X again, if it didn't order them first otherwise.

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

Just like Andreas, I will be heading to GUADEC as well and be there the whole week. So if you are there, then we should meet up! I might be even convinced to get stabilization of GNOME going in Gentoo with some beer
To my knowledge remi and eva from the gnome team will also be there from Sunday. Who else from Gentoo? Let us know! I think zaheerm?

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.

News from the GNOME stabilization front:

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.

I figure that as I haven't really blogged much as of late, I could just as well note what my latest commit spree was about (related to that - go beat my todays commit count on cia.navi.cx in a productive way ).

I cleaned up redundant versions in the GNOME packages, which mostly amounted to removing the versions for earlier than GNOME-2.14, plus some old 2.16 versions that have a newer version in the tree for 30 days already or the ones with bugs while only a newer version has fixes.
In total about 100 different versions/revisions were removed, so I hope that helps a bit to rsync times and mirror server space.

And, no, no gnome1 packages were removed in the process, just a few revisions that had newer ones in the same major.minor version-set available. That cleanup is for when they have sat in p.mask for long enough and for certain someone else.

Many things not officially part of upstream GNOME haven't been cleaned up yet, as well as some of the most core libraries, just in case (and fear of being reprimanded when removing them ) - such as glib, pango and gtk+.
There is also lots of redundant gstreamer/gnome co-maintained versions around. Could someone at home with gst maintenance take a look please?

I hoped to get the redundant gnome herd (co)maintained ebuild revision count down to ~200, but ended up at 325 for now, from around 420ish at the start of my long "day".

At any rate, the current reason to do the cleanup is more or less fulfilled - easier generation for an GnomeUpstreamDelta wiki page for official GNOME modules, listing patches that we apply on top of upstream tarballs, with an explanation of what it does and if and where it is filed upstream to reduce the delta. This is in line with other distributions doing the same. I believe Luis wanted to start with a proper page of ours very soon

PS: pcheck repo -c RedundantVersionReport rocks.

That is all.

Yes. That's right.
GNOME-2.16 is out of package.mask and now nearing your unstable ~arch systems closest mirror with the speed of, , electrons.
This is currently a 2.16.1 version of it.
For the rare (sub)profiles using Linux kernel version 2.4, GNOME-2.16 will stay masked, due to it requiring HAL (Hardware Abstraction Layer) quite heavily. The Linux version of it uses udev, which is new in 2.6 kernel. These profiles will however now get gtk+-2.10 with the necessary dependencies in their ~arch.

There is an upgrading guide over here:
http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml

It is likely that it will gain more items to it over time as things come up.

Enjoy! I know I am.
For the stable machines, well, the clock is ticking now.

Thanks to the GNOME desktop team for pulling this through!
I just got to do the finishing touches

Oh and I received a Gentoo GNOME team member badge some time ago for some reason

I finally got around to bumping wxGTK in the tree to 2.6.3.3 with all the changes like migrating completely away from using the wxlib.eclass, fixes for stuff that I considered blockers for considering 2.6.3.2 being a stabling candidate, and so on.

As there seem to be reasons to shorten the 30 day stabling policy a little bit for this one, I would appreciate testing success stories in my leio@g.o mail, and failure stories in bugzilla ASAP

Next stop, wxpython-2.6.3.3. I would say tomorrow, but judging on the date I gave for wxGTK, I will not say one this time.

Oh, and if I were a maintainer of a package that has any version that depends on wxGTK-2.4 left in the portage tree, I would take care of cleaning out old ebuilds and making sure things work against wxGTK-2.6, as next next stop is nuking wxGTK/wxpython-2.4.x out of the tree for a well deserved permanent retirement.

Hey, hey.

So I decided I should do this first blog on this planet.g.o aggregated blog.
You can find my older blog posts from http://advogato.org/person/leio/ if interested for some reason.

I will be screwin^Wmaintaining wxWidgets related packages in the wxwindows herd (I'll get that name renamed to wxwidgets soon). Some might have seen my dirty fingers in the gnome-experimental overlay already, too - we'll see how soon I can get more involved in that front.
But first, I need to finish fixing the sad state that wxGTK, wxpython and co have been for a while in Gentoo now. I got them both already bumped to 2.6.3.2 back in April via proxy, but I don't feel comfortable about requesting stabilization of them as of yet.
First, I found out that me moving to using wxPython tarballs (which include all the necessary C++ code as well, or so I thought) - to get updates more often, have a matching wxGTK/wxpython version always and other benefits - made the wxrc util disappear (thanks to Vaclav Slavik for notifying me in this matter). Turned out wxPython source packages didn't include the utils/ folder and the wxGTK build system didn't care if it existed or not - it simply silently didn't build/install it. Whoops. wxPython author fixed that up quickly on request, and bumping to 2.6.3.3 will fix that automatically.
Secondly, I found that I broke ABI with the package source tarball switch. One virtual method was added to a widely used stand-alone class (the list control). Turned out a couple patches was applied to the sources before the tarball creation, with the patches nicely in a subdirectory. So just a reverse patching in src_unpack and voila - stable upgrades won't see any incompatible ABI changes (I will make checks, and hopefully right ). I hope ~arch users won't hate me too much, but it's why it's called unstable, and in reality I never saw any reports on this causing problems. I suppose adding something to the vtable doesn't break too many common systems, or it might be from the fact that people (upstream application ones) don't derive from that class all that often to care about that particular vtable.
Thirdly, after finding out why the wxDebugReport class was not built in Gentoo, I concluded that using the wxlib.eclass by the wxGTK ebuild is just plain broken conceptually. The eclass disables functionality for all 2.6 versions just because one version happened to be broken. wxDebugReport, accidentally precompiled headers (compile time), forcing of one make process (I've used -j2 on wxGTK local builds for over 2 years now...), and other things. So I have decided to migrate the ebuild over to not use the eclass anymore before I can feel comfortable asking stabilization of any wxGTK package. This migration is kind of done, but now there is still some afterwards cleaning up to do, fixing the MAKEOPTS ignoring, and so on. I will much later look into resurrecting the eclass as a new version, when it's time to look into making the initial idea why the eclass was created - multiple wxWidgets ports in the tree, sharing some building code in the eclass - a reality. As it was right now, just wxGTK ebuild used it, and the eclass contained all that nastyness that doesn't work for a wide range of different package version.

As for wxpython, it's mostly just about fixing the mess that is lack of python_mod_compile and python_mod_cleanup usage, which commonly leads to wxpython being broken on an upgrade if the USE flags or SLOT changed in the case of wxpython multiversion support.

Of course while doing the bump, I hope to fix as many bugs as I can without holding it off for too long.

Now to get back to working!