"Making Your First Contribution To Open-Source" Irish Hackerspaces Week 2011

A CG character in front of a laptop thinking of various open-source projects

I gave my presentation on "making your first open-source contribution" in Tog yesterday evening and I think it went down well; I enjoyed delivering the talk and received positive comments about it afterwards -- although I do need to speak louder. I'm enjoying lightning talks! Now, what to speak about next... :)

The slides are available on Slideshare (or PDF). I also gave a hand-out to give people a chance to check out the links afterwards.

- - -

On another note I think an evening of lightning talks was generally well received, and there is some motivation to run another similar event in 2 months. I'd love to have this be a regular thing. We need to be more strict on time-keeping though; surprisingly it seems people tend to feel bad for not speaking long enough, so they start just talking about random stuff or opening web links of cool things to show off... and interesting or not it feels like it's dragging on, particularly when one knows there's 3 or 4 more talks to go after.

I also got feedback from first time visitors that starting late "because people will be late anyway" makes it very sucky for people who don't know anyone yet, and also less likely that there'll be time to stick around after the talks to chat with the speakers and other attendees. I think we should start right on time next time (and to be fair, the 2 or 3 people who arrived between 7:00pm (announced time) and 7:30pm (actual starting time) were members... Not worth waiting for!!). It'd be nice to start on time and then encourage people to stay with drinks and cookies, or otherwise we need to find a social butterfly that is good at integrating people. :-)

Writing this down now, so that I can remember it in 2 months. Any other comments on the evening from people who were there, or general suggestions and tips on organising lightning talks?

(Irish Hackerspaces Week isn't over yet! Check out our other events.)

Leave a comment | 2 so far

Desktop Summit 2011 - Back!

The Desktop Summit is finished for me, though it continues on with workshop and BoFs.

Berlin's weather is pretty much like Dublin's with regard to the sky colour and rain status; though maybe with a few more degrees :) I quite enjoyed the conference, very happy to meet again the friends I made last year as well as meeting up with new interesting people (btw, if you asked about my card, it was made at moo.com: get yours now!!). It was also great to meet a couple of cool people whose activities I follow online, though I'd like to find a way to introduce myself to someone I know who doesn't know me in a perhaps less creepy way :o) (Sorry people, it was still a pleasure!)

I found less elation in the technical talks this year than last, perhaps because it's difficult to beat the excitement of seeing Gnome 3 work for the first time, pre-release. The ones I attended were still interesting and hinted at all the solid work that is going on currently, and I really enjoyed the many discussions on outreach, collaboration between the projects and within projects, and all that goodness. The Gnome State of the Union talk was a hoot, and one of the highlights for me was when they showed a list of quotes from unhappy users, like "if they treat their users like idiots, they should expect idiots as users" (or something like this), etc., as we're seeing online at the moment. It turned out these quotes were about the Gnome 2.0 release, and this makes me hopeful once the dust settles down, people will look at Gnome 3 with less of a knee-jerk reaction (and might still decide it's not for them, of course).

I will try to put together my notes into a few posts, though I can guarantee I won't have the time to be as thorough (or long-winded, depending on the point of view!) as in my notes for EuroPython unless I get the flu or something.

Many thanks to the organisers for putting together the conference and parties, I had a great time -- s'y'all next year!

Leave a comment

Desktop Summit 2011

I'm going to the Desktop Summit 2011

Tomorrow morning at ass o'clock, I fly to Berlin to attend the Desktop Summit \o/ The talk schedule looks fantastic and I'm really looking forward to it, and to meeting again the friendly people from last year as well as new friendly faces.

Woohoo! See you there!

Leave a comment

GUADEC: Inside the Banshee Awesome Factory

Eek! Looking through my old drafts I can't believe I forgot to post this. I was waiting for the LWN link to become available to all -- but I guess it's never too late to share the awesome.

Article: GUADEC: Banshee project reaches out for contributors (LWN)

This is the summary of a very good talk, "Inside the Banshee Awesome Factory" from last GUADEC, describing a number of things that the Banshee project does to attract, welcome and nurture new contributors. For instance, they make sure to make plugin development fun, by automating away the boilerplate code -- kinda similar to starting a new project in Django (I wonder if that's something Sugar could use, to create new Activities...) Every contribution is equally appreciated, including the "typo" fixes that many people would start with. They're not afraid to welcome people with little programming knowledge, and walk them through how easy it is to fix a bug or add a new feature. I suspect this works fantastically to also attract good people who are not overly confident in their skills. The speaker wasn't scared to live-demo how easy it is to add a new feature, particularly if it's similar to something existing -- actually he was a very good speaker, if you have the time you might want to catch the video of the talk itself (day 3, Paris room, 10:15-11:00).

A very cool stat I forgot about, that's in the article: in the last 2 years and a half of development, Banshee has averaged one new contributor every week. That is awesome! It's worth looking into what it is they're doing right.

Leave a comment

Gnome Development Documentation & Tools HackFest Retrospective & random thoughts

I just got home back from Berlin, where I participated in my first HackFest.

First day, first impressions

I was about 6 hours late for the first day, mostly due to weather related delays at Dublin Airport. I would have been a little late anyway (not enough days off left to fly in on Wednesday), but once there I quickly realised how beneficial it would have been to arrive a day early, attend the Welcome Dinner, and get to know people (at least names!) before trying to work with them. Lesson learnt for next time.

The first day was mostly discussions and planning what should be done, and toward the end assigning tasks to people for the following days. The whole HackFest thing is very focused, that first day was a lot of nerdy discussions except with a focus on getting things done (and thus not much patience for staying off topic). People were also careful not to make decisions for the whole community.

During most discussions, a few people were dominating/leading the conversation, which I wondered a little about at times. Some voices sometimes got ignored because someone louder started speaking or answering a question over them.

Being late meant that when a couple of topics I have an interest in came up, I didn't have yet a good enough grasp of the group dynamics to be able to chime in (my fault for being late and not speaking up anyhow). For instance someone mentioned the idea of a "Kid's corner" in the documentation for school students to learn about Gnome development. That's a topic dear to my heart, and what an awesome idea! There was no time to work on it during the HackFest but in case the idea surfaces up again I hope I will be around to listen in and participate.

In the end, the main plan became to work on a catalogue of "cool" demos to show and teach about different aspects of the platform -- first applications at a level a little bit above "Hello, World", for developers to try and expand on with their own cool ideas (the licence for the code in the documentation will allow for this, of course). Some people worked on other cool stuff.

The HackFest continues

I kinda messed up day #2. I can't help with writing code examples because I wouldn't know how to do most of them yet, and I haven't internalised best practices in Gnome Development either. So I kinda hid instead (I still had a good time! But I felt bad for not contributing enough).

I could have helped with writing, but it turns out most people wrote at fine to awesome levels all on their own already :) That left me with trying out tutorials and reviewing them with the fresh shiny eyes of a newcomer to the platform, which required the tutorials to be written first.

From day #3 I started jumping on people as they entered the office and constantly asking "Do you have anything you'd like me to look at?" so people knew to send things my way. Turns out some libraries (like libgda or webkit) couldn't build this week due to changes in gtk3 and I ended the day with Gnome Shell not starting on my machine, GStreamer behaving in the strangest way and also a better knowledge of Jhbuild ("Erm, could someone with a few minutes help me understand a Jhbuild issue?" - " *laugh* You do realise the maintainer is sitting besides you, right?"). Things merrily continued till the end of the last day, and I managed to test and review several tutorials and increase my knowledge of GStreamer, Javascript-the-Gnome-way, Clutter and Gtk, as well as learn about Mallard (the real question being, MAllard or mallARD?), glühwein, and how to say croissant in German (that's "croissant").

Sometimes someone would bring up a topic of conversation (intro to Mallard, what to include in the platform overview, how to revamp developer.gnome.org, ...) and people would assemble around the table, maybe use the projector and discuss what direction to take.

People did a beautiful job with the demo examples I got to test. They are simple, well explained, quick to try out and you do learn a lot when you go through them, while usually still getting a hint that there is more awesomeness to find if you dig further into Gnome. Most of the problems I encountered won't be problems when people run the examples on a stable Gnome 3 system in the future, as opposed to an active/fluid development version within a sandbox. I kinda failed at being a good representative of Python-as-a-first-class-citizen though: no example was completed in the Python language over the 4 days! C, Vala and Javascript will be nicely represented though.

People are very much "Work hard, Play hard" in a hackfest environment. Thanks to our Openismus hosts we got to work in a nice office, be introduced to lovely restaurants and visit a Christmas market among other things. People would go out at night and then come back to the office around 10 or 11pm and work longer into the night. I never stayed that late (happier working in the morning, as strange as it may be for a hacker).

As with my GUADEC experience, the Gnome folks are an incredibly nice bunch, very welcoming. An interested newcomer dropped by unannounced on Sunday and was taken under someone's wing to work on documentation tasks, mentor within arm reach.

I suspect it might have been a tad too early for me to attend a hackfest though (considering my lack of experience with the community and in general), even though I came here as one of the main targets for this documentation effort -- the Hobbyist, happy Gnome user and eager wannabe contributor. I'm still glad I attended and jätte-happy with my experience, and I hope my comments and feedback on the examples were helpful. Perhaps that is something I can keep helping with.

Leave a comment | 4 so far

Building Gnome-Shell ...at last!

Since attending GUADEC I've been meaning to build Gnome-Shell from source and give it a serious try. Unfortunately, the few times I had the time to work on it my trusty laptop couldn't handle it, in that even left alone for 3 or 4 hours it couldn't manage to finish building the first project... out of 23.

Enters last Friday whereby after 3 weeks of little to no communication I finally received my new laptop, a fantastically beautiful and shiny ThinkPad X201 *_* Oh joy. There's another post coming with getting various Linux distros to work on it, but for now:

Building Gnome-Shell on Debian (Squeeze/unstable)

Let's begin from the wonderful documentation: http://live.gnome.org/GnomeShell#building.

I'm starting from a basically brand new Linux install, so there were many dependencies to install, which thankfully Jhbuild kindly specified in one go at the beginning.

The first script creates a ~/bin folder and stores the jhbuild command in there, so this should be added to your $PATH (and in .bashrc for the future). I decided to follow the doc recommendation and created a gsbuild alias to avoid conflict with any other Gnome work I may end up doing, especially as Sugar also uses a custom version of jhbuild -- the more conflicts I can avoid, the better.

After about 2 hours, the 23 projects were checked out and built. At that very same time, any guilt I may have been feeling at acquiring a brand new laptop disappeared in a puff of spoke. In 2 hours that little guy empowered me to do and try more things I couldn't do before -- awesome!

Of course it would be a bit too simple to leave it at that, so one of the 23 projects did not built successfully, I name gjs. 

configure: error: mozilla-js >= 1.9.2 is required

I'll spare my trials with various libraries... Here's what I should have looked up first:

$ dpkg-query -S mozilla-js
libmozjs-dev: /usr/lib/pkgconfig/mozilla-js.pc

Unfortunately, aptitude show libmozjs-dev reveals that only 1.9.1 is available in unstable. Time to go experimenting with, heh, experimental.

[/etc/apt/sources.list]
# Experimental
deb http://ftp.ie.debian.org/debian experimental main

And to "override" a package already installed with one from another repo branch:

aptitude install -t experimental libmozjs-dev

This changes the error message into: "Could not figure out where Firefox JavaScript library lives", solved with:

aptitude install -t experimental xulrunner-dev

And tadam! gsbuild build gjs completes! Time for a full rebuild (...and to comment out the experimental source, in my case.)

collect2: ld returned 1 exit status

Moving on: project 22 out of 23, gnome-shell, now fails with a collect2 error. Googling around I stumble upon this incredibly helpful blog post that mentions, in passing, that you may come up against this error and how to solve it. Here's the 32-bit solution.

rm <GNOME_SHELL>/install/lib/*.la

A bit mysterious for a newbie Gnome hacker like me, but yay! Victory!

Browsing away from the Shell...
Gnome-Shell // Working on an activity

...then switching context
Gnome-Shell // Dashboard

I'm really impressed and happy with how seamlessly it all works and comfortably fits my workflow. Many distros package it, give it a shot!

Now, I better go and find a gnome-love bug related to Gnome-Shell to sink my teeth into...

Leave a comment | 9 so far

Gnome Development Documentation and Tools Hackfest

This is very spooky to me, but I've signed myself up for the Gnome development documentation and tools hackfest this December.

It's spooky because I'm not a Gnome developer (except for that one Gnome-love patch... which is much past its expiry date by now, I must move on!). I met some fantastic people at GUADEC though, and I very much look forward to meeting them again and being inspired by them again. This particular hackfest aims to improve the documentation and tools for people starting out with Gnome development, so I should be the perfect target and I hope I will be able to help and contribute meaningfully.

If it doesn't work out, well, I guess I can excuse myself and go visit Berlin. I've never been to Germany. The flights and days off are booked... All that's left is accommodation, which I'll look into after a bit of research. Ideally, before December comes!

Leave a comment

GUADEC 2010: "Building a strong post 3.0 Gnome story"

This is the talk that was hijacked by the release team to make the announcement about the delay in releasing Gnome 3.

Gnome 3: Where we are

Vincent Untz began by reminding us that there is a lot of excitement around Gnome 3 and Gnome Shell. To encourage the initial development effort around Gnome 3, the release team boldly stated 2 years ago that Gnome 2.30 would be Gnome 3. The community then reached a level of activity never seen in years. It was a very aggressive schedule, and it was meant that way: perhaps the work would not have started or not have been so intense without it.

However, Gnome sticks to a predictable 6 months schedule, and quality matters more than anything else. We want people to love Gnome 3. After waiting 8 years since Gnome 2.0, we want this release to be amazing. That is why the release team decided to move Gnome 3.0 release date to March 2011, having closely following mailing lists and using GUADEC as an opportunity to get the latest from every team.

  • Many modules, such as Gnome-shell are nearly there and could be okay for a release in September. But we want this release to be amazing, not simply okay.
  • Platform-wise, most people have stopped using the deprecated stuff, which is good.
  • Some modules will need more time to migrate, such as gsettings and the Human Interface Guidelines update which would not be ready in 2 months (Note: I attended a lightning talk about this and I like what they're planning on doing with this: a series of design patterns rather than a gigantic monolithic document that is hard to parse. They only started this the week before GUADEC though!)

The work for September

Some may worry that this is a bit late for such an announcement, and too much work to prepare Gnome 2.32 in September. Some modules will need to switch back to Gtk2.

There will also be a Gnome 3.0 beta release in September (\o/). The release team wants everyone to start using it, play with it, and report bugs. Application developers should start porting their application to Gtk3, as it will take time to get there and it would be better to start this work in September rather than next March.

The talk ended with a list of TODOs for the release team.

  • Revert to gtk2. They believe it was not that hard to move to 3, therefore it should not be hard to move back to 2. They're happy to help if people are not sure how to do this. Ideally this should be done though a new flag, to give an option to compile with gtk2 or gtk3 so that people focusing on the gtk3 effort may keep working on it.
  • They will keep pushing for Gnome 3, Gnome 2.32 is only a step. Keep porting!
  • Some modules such as Shell will be in feature freeze, to polish and finish what they've started.
  • The release team will also push the community to implement designs. Good mockups are being made and we're happy about it, but then nothing is done about them.

The questions part of the talk was interesting albeit a bit tense.

Gnome 2.32

The first question was about the 6 months release schedule, and whether it really was a valid reason to have a 2.32. What would be the content, wouldn't it only take time away from people's work on Gnome 3? Maintainers cannot be forced to do anything, and if they have better reasons to work on 3 it's okay. Perhaps other maintainers will have built new features and will want them to be used by people without having to wait 9 months. The audience still worried about the maintenance burden and cost for people already depending on Gtk3 features, but the speaker seemed confident that switching back to 2 was mostly about changing some configure options, and that no one had to do if it was too much overhead.

Still maintainers in the audience insisted that having both 2.32 and a Beta meant twice the work. Why spend time on something that matters less and less? They also disagreed that having gnome-shell and 2.32 in the background was a good idea, as it's not how the design is done nor how it's meant to work. Gnome 3 should be more than the Shell. Untz seems to believe that many features do not rely on Gtk3 or the Shell.

Maintainers contended that it wasn't the same amount of work for an application like Cheese compared to the core desktop. There is a burden to support 2 desktop environments in parallel. To which Untz answered that feature freeze was still planned for the following week, leading to a "what's the point?" question. Once again, if people don't want to do it, they don't have to.

Marketing

Concerns about the marketing message were quickly relieved by someone from the marketing team, who said that the "Beta" label generates excitement. Anyone with a feature that is stable enough should stick it in, although the control centre is another matter. We still want to ship a quality product, if it only has half the features it's okay as long as they're stable. It will generate the buzz.

There was a question about working with distros to help ship 3.0 in a way that is easier to install, to encourage people to try out the beta. There are instructions for many distros already, but it was suggested to also offer clear and prominent instructions on the Gnome front page once the beta's out.

The last question was about what the schedule would look like for the next 6 months. Although the schedule will be mostly normal, with new modules and new features, some rules will be similar to now in that new applications won't be accepted in just because they're great. Likewise, it doesn't make sense to have a freeze for everything, but for some modules it does.

Final words

Keep working on Gnome 3.0!

Leave a comment

Gnome census

I missed the talk at GUADEC, but some very cool stats on Gnome participation were released. The full report is available and there is also a blog post summarising some of the information. Looks like my experience of mostly meeting people employed to work on or with Gnome is either a coincidence or more specific to GUADEC than to Gnome itself.

Leave a comment

Random thoughts about the Netherlands and GUADEC From the airport

Lots, lots, lots of bicycles. After 5 days I still haven't totally grokked the explicit and implicit rules of where to walk to avoid being run over by a bike. But I survived!

At GUADEC, when someone asks you "what do you do?" they mean in Gnome. I met very few people that weren't paid to work on Gnome in some way or shape. I introduced myself as "a happy user" (I am!) which seemed to delight some people. I got a couple of "good bye, happy user!" as I was leaving the hotel lobby at an(other) unofficial after-party yesterday, that was quite funny. Probably from people who couldn't remember my name as I wasn't wearing my badge anymore ;)

I've learnt many things and met a ton of very cool people over the last few days, although tonight my mind is kinda blank. Information and people overload, between the conference all day long followed by parties every night, GUADEC gets kinda intense. I'm delighted and plotting whether I'll be able to go next year. Someone offered to mentor/help me out with getting involved with some Gnome-love bugs. There'll be a HackFest in Berlin in December. I'm looking forward to following up with many of the people I've befriended over the last few days, after I sleep some!

Lots of people don't seem to know Moo cards and loved my MiniCards, sometimes asking me if they could please get one while I was handing it to someone else. If you got here from the link on my card now you know where to get MiniCards of your own :)

My worries about Gnome 3 have been lessened some. I don't know if it's attending so many talks by passionate hard-working people, or something they put in the water at GUADEC that makes me come back feeling very positive and confident about Gnome 3. March 2011!

Leave a comment | 3 so far

Ready for GUADEC

I will be flying to Amsterdam tomorrow. Bag's ready, only need to select 1 or 2 books that are both interesting and light. If everything goes according to plan flight-wise I'll be able to attend the Gnome Women dinner tomorrow night, which should be good fun and a great way to start meeting Gnome people!

I'm looking forward to talks targeting new Gnome contributors, like "5 things every Gnome hacker should know". I'd also like to learn more on Telepathy -- "Gnome 3: the Telepathic Desktop" looks like it should be interesting -- and I want to attend a few other talks about Gnome 3 to reassure myself about the future of Gnome and what the roadmap looks like post 3.0 release. I can never quite make up my mind between coolness and worries, whenever I think about it.

Looking forward to it all!

Leave a comment | 3 so far

5 questions for GUADEC participants

From the GUADEC blog:

1) Who are you and what do you do?

I'm a software developer from Dublin, Ireland. Passionate about open-source and education.

2) How did you get into GNOME?

Gnome has been the default desktop for most distro I've used. After a while I decided to see if I could help out with something, and found some bugs tagged with gnome-love that I could actually solve, yay! I haven't done much since then though, besides being a happy Gnome-tee-shirt-wearing user.

3) Why are you coming to GUADEC?

I'm hoping to learn more about Gnome, meet some of the awesome people behind the project(s), and build up the confidence to become a stronger contributor myself.

4) In 1 sentence, describe what your most favorite recent GNOME project has been. (Doesn't have to be yours!)

Gnome-terminal. I use it constantly, got my first Gnome patch accepted into that project and seem to stumble upon it all the time (e.g. finding the related gnome-terminal patch on the same site I was using to learn about control sequences.)

...Going over my one sentence, Empathy/Telepathy are pretty cool too. And I'm having a jolly good time learning pyGTK as well!

5) Will this be your first time visiting the Netherlands?

Yes! I didn't leave much buffer time around the conference for tourism though.

 GUADEC participant logo

Leave a comment

Xterm control sequences, a quick and incomplete introduction

XTerm control sequences are those sequences of characters that when typed into a terminal, can have all sort of cool side-effects. Try this one:

$ echo -e '\e[33;45mHello!'

If you're not too enthused about yellow and magenta (shame!) type in:

$ echo -e '\e[0m'

Many other neat things can be done with those control sequences, so I'm going to document here how to understand the documentation, so I don't have to figure it out from scratch again in the future. This could be summarised as, "read the introduction to the documentation before jumping in the middle" but I might not remember that either given enough time :o)

It all started with a Pippy bug I was trying to figure out, summarised for the interesting bits here:

# xterm magic! see http://rtfm.etla.org/xterm/ctlseq.html
import os, tty, termios
fd = os.open('/dev/tty', os.O_RDWR|os.O_APPEND)
tty.setraw(fd, termios.TCSANOW) # set to raw mode.
os.write(fd, '\x1B[18t') # write the 'query screen size' command
# (Removed: Code to parse response)

"\x1B[18t" is the bit that matters. I'm going to use the documentation linked in the code as a reference here, though there are other versions, some more recent, floating around the Internet.

Before skipping ahead and skimming around the document, there's a couple of crucially important pieces of information that must be read.

First one is:

Ps     A single (usually optional) numeric parameter, composed of one of more digits.
Pm     A multiple numeric parameter composed of any number of single numeric parameters, separated by ; character(s). Individual values for the parameters are listed with Ps.

Second bit is (even) weirder and hidden amidst other commands:

ESC [      CSI       0x9b       Control Sequence Introducer

The CSI abbreviation is used all over the paper and without that, well, it's much more difficult to understand.

Now looking again at \x1B[18t. \x1B means hexadecimal character 1B which in ASCII is "ESCAPE."

From what we just read we know that any command needs to be escaped by starting with ESC[ (represented by \e[ in our shell examples.) That's the "CSI" and it tells the terminal that what follows is to be interpreted as a control sequence.

Moving on, the stuff of interest to us here is under the header "Functions using CSI, ordered by the final character(s)". For the Pippy example, it's 't' and thus this one:

CSI Ps ; Ps ; Ps t      Window manipulation (from dtterm, as well as extensions). Valid values for the first (and any additional parameters) are: <snip values>

Looking at the long list of possible values, we find: "CSI 18 t" returns the size of the xterm window in pixels as: "CSI 4 ; height ; width t". End of mystery! Other "suffix t" commands can be played with to change the size of your terminal, $ echo -e '\e[;80;24t' to set things right again.

There's a shell script on that same site if you want to play around more, as well as the patch that was submitted to gnome-terminal to implement more control sequences in all its glorious hyerogliphic majesty (commented though :)).

Leave a comment | 1 so far

GUADEC 2010

I'm attending GUADEC

Feeling a bit anxious about ash clouds, but looking forward to the conference!

Leave a comment

FOSDEM 2010: Gnome talks Bug triaging, Plugin framework, A new kind of IDE

There were quite a few talks about Gnome, I'm going to highlight here 3 of them.

Gnome foot

Gnome Bugsquad

The first talk was about bug triaging in Gnome. I can't believe there are only 5 active bug triagers in the project (as in, people fully focused on cleaning up the bug database). Tobias Mueller, the happy and dynamic speaker, made a good job explaining why this is such an important task, as the bug tracker is basically a window to the world. This is what people will be confronted with when they try to interact with the project, and having unanswered bugs lingering around doesn't give a very good impression.

In itself, bug triaging is a great entry point into the project because it doesn't require in-depth knowledge and it brings you closer to the community as you get to know the developers by name, so it's a good way to get involved, learn more about Gnome and help out.

The way triaging work:

  • There are bugs. People find them and complain about them in the bug tracker.
  • We need to understand and get all the necessary information for the developer to be able to fix it.
  • So the status of the bug needs to be kept accurate (more on that later)
  • And bug triagers can identify severe issues, such as bugs that come back often or many times so we can inform the adequate people.

I love that quote: "Bug triaging is about making people happy." We want our users to be happy, Gnome is about the people in the end!

Some other happy mottos:

"Be nice, be friendly, be happy."

"Answer early, answer often."

There are several ways to get in touch, through IRC, the mailing list, they're trying to hold bug days but currently lack the manpower to do so. They have a triage guide that is apparently so awesome even the KDE guys use it! :D Here's a link, I have to carve out time to read it.

After showing us some tools to find duplicate bugs and what sort of information to ask for, Toby walked us through the different statuses and how to use them, like what to do if you can't get information from the bug reporter after 6 weeks (the assumption is that this is not a problem anymore so resolve the bug), or if you're triaging a bug from more than 2 releases ago (resolve it as obsolete). Some statuses are reserved for the module maintainers. It's all summarised in a shiny diagram available on the wiki. When you start out you actually can't modify the status yourself, so you should add a comment explaining why you think the status should be updated and someone with the Power on #bugs will change it for you. Quickly enough, once you've shown you understand how this works, you can ask for the ability to change statuses yourself.

The final statement was that they need people and it's a good way to start if you want to get involved, it's not too hard for beginners and it doesn't cost too much time or requires that much knowledge. And you get to know the people and projects.

To get started:

  1. Create a Bugzilla account,
  2. Read the wiki,
  3. Ask questions on IRC,
  4. Get started. You can't do anything yet, so write it in the comments,
  5. If it all makes sense ask for access to do it yourself.

At the end, he asked who he convinced, I think he should have asked who would consider contributing to bug triaging, that's less commitment while still showing interest :) I joined the ML while he was speaking but I didn't raise my hand when he asked, because my way of doing things is to lurk for a while and then see if/how I can fit something in my schedule, rather than making promises I will break. We'll see how that one goes! I'd love to get more involved with Gnome.

Adding plugins to your Gnome apps

Steve Frécinaux talked to us about libpeas, a framework being developed to make plugin development within Gnome applications easier and more consistent across applications.

Plate of peas

Building a plug-in API is very, very hard, and having dissimilar APIs makes it harder -- that is, if you write a plugin for Nautilus, you will have to relearn from scratch to build a plugin for gedit. There's a heavily duplicated code base as well, as most projects seem to have taken the gedit plugin framework as a basis, but it's all slightly different because of bug fixes and fitting their own special needs that are not transmitted upstream.

Libpeas aims to fix all this. Plugins are good because they enable the main codebase to remain simple and clean while allowing for lots of additional functionality.

The goals are:

  • Ease of use: the framework should be minimalist with little boilerplate code
  • Extensible: different applications have different needs, not every project is like gedit
  • Lightweigth: it should only load what you use, e.g. not load python if it's not needed by any plugin

Plugins can be written in C, Python, or Javascript.

A plugin is what you install, which can consist of one or more extension. An extension is the implementation of an extension point (hooks). So plugins can register extensions with several extensions points within the application.

The speaker walked us through the different principles of plugins vs extensions, and finally showed us the steps to follow to make your applicable extensible and create hooks.

I can't find a page for the project on the Gnome wiki though, which is not cool :/

Gnome Development Tools: High-Level Debugging and the Misha Research IDE

To be honest I'm not sure this was particularly Gnome-specific, although it WAS written using Gtk tools :) Nick Papoylias introduced us to a new genre of IDE, based on the premise that debugging hasn't really evolved in the past 20 years when really, there are many ways it could be used besides stepping line-by-line through a program after encountering a problem. Debuggers can be integrated to different phases of the development life cycle, and there are many ideas that academia has put forward that are slow to be adopted, if at all (reverse debugging just made it into the latest gdb for instance).

He admitted that they didn't respect every Gnome UI guideline but as they were experimenting with a new approach to IDE and programming workflow, it made sense to experiment with a different UI as well to save space. The interface felt really busy but I'm not particularly worried about that, that's how IDE tend to be by nature.

They are adding new things to rethink the debugging workflow, that work together with the symbol debugger (gdb).

  • Syntax parser: Navigate code in terms of structures, loop iteration, functions -- not only line by line
  • Data visualisation
  • General purpose extension language: Python
  • Reverse debugging

It supports stepping through the syntactic structure while having a up-to-date data visualisation. This is a very nice way to see what is happening as we run through the code, he showed an example of variable insertion in a Binary Search Tree and it was amazing to see the tree be updated for every iteration of the loop. That'd be a much faster way to catch silly little bugs that tend to creep up as you develop (so you can catch them even before writing lengthy unit tests).

The presentation ended by showing us what the extension language could do and wow. Was that impressive. You can use Python functions to call your C code, for both simple and elaborate calls. The Python code directly calls C functions with no intervention from the developer. And through the debugging console we can visualise what's going on (e.g. the tree that is created through Python).

Additionally, if you create a main.py in your project, you can attach callbacks buttons to the IDE. This is really cool. He had it call a plotting application to display random results in a graph and check the distribution or whatever. It was really impressive.

So Python can be used to make inter-language calls, import external libraries, add functionality to the IDE, and call C programs directly. Check out the project website.

Leave a comment