The interim workaround is to use the Profile Manager to create a temporary new profile. You’ll find the Profile Manager under the Start menu on Windows, or by executing “songbird -p” on Mac.

Sorry for the headaches. We’re going to get this fixed as quickly as we can. Full details of the cause and fix are available in bug 21356.

Just want to download it?  http://getsongbird.com is for you.  Waiting for your automatic updates?  We’ll post ‘em later today (Tuesday in the US). See the 12/23 update below.

(Kanyebird is gonna let you finish, but he thinks the Gonzo feather was the best feather of all time.)

Update (12/23/09): The Gonzo feather really, really did not want to go away; we fixed yet another Gonzo-related bug (number 19365, if you really want to know) and released Songbird 1.4.3.  Automatic updates will come out early next week.

Your Bird will let you know within 24 hours about the available update to version 1.1.2.  If you just can’t wait, go to the Help menu and choose Check For Updates for instant Birdification.

On the other hand, it’s also hard to express just how sorry we are that such a thing happened. I definitely hope that the way in which we engaged the community in the past few days sent a clear message that we were nothing short of completely dedicated to solving this issue as rapidly as possible while ensuring that this problem is gone for good.

At this time, the updated iPod Add-On should already be available on the Add-On site and disabled version of the Add-On should also auto-update to the version with the fix.

The problem itself stemmed from a code change that was made to the methods used to collate (i.e. order) properties that are numbers. It turns out that the collator was a little too smart for its own good. This, combined with the way the persistent IDs are generated in iTunes and stored on the iPod, led the Add-On to believe it was operating on Track A when, really, it was operating on Track B. With this confusion, it was possible for the iPod Add-On to erase certain tracks because it was essentially attempting to de-duplicate the contents of the iPod when mounting and synchronizing. It may have also simply removed references to these tracks from the iPod. This would leave the content on the iPod but the content would no longer be associated with the iPod Library, which would make it seem like it disappeared from the iPod.

We’d also like to point out a few potential misconceptions about this issue.

• This issue did not affect the iTunes Library.
• There were no ill effects for iPods that were managed using Songbird. Only songs synced through iTunes are affected.
• This issue is akin to losing or having ones iPod break. While it is unfortunate, it should normally be possible to repopulate your iPod using the original source (eg. Your music library on your laptop).
• Users that did not upgrade from 1.0 to 1.1 and ran into this problem will see their collection restored after installing or updating to the new iPod Add-On.

Since then, we’ve crafted test cases to ensure that this problem never happens again.

We hope you’ll come back to us!

It’s been brought to our attention that the iPod Add-On has some really nasty issues which may cause it to delete content from an iPod without asking the user first. Because of this we are pulling this add-on from the list of recommended add-ons.

If you have this add-on currently installed we highly suggest you disable or uninstall it for the time being.

We apologize for any problems you’ve encountered because of this issue and I assure you we’re looking into this with utmost attention. We will post more information about this issue in our bug tracking tool here.

We’ve hit a snag in the Hendrix release — our 1.1b1 and 1.1b2 builds are causing crashes for some of you and we don’t know why.  We’re launching an all-talons-out bird assault on this thing to get it fixed before the final release.

Here’s how it’s going to go down and what we need from you:

If you’re seeing the crash, you’re probably on Windows Vista and it’s probably crashing soon after launching Songbird. We need your information!  Submit the crash report and please oh please add a comment about what was going on when it crashed. (If this doesn’t sound like your crash, we’re not ignoring you; we fixed two other new crashers on Friday and they should be gone now.  See bugs 15485 and 15502.)

Everyone (crashers and non-crashers alike), download the latest nightly off trunk and give it a spin.  We upgraded Songbird’s database in our trunk builds in hopes of fixing the crash.  If the community gives us the thumbs-up on the DB upgrade, we will merge those changes out to the Songbird1.1 branch for the Hendrix release.

Developers, if you feel like rolling up your sleeves and digging around in the bird innards for this one, you can find all pertinent crash reports here.  Development activity is being tracked in bug 15501.

Use this comments thread to communicate with us and with each other!  Did the trunk build fix the crash? Did it cause your machine to pop open and give birth to a fleet of unicorns? We want to know, so we’ll be checking in frequently over the weekend.

Happy weekend, everyone!  I’ll be announcing the winners of the Watch Folders community bug hunt next week!

This is the first post of a 3 part series presenting our experience moving Songbird development to an Agile process.

Drowning in the waterfall

Up until version 0.3, Songbird development had been following a fairly traditional waterfall model. Realizing the ambitious vision of building both a platform and a desktop media player has presented many challenges. A lot of plumbing infrastructure is needed before any features can be created. Faced with that challenge, the engineering team did what engineers do best, they designed a very comprehensive system, planned for it very carefully and started cranking code.

During the planning phase, the team estimated the work to the best of their abilities and a Gantt chart was created to reflect identified dependencies and track progress. Unfortunately, this approach led to lengthy release cycles (10-12 months) with lots of room for scope creep. When the release finally got completed, lots of good work was accomplished (over 1200 issues where addressed in 0.3 alone) but the lack of visibility was problematic and the slow pace of releases was too demoralizing.

We recognized that the schedule was build on assumption that we knew everything upfront. There was a sentiment that the whole Gantt thing was a little removed from the actual work and that overall “things were going ok, because we were kind of tracking it” was not an acceptable way to run our project. We had to accept that our planning and scheduling practices were broken.

Besides the effect on morale, a long development cycle presented the following problems:

• Nothing can be released until everything is completed and put back together.
• Difficulty to bring visibility on real progress (i.e. when can we ship?).
• Last stable release branch and trunk drift apart significantly. Especially problematic to support commercial partners.

We also felt that our task estimates were not granular enough and the built-in slack was not taking into account other work. Unfrequent build also meant a lack of visibility on product quality.

That kind of development approach also fosters poor engineering and product development habits, such as:

• Reduced sense of urgency to release code. Discipline drops, unit test failures increase, bugs pile up. “We have enough time to fix this” mentality develops.
• Ultimate release becomes a huge effort as the routine around releasing code does not form.
• No continuity in QA, bugs accumulate in a backlog.
• No context for new work, so there is a tendency to add more things to existing release, also known as feature creep.

Becoming more Agile

We decided to adopt a new approach to development that would address those issues. These are the objectives we tried to fulfill:

1. Satisfy our customers (end-users, developers, partners) through early and continuous delivery of valuable and innovative software.
2. Provide ability to react quickly to business changes.
3. Reduce product defects and security exposures.
4. Ensure team and product sustainability. Focus on ease of product maintenance, allow the team to maintain a constant pace indefinitely and be resilient to turn over.
5. Provide good visibility into progress and release date.

We felt that we had a good foundation of existing practices we could build upon. Build automation, continuous integration, unit testing, peer review process for code commits, automated api documentation and the use of Bugzilla were already well established within the team. We needed to augment those with a few others borrowed from Agile methodologies.

We added the following set of guiding principles:

• Reduce release length and maintain a releasable product at all time.
• Working software is delivered frequently (weeks rather than months) and is the principal measure of progress.
• Provide rapid feedback loop to QA and Product Manager.
• Develop a system for better estimation and tracking.

Reduce release length

At a high level, we’ve committed to release a major update of Songbird every other month. We opted for calendar driven releases with a short development cycle of 4 to 6 weeks of coding maximum. We adopted a naming scheme for each release train drawn from a music artists theme. Alphabetically sequencing those release trains makes it easy to see the order of releases (Eno release comes after Dokken for instance).

Measure progress against working code

Within a release cycle, we introduced the notion of iterations of 1 week length that we used for planning and measuring progress against. This gave us the context to improve our estimation and tracking system.

Develop a system for better estimation and tracking

Estimating how long software development takes is one of the most difficult thing to do.

We created a High Level Roadmap that captures the scope and sequencing of each release.

We came up with a set of lightweight artifacts that would help us represent and track what needs to be done.

• Feature – High level product feature (bullet point on product box, if we had one)
• Story – Smallest increment of implementable end-user value
• Task – Engineering implementation detail, chore, etc.
• Bug – Defect in existing functionality

In support of that, we also created on our wiki design docs that represent wireframe and accompanying notes to explain each feature. You can see an example of such document for the view menus clean up in Eno release.

For each story, task and bug, we’ve introduced a costing system based on points. The scale starts as at 1 point, for something easy that an engineer can do in a day. Two points means it will take some time to think about it and write the code. 3 pointers are reserved for the most difficult issues, requiring research or lots of code. The idea is to come up with a normalized unit of work across the team that we can measure ourselves against. Moving from a time based estimate to point base is not easy. For one, the scale is not linear (e.g. 3 pointers don’t take 3 times as long as 1 pointers). However, the basis for this is to simplify and reduce cost estimate process to a good enough level that we can measure and forecast. While it may be a blunt instrument, there is diminish return in spending more time refining and tracking estimate at a much more precise level.

The key benefit from developing a consistent costing practice is the ability to measure progress and use it to forecast future work. Entering Velocity. By computing how many points get completed by the team over an iteration, we were able to normalize the output in the form of a velocity metric. This gives us a sense of how much stuff we can accomplish in a typical cycle.

To track our progress, we setup 2 iteration meeting, one to review and plan the iteration and the other to steer the iteration at mid-point.

All the artifacts and measurements are tied together on a Release Plan published on our internal wiki.

Feedback loops

Another important factor is the acceptance and validation of work. In order for points to be counted in an iteration, there needs to be an agreement on when things are “done”. Nightly builds are being used for verification every day. On the bug front, QA validates engineering fixes and mark them validated. Similarly, Product Manager accept stories as completed when they are satisfied with the implementation of a feature.

Putting it to practice

With all these new practices in place, we were eager to tackle our first Agile release known as “Cher”. Our next post will take a look at the roller coaster of real life release cycle.

The down side is that your current Songbird library will not be compatible with future versions of Songbird, starting with tonight’s nightly. The fix is easy — simply delete your profile and re-import your library. There is another option for those who would prefer to keep their libraries, but it takes some skills. It involves using the sqlite command line tool and running a migration script on each of your Songbird library database files. If you’re gung-ho to give this a try, Peter documented the steps on our wiki.

Here’s a screenshot of a quick demo – it uses HTML but the same can be done in XUL. See how the corners of the background image don’t show through the edges of the porthole like before?

Download example source code.