My involvement with PyGObject

That being said most of my hacking time will be spent on OpenShift related projects and while I had already transitioned out of day to day PyGObject maintainership some time ago, I will no longer have any real time to dedicate to the project (I’m actually learning Ruby right now). To tell the truth, not being able to put any more serious time into the project is one of the major reasons I decided I needed a change. There are a number of other people still contributing to the project but it is sorely in need of a lead maintainer who can do releases, keep people on schedule and ping the right people when bugs languish. I feel PyGObject is in good shape but as it begins to get more uptake bugs fixes need to be committed, edge cases corralled and the last mile needs to be traversed. I will still hang out in #python on GIMPNet and can be persuaded to look at patches or even write a few if you ping me and are nice.

Jobs

With me leaving the Fedora team there is now an opening for someone to join the team. They are looking for an all around FOSS rock star who can work in a number of different areas such as packaging, desktop and web development, and any number of miscellaneous skill your would encounter with any FOSS project. The main responsibilities would be maintaining, improving and integrating our infrastructure tools such as Fedora Community Packages web app, Bodhi update tool and Fas accounts system as well as developing tools to make it easier to contribute to Fedora. Most of the tools are written in Python so being a Python expert is a big plus as well as having worked as part of a team on any major open source project. If that sounds like fun to you send me your resume (I get a bonus if you get hired).

OpenShift is also expanding so if any of these jobs look more like your speed feel free to mail me also.

Because we value the huge benefits Python has brought to Fedora and Linux, it isn’t enough for us to simply build on top of a great system.  We feel the infrastructure and Python upstream communities themselves are worthy of investing in and have taken an active role in helping to port and maintain a number of Python 3 modules.

It is with that in mind that I announce the first release of the Python 3 enabled PyGObject module on Fedora Rawhide. To install it you can simply do this:

yum install python3-gobject

We are hoping to get Fedora 14 package available once the noncritical path gobject-introspection dependent libraries are updated.  Failing that I will create a look-aside repo for those who want to play with it.

This is a small step in our porting efforts, all be it one that allows us to start porting many of our python desktop applications.  While we have been quietly helping with the Python 3 transition for awhile now, look for Fedora to start to accelerate our adoption of Python 3 in future releases.

Thanks to Carlos Garnacho’s recent work with the evdev driver and Gtk+ along with Peter Hutterer’s work on getting  the multitouch situation sorted out inside of X, not to mention everybody else who has contributed to the effort, I was able to get Multitouch working on my Fedora 13 powered Lenovo T410s.

All the following instructions relate to those who have N-Trig multitouch devices. Mileage may vary with other devices. To start playing around with multitouch in Fedora today you will need

• my evdev multitouch RPM packages built from Carlos’ branch
  • Warning: this package obsolete xorg-x11-drv-evdev so you will no longer get updates from the Fedora repo
  • Note: I’ll provide a yum repo for my packages once Koji is up and running again, for now if you don’t have an X86_64 machine you will need to rebuild the source rpm.
• If you have a N-Trig device you will also need to get the kernel Kyle built which has a fixed N-Trig driver (hopefully this will show up in an update soon).
• You will also need Carlos’ xorg.conf snippet. This is again for the
  N-Trig driver but should be easily modifiable for other devices
• To play with multitouch you will need the latest Gtk+ from the xi2-playground branch

I recommend building Gtk in a jhbuild environment or at least don’t install it since it is the unstable 3.0 branch. Once the multitouch stuff has been backported to 2-20 branch I will start providing packages. I take no responsibility for the breakage of anyone’s machine due to replacing such a major system package. Thankfully, if you run inside of jhbuild you can play around all you want without fear of breaking your system. Another option might be to run inside an virtual machine but I am not sure if multitouch events will propagate correctly yet.

If you want to play with some demos you will find them inside the tests/multitouch directory of Gtk. Have fun and ping me with any issues you have. It might be nice if we got this working for Fedora 14. The pieces are certainly falling into place.

The project I have been working on for a long time now has seen it’s first (beta) release. Meet Fedora Community, a consolidation of the various Fedora Infrastructure bits into one UI with a focus on usability. The unique thing about this site is that it doesn’t replace the other Fedora Infrastructure bits. It uses them as backends and mashes together the data into one view. For instance you no longer have to go to the bodhi update tool after checking on a build in koji. Instead you simply look at the build tool and if the package is able to be updated you will be presented with the option to do so. It will also point you to the correct log if an error happens in the build.

Right now it is geared towards Fedora packagers but in the future we hope to be adding a lot more functionality. Since the concept revolves around small applications running in a dashboard the possibilities are endless. Think live server status for sysadmins or up to date Fedora news for users. As always, because Fedora stands for Freedom and Community we will be emphasizing upstream collaboration which we owe a great debt for making all of Fedora possible, and Fedora Community’s code will always be licensed under AGPLv3 and compatible licenses.

To learn more you can grab the podcasts (in ogg vorbis format of course) or go to our project page.

Fedora Community, codename MyFedora, integrates the Fedora infrastructure into one interface focused on usability and streamlining user workflows.  This is a beta release with a production version to be released alongside Fedora 10.  While the first revisions are focused on Fedora Developers, the underlying Moksha framework, based on top of the Python WSGI TurboGears 2 platform, provides a base for writing self contained applications which can integrate to create one large application.  The applications seen on Fedora Community interact with the Fedora infrastructure to produce a single, unified view.  In the future applications can be written to interact with Transifex for translations, listen to upstream for project releases and even federate between infrastructures such as OLPC being able to have a view into their services along side the services they use in Fedora.

We are calling on Fedora members to test out the site and file bugs.  We plan to roll this out alongside Fedora 10 so pitch in and help us make a great release.

Your site regarding %TITLE% looks very interesting to me. I found it doing a search for %KEYWORD%….

If you can’t even get the template right … try harder not smarter, because I know you are as dumb as a rock.

In other news look for some Fedora announcements from me pretty soon.  I’ve been pretty under the radar recently in terms of what I have been working on.  It has all been public, just not publicised.  Revolutionary, probably not.  Those who know me know I like calculated improvements.  A step forward…let’s just say I am proud of what I am doing and have to praise Red Hat for having faith in me and my plans to let me work on things I felt were important.  There is a reason they are not just a pay check to me, and part of that is their belief in the power of free and open source softaware and the confidence in developers who work on the betterment of not just the company but the community and the ecosystem as a whole.

It seems that a “feature” that Microsoft implemented in the Windows 9.x days has appeared in Plymouth. Yes that’s right, that “feature” the I.T. world grew to hate, holding down the Ctrl or F8 keys to get into Windows Safe Mode (http://support.microsoft.com/kb/180902/en-us) has invaded Fedora. Ouch!

Now, if I take a step back, I can completely claim the following:

• Plymouth takes away my freedom of choice (a freedom that has become a basic Human Right
• Fedora has taken three steps back to gain one step in the name of ‘usability’

The funny thing is Mac has this feature also (hold c to boot from cdrom etc). Let’s repeat after me, “having to hold down one key after boot does not take away my freedom of choice”. And while we are at it, why do people fling around phrases like “freedom of choice” so cavalierly? It gets to the point where those once powerful words become watered down and an instantly marks ones argument as suspect. I know, let’s give more freedom of choice by bringing up the bios every time they boot. There is a lot of choices in there.

If there is an argument to be had here it is about continuity and discoverability. On the continuity side, if someone is used to seeing grub every time they boot it might be nice to keep that feature or something equivalent on upgrade but not on a fresh install. On discoverability of the feature, I would agree this is where the fustration comes from. However for the small number of (potential) users who actually like grub it would be wrong to add another option to the install. It would be much better as part of system-config-boot and if possible as an option in grub itself so that people who need to switch often can set it the first time and never have to hold down a key again. Hell, if I dual booted a lot I would like to have a key assigned to each OS I boot into but then again with virtualization being pretty good, there are better ways to run a separate OS.

Put it this way. Users may have kicked and screamed when Windows integrated DOS but Windows usage still grew. When MS decided not to show the text boot menu, again usage still grew. The way I see it is polish opened up the world of computing to more and more people.  By not polishing Linux and staying in a mindset that change is bad we will be stuck in the past while the rest of the world moves on. That is not to say every change is good but good reasoning went into this particular change and so far I haven’t seen any legitimate argument for not having it. Let’s repeat again, “having to hold down one key after boot does not take away my freedom of choice”.

• Federico’s screencast of rpm2git tool – we should be using this or something similar

The second reason given, which has to do with building a community is pretty broad but more believable.  Fedora has made huge strides while also sticking to its guns in the freedom department and being valuable upstream contributors. It may be that we sacrificed short term gains which can be gotten via a bit more differentiation, or out of the box “just works” on closed hardware but as companies are being convinced to open up their specs and open drivers are being written, a large portion of which is being done by Fedora developers working upstream, little of the short term gains matter much.

I suspect the real reason is somewhere in the community vein, staring with the Kernel and X team developers who work tirelessly making sure their work is fit for upstream consumption and can be supported in the long term. Following their lead the rest falls naturally out of that single notion of moving Linux forward as a whole. Kudo’s to all my Fedora friends – keep moving forward.