Not only has he picked up the daily maintenance, but he has also converted the recipes to use git. He has also packaged gnome-shell, very cool stuff.

What: Jaunty Jackalope Release Party

Where: Flying Saucer
328 West Morgan Street@Harrington
Raleigh, NC 27601
919-821-PINT (7468)

When: Thursday, April 23, 2009
Time: 6-9pm (or until we just can’t party anymore)

Please RSVP to akgraner [at] gmail [dot] com so we can let the Saucer know if they need rope off more space or not.

And don’t forget… bring your friends!

If you have a little time to help out, your hug can help improve Jaunty.  Here are some stats going into this week’s hug day:

* 49 New bugs need a hug.
* 103 Incomplete bugs need a status check.
* 81 Confirmed bugs need a review.
* 16 Bugs with patches that need to be reviewed.

Remember, every hug counts!

This has changed now, not because pidgin has gotten better at IRC, but because of the message indicator applet. The message indicator grabs notifications from notify-osd that are based on human to human interaction, and stores them in a little applet in the panel that indicates what might need your attention. Currently only evolution and pidgin support it, but hopefully many more soon (gwibber, please gwibber!). Now when people highlight me in a chat, IM or private message me I see the nice little indicator with a star showing it needs attention.

I am very happy to say I can use Pidgin for my daily IRC use… Yay for a single client finally!

I am sure nobody will be surprised to hear that the indicator-applet is included in Foresight as well, just add it to your panel.

I have spent a wonderful 3 years working at rPath, which ended in January. Having made some great friends at rPath, of which I am thankful, and having had some great experiences too. I will miss my rPath family, but will surely stay in touch. Tomorrow I start the next leg of my journey, with Canonical. I will be a Desktop Integration Engineer, working on the desktop team to integrate the fine work being done by the Desktop Experience team into Ubuntu. This is a very exciting opportunity for me, I have really been doing this for the past 4 years working on Foresight Linux. Taking cool stuff people have been working on and integrating it into a distro for broader consumption.

Over the years working on Foresight I have formed some great relationships with our Ubuntu brothers which has lead me to join their team. Joining the Ubuntu Desktop team will change my day job yes, but it won’t change my role or participation in the other work I do outside of that day job. I will still be maintaining Foresight Linux, the GNOME Developers Kit, PackageKit, and whatever other upstream projects I can cause trouble with.

I am trying to resist the urge to make predictions for 2009.  Let’s just say we’ll kick ass in 2009, and leave it at that.

The road to Foresight 2.5 includes you!  Historically we have not provided the level of transparency needed to enable more people to participate in Foresight’s core development.  I am very excited about the packagers that have joined in to help, but I suspect them and others have trouble figuring out what is needed.  They have done a great job of packaging new applications and helping to grow our repositories, and we appreciate that.  However, Antonio (doniphon) and I do most of the distro work, and that is our fault.  We tend to have a good understanding of what needs to be done, and we just do it.  This leaves others either not knowing what they can help with, or feeling like they might step on our toes.

So what do we need to do?  Log all issues we are working on, or plan to work on in FITS (Foresight Issue Tracking System) and continually log our progress on tasks.  Not only does this provides us a high level view of where we are, and what needs to be done, but it also provides a wider audience a list of tasks they can step up and accomplish.

We are going with short 1-2 month sprints instead of long 6 month development cycles.  During these sprints we will continually push features into mainline, continually delivering innovation.

• Sprint Kick off/planning cycle
• A larger meeting to discuss major objectives for the sprint
• Break it down into the top level objectives and create issues for them in FITS
• Hopefully find a driver for each top level objective
• Organize smaller planning discussions, ideally done via FITS
• Break down the top level objective into smaller issues in FITS
• Document requirements of success for each objective
• Assign a mentor
• Assign a due date.
• Create Use Cases for testing

• Tracking and status reporting
• Each assignee will continue to update the progress of tasks via FITS
• Regular blogging of your progress on your piece of the road map, lets make this fun!
• Weekly status reports

• Mentoring
• We should have some more experienced people available to act as mentors.
• Sounding board for ideas
• Contribute to and approve designs
• Help define measurement for success
• Review/approve completed tasks before pushing to mainline

The key for success is maximum transparency, this means using FITS and the foresight-devel mailing list as much as possible. If you would like to participate, please send an email to our development mailing list. You can find information on the lists here.

For a list of objectives we are already thinking of for Foresight 2.5, check out this list