jorge's stompbox

It's ISO testing time ....

Friends, Romans, countrymen! Lend me your vm's, desktops, and hardware that is laying around. I have come to test the Intrepid ISO, not to praise it (yet)! The bugs that releases do lives after them, the good is oft interred with their bones. The noble sabdfl has told you that Intrepid is ambitious ....

Ok, enough bad poetry.  Now is the time to help test the Intrepid ISOs - The also noble Henrik has put a call to test the beta ISOs. Instructions included in the post. People with 64 bit and DVDs are really needed.

See you on #ubuntu-testing!

One where I am totally awesome ...

Craig Maloney (snap-l) has never seen Metallica's Binge and Purge.

DVD box set status = lent to friend.

One where I am an absolute failure ....

I got bit by this bug about a month ago. It wasn't a big deal for me, just synergy not working, so I took the easy way out and just subscribed to it, grabbed the source from Debian, fixed it and forgot about it.

At the time I was too busy to care to get it fixed in Ubuntu ... even though by running Intrepid I should have helped fix it for everyone by default. Thanks to Joseph Fannin for reporting the bug, thanks to Wouter Stomp for figuring it out the differences between Debian/Ubuntu, and thanks for Kees Cook for fixing it.

I am blogging this because I could have helped fixed this bug a month ago but at the time I just wanted to get it fixed so I could move on to something else.

Stupid, and absolutely unacceptable behavior on my part.

I am currently reviewing bugs in launchpad which I've touched and not done due diligence.

Introducing the Upstream Report

After months of tweaking and gathering feedback, I am happy to announce the beta of the Ubuntu Upstream Report. The upstream report is a real-time page that lists the Top 100 projects in Ubuntu sorted by open bugs, and also shows us how many of those bugs are "upstreamable", and how many of those have an actual link to an upstream bug tracker.

The intent of this page is to be used as a tool by Ubuntu Developers to track how well their linkages to upstream bug trackers are, and provide a list of bugs that are possible "targets" for them to push upstream.

When you first see it it's quite overwhelming, so let's look at how we got to this report.

Understanding the Problem

When I talk to bugmasters for large projects usually a generic term I hear is "So and so is doing a good job with package foo" or "I've not gotten a single bug report for my package bar, I had to go hunt someone down". While generally these comments are useful, nothing beats having numbers. It would be nice to be able to talk to a maintainer and say "We've been able to forward to you 90% of the bugs that we've Triaged." or in the worst case, be able to pinpoint which packages have poor linkages so that we can put QA resources on that package to get better linkages.

It's also a problem for developers. There's no "30,000 foot view" of how well your bugs are being linked upstream, and you don't really have a "hit list" of possible bugs to upstream, you really just handle your specific pile and do the best you can.

We wanted to provide a tool that not only shows upstreams how well we're linking and forwarding bugs, but a day-to-day tool for maintainers to see where there are targets of opportunity to forward to upstream. And lastly, for triagers we wanted to provide real-time working "bug lists" that you can work through if you want to help be the bridge that connects the downstream Ubuntu Package to the upstream project.

Reading the Report

Let's pick an example, I will use rhythmbox since it's a package we ship by default and most people are familiar with it:

The first column tells you the source package name, pretty simple. The next column is a check to see if there is a corresponding project in Launchpad. By the time a project makes it to this list that should be filled out. The little bzr icon is there if there is a code import of the project in bzr. The next column is the bug tracker field. It is absolutely critical that this field is filled and correct, you can't forward bugs to an upstream if you have no idea where they're supposed to go. :)

The next field, which you will notice is very red is the "upstream contact" field. Ideally this is a person who is willing to be that bridge between us and the upstream project. For a bunch of these there are teams that handle this, in the case of Rhythmbox it is handled by the desktop team. I'm going to leave these alone for now and address them in a later blog post, I want to get to the meat. :)

The Triage Column

The first number in rhythmbox is 306. This means that right now there are 306 open bugs against rhythmbox in the Ubuntu Bug Tracker. Of those, 191 are in the "Triaged State", for a difference of 115, 62.42%. Note how you can click on the number to get the list of bugs!

The Upstream Column

Ok, here's the meat of the report. Of the 306 open bugs 227 have an open upstream task. What is an upstream task? It looks like this:

Sometimes, we can't find an upstream bug report for the bug, so people open a blank upstream task, this is PERFECTLY OK! Sometimes all that is needed is a developer to acknowledge that it is indeed an upstream bug; for example Jonathan Thomas did this for bug 132375. (I'll come back to this bug in a bit)

So ideally when someone determines this someone involved in the bug report should do the due diligance of filing the bug upstream. Sometimes this doesn't happen, people are busy with real life, or they might just be triaging a few bugs and can make the determination that it's upstream but not have the time to go through the steps of filing it upstream. That is perfectly OK because when someone marks something upstream and leaves it blank, it shows up in the next column:

The Watch Column - aka. Low Hanging Fruit

Any bug that has an open upstream task ... but is NOT linked to an upstream bug tracker shows up in this column. These are bugs that we have determined should be upstreamable but haven't been linked yet. As you can see, out of 227 upstreamable bugs Rhythmbox has 227 bug watches to the GNOME Bugzilla. That is a pretty impressive number. Nautilus, 311 linked out 313 marked upstreamable. Bug 132375 would show up on this list under kdebase.

Workflow

So let's look at an example on how to improve a project's linkages. kdebase has 76 out of 83 possible bugs linked upstream; 91.57% which is quite excellent. The very last column, the delta, shows us those 9 bugs that haven't quite made it, so let's take a look. Clicking on the 9 takes us to bug 132375.

This my friends, is an awesome candidate to be upstreamed. The report is an easy way to find upstreamable bugs! What should happen now is someone files this bug in the upstream KDE bugzilla, and (don't forget) to link the launchpad bug to that new report. Instructions for linking are found here. As soon as the launchpad watch kicks off, this bug moves out of the delta column and into the watched column.

You'll notice that both kdebase and rhythmbox are marked "green". Any project with a 90% or above link rate shows up as green. This number is pretty obvious and non-negotiable - if a bug is determined to be upstream and is NOT forwarded upstream then it is in a FAIL state. ;) The 10% breathing room is there for bugs that are determined to be upstream but you're waiting on more information or data or something before you send it up.

What happens next

Launchpad watches are awesome for one simple reason: When a bug is fixed upstream we know about it. When we know about it we can target them with resources. Launchpad watches feed the Harvest machine - which is useful because developers can find these low hanging fruit and fix them.

Why you should care

We have a ton of users, as a result of this, we get a ton of bugs. Many of these users are new to linux, this leads to many bug reports that are incomplete or just not good enough to send upstream. What we DON'T want is people blindingly forwarding bad bugs upstream, we want our most detailed, complete bugs sent up. This report gives us targets that we should look at as candidates for sending bugs upstream. The kdebase example I showed is "only" a wishlist bug, but still, upstream should know about it. Bugs that show up in the "Triaged" state have been set that way by the Ubuntu Bugcontrol team, those should be scrutinized as candidates and sent upstream.

The real simple question to "why?" is because it's the right thing to do. We ship rhythmbox to millions of users, it's our duty to ensure that every one of those 227 bugs is sent upstream. If our users report bugs and they don't get to the authors, then chances are they won't receive a fix, and that isn't very user-oriented. :D

Tips on How to Proceed

• Ubuntu Developers - If the Upstream column has a low percentage, then you're probably not opening upstream tasks to your bugs. virt-manager has 0 out of 75 bugs marked as possibly upstream. Either we introduced 75 bugs to virt-manager or we're not marking the upstreamable bugs with an upstream task.
• Triagers - Use the last column to look for bugs where a developer has opened an upstream task - search the upstream bugzilla to see if it has been reported, if it has, link it! If it hasn't been reported, you can follow these instructions to create a new bug in the upstream bugzilla to link it. If you get confused on how exactly to do this ask someone for help.
• Upstream Developers - You can use the last column and use it as a list to check out bugs that we haven't sent to you yet. If you have an Ubuntu user that pops into your IRC channel asking how they can help you can point them to this list.
• Users - You can help "become that bridge" between Ubuntu and upstream by following these bugs and forwarding upstream as appropriate. If you find the same bug in the upstream bug tracker then make that link!

Caveats

This report is still a beta but we consider it in good enough shape to get it out there and get people working with it so we can fix it and make it more useful for everyone. Currently there are the following caveats:

• Currently there are ubuntu-specific projects on there that don't really have an upstream or where Ubuntu is the upstream, like software-properties, these will be removed.
• Sorting is kind of wonky, you might need to refresh if you're sorting columns a bunch of times (Graham is working on this as we speak!)
• Right now we're only showing the top100 projects according to open bugs - we should have a method of querying any package in the archive.
• Some of the target bugs in the last column might be old or inappropriate - remember this column shows open upstream tasks with no links, clean these out and marking upstreamable bugs with an open task and this list will become useful to you!
• The upstream report targets are not an excuse to NOT work with an existing team! Don't just go in there and start forwarding bugs, work with the existing teams. Sometimes Ubuntu developers do NOT forward a bug until they have more information - if you just go and forward something when it is not ready you're just creating more work for everyone, so if you want to work on something, let someone know! The desktop team doesn't bite, I promise!

... and last but not least:

The Upstream Report is Chuck Norris

a) He has no emotion - he just reports numbers. Use it as a tool to gauge where you are, and where you need to improve.

b) Let me reiterate - having a "green" doesn't get you off the hook! It just shows how well your linkages are doing - low upstreamable bugs stick out like a sore thumb - if a project you work on has 100 open bugs, but only something like 3 are marked as upstreamable and you think you're doing awesome because you've linked those 3 and you get "100%" in the linkages then you're doing it wrong!

c) If your numbers are bad, don't panic! - the report was designed to show you were things are bad, and give you a list of targets so you can triage/forward appropriately. There will be instances where a bug might show up that is inappropriate to send upstream. That's fine, don't forward it. Use the list of targets as a short list of possibles to look for candidates.

d) If your numbers are awesome then congratulations, you're doing the right thing.

The Bottom Line

At the bottom under totals we find that when we do find a bug we do a good job (92%) of linking it upstream. The bad news is that only 17% of our current bugs are marked as upstreamable. I look forward to seeing how we grow this number and increase our linkages!

The Future

This is just a rough start - if you follow a bug workflow in your head to it's logical conclusion you can think up of many ways we can expand this report - Do we have nice method for undoing a bad upstream link? Apport crashes are pretty unique, is there a way we can automate that to get that to upstreams in a nicer way? What can we do to improve bugs.launchpad.net to make linking easier and less error prone? How can Launchpad talk to upstream bug trackers to make this even more useful?

These are questions that we'll be addressing as time goes on, in the meantime I hope that this initial cut is useful for everyone. As always, feel free to contact me, jorge at ubuntu.com with feedback - you can report bugs here: https://bugs.launchpad.net/malone, please tag them with "ubuntu-upstream-relations". I've added this blog post example to the Ubuntu wiki - updates and changes will happen there.

Please test usb-creator.

Aside from being a ninja, Evan Dandrea also works on Ubuntu installer stuff. You know all those ISOs you have laying around from ISO testing? You can use those to test the usb-creator. Evan has posted his request to the list, but it's not in the archives yet, so I posted it to forum thread.

Help test Ubuntu ISOs!

Want to help Ubuntu but don't know where to begin? Testing ISOs is a great way to get started. I've posted this thread on the forums, which points to the announcements and resources you'll need to get started.

Dear internet ....

It is entirely possible to constructively criticize actions of an upstream project without resorting to name calling, ALL CAPS, whining, threats, personal attacks, and other juvenile behavior.

I'm pretty sure I've read this before somewhere...

Just throwing that out there ....

RIP Richard Wright

Richard Wright, the keyboardist for Pink Floyd, has passed away.

Lazyweb bass/guitar players, help.

So over the past year I've been getting back into playing the bass guitar. I used to play the electric bass in Jazz Band in high school, along with the double bass in Orchestra. (The double bass is this honking huge monster.)

I've been fortunate in working in an open source job, which naturally seems to mean that I get to work with a bunch of musicians. I don't know what it is about hackers and music that makes the two "just fit", but I digress....

So anyway, at the end of the last UDS we did this thing called Ubuntu All Stars, where basically we jam for people who have been working all week. The first half was a live band, and it was capped off with Daniel and Luis spinning wax way into the night.

The first "All Stars" was a little rock jam we did during a Canonical All Hands. This was the first time I got to play with Barry Warsaw, Tony Espy, Graham Binns, Bill Filler, Chris Armstrong, Jono Bacon, and Jamshed Kakar (among others). In case you didn't know, Barry Warsaw is not only a well respected Python and mailman hacker, he's also a prolific bass player. Since I drove to Boston for that allhands, I had my 2 basses and gear onhand, which Barry quickly set up for that jam. So, that jam happened ... let's look at some pictures ...

These are pics of Barry on my Ibanez RD500 .... take note of how he rests his thumb on the J pickup.

As it turns out, Graham Binns also(!) has an RD500 ... same thing as Barry, thumb on the J.

Now, I happen to play different ... check these out ....

Ok, so I tend to play really close to the back end of the bass, really close to the bridge. I don't know why I do this, since I mostly learned on the double bass (which doesn't have pickups, just one hunk of wood that suspends the strings above the body) I have no clue where my fingers are supposed to be. So I just put them where they felt comfortable. Obviously I can tell that where you play affects your sound.... this is where I get totally lost....

Help me Bass Players

I've noticed that the closer I play to the neck the deeper the sound is, the closer I play to the bridge, the twangier it is ... this is pretty basic stuff, this is obvious when you first pick up the bass. I've known this for years. My main question is ... how do different pickups affect this sound? In Istanbul at GUADEC I played like this (on purpose):

I couldn't tell a difference, I noticed that Edward Hervey played similarly. Jono plays with a pick, and I've noticed him play right in the middle; nothing against Jono but I've seen many "guitarists who play bass" do this kind of thing. I am unsure if this is on purpose or how just people tend to be.

What brought this whole thing on?

• I've picked up a new set of Rush DVDs, and I noticed that Geddy's Wal has dual humbuckers, and he routinely switches from the neck humbucker to the bridge humbucker during many songs. I was wondering why he would do this, because it sounds the same to me!
• In the 1984 DVD Geddy plays a Steinberger (ugh), and he mostly plays it right inbetween both pickups, I don't notice him shifting around at all.
• On the Rush 30th Anniversary DVD (R30), Geddy plays a Fender signature bass (made just for him) with just one J pickup(!). I don't understand how one goes from a Wal with dual active humbuckers to one J pickup ... explain? I also note that Geddy's sound in the 2000's sounds way less twangy and in your face vs. the older material. Also, he alternates between different sides of the pickup, so he's still kind of switching up, just only on one pickup.
• If you want a real life example, note the playing of his chords on R30 vs. Show of Hands on "Force Ten" - he's playing it totally different, and it sounds totally different.
• I've noticed that Jason Newsted and most of the metal bassists play with a pick nearly right on the bridge, vs. Robert Trujillo with his fingers closer to the neck.
• Roger Waters plays closer to the bridge with a pick, while Pink Floyd seems to pick studio musicians that play with their fingers, closer to the neck.
• To make things more complicated ... it's not just where I play, but how I adjust my volume for each pickup .... argh!
• My guitarist friend Ken Simon explains that if you think of a guitar/bass string as one big wave, that it's obvious that where you "break" the wave that the tone is different. That makes sense to me... I have no idea how this relates to pickups though...

So what are you guys doing for sound? I have this big feeling that I'm over analyzing this need to concentrate on just practicing. Do you guys just pick where to play? What do you guys do about different kinds of pickups? What are you guys doing out there for "best practices"? God I hate sucking so badly, if someone could explain why I suck so bad I would appreciate that as well. :(

EDIT: I know it sounds like I'm nitpicking, but I'd like to know why people play the way they play, it's interesting to me

Ohio Linuxfest almost here...

Ohio Linuxfest is almost here. October 10-11 in Columbus, Ohio. Here's the schedule.

The list of speakers is up, and it's impressive. Joe "Zonker" Brockmeier from openSUSE and our Ubuntu Community Manager, Jono Bacon are doing the keynotes. (Is it me or are these two becoming inseperable speakers at US conventions lately?)

Talks I am looking forward to attending:

• Roland Hess - Blender - this is going to be cool, if you've not seen Big Buck Bunny go watch it now.
• Mackenzie Morgan - wifi - It's always awesome to see fellow Ubuntu community members take the stage.
• Daniel Chen - Unbreaking Audio for the Unassuming Linux User - I have a feeling this one will be popular. :) Dan is one of our rockstars draining the swamp that is Linux audio.
• Bdale Garbee - Peace, Love, and Rockets - Bdale is a former Debian Project Leader, I believe he's the one who coined the term of Debian as "the universal OS" - I got to meet Bdale at Debconf8 this year and he's just alot of fun to hang out with, he's a really good mentor to listen to about all sorts of things, from tech stuff to general community building. I look forward to Elizabeth Garbee's talk as well, "Through the Looking Glass: Open Source From a Teenage Perspective", that sounds interesting.
• John 'maddog' Hall - Sustainable Computing - All of maddog's talks are always good, nuff said.
• Ilan Rabinovitch - Hacking the legislature with Geek-PAC - Ilan is one of the organizers of SCALE, and always an awesome guy to hang out with when I hit the left coast.

There are of course more talks as well, these are just the ones I'm looking forward to. I am disappointed that Richard Bowen won't be speaking on Apache this year, but them's the breaks. I am also somewhat relieved that my joint talk with Ken VanDine on GNOME was bumped - I've had the (tremendous) opportunity of speaking at OLF for like 4 years in a row, so I am happy now that the show has grown to a level where us crazy locals don't have to fill in, and we can instead bring in the heavyweights like Zonker, maddog, jono, and bdale.

Don't think that the Ubuntu machine is taking a break because I'm not doing a talk either. In addition to maco and daniel, we'll be bringing in the Michigan LoCo: greg-g, wolfger, rick_h, n0p, snapl, and the others. The Kubuntu maniacs from Chicago will be joining us as well (nixternal and crew), and let's not forget our gracious hosts from Ohio, vorian and the other OSU crazies. Simon Ruiz is coming from Indiana and I expect Andrew Conkling to bring in the guys from Pennsylvania again.

Expect serious invasion of BOF rooms and coordinated "strikes of awesome" to be doled out with impunity. Unfortunately the wifi situation at OLF is always dodgy so there's no way we can do a full blown packaging or bug jam, but one thing I've learned is that when people of this caliber are shoved into a convention center, awesome stuff just tends to happen. We can almost surely bust out the bug and packaging jam notes from Penguicon and drive some discussion there, I would also like Andrew to share with us his experience working with Banshee bugs.

Coming to Ohio? Post below and let's see what we can come up with.

EDIT: Skippy reminds everyone to REGISTER as soon as possible!