Brainstorm

Undelayed bugfix releases for Nokia (open source) packages.

Posted on 2009-12-03 11:49 UTC by Ville Reijonen. Status: Under consideration, Categories: User Experience, Devices, Marketing.

Nokia has few applications under open source licence such as Modest and application manager. Now, as case with Modest by the time of creation of this text, there are a few critical bugs/issues which affect a large amount of people. The fix is available in the source code but updated version of the package is not released until Nokia releases a full update. The lead time could be couple of months and the release times are never annouced beforehand.

Due to the delay, many active people notice the same bugs and go to bugzilla. Sometimes they do notice the existing report and write their own - this causes many duplicated bug reports to appear. Sometimes the bug is already fixed internally. A lot of effort is wasted thereby with the delayed bugfix release and redundant work. Delays and redundant work creates frustration. Additionally, the software may be unusable for many months when it could be fixed now. Talented individual frustrated enough might roll up their own update, but if 10 people do it for themselves this is clearly again a lot more wasted effort and time.

Delay is therefore bad for user experience and can make the whole device look bad in the eye of frustrated people. This is definitely a lost position for marketing efforts when fast bugfix releases would be a positive element for consumer mind.

Discussion on Talk: http://talk.maemo.org/showthread.php?t=35793

Solutions for this brainstorm

Solution #1: Fork the OSS source

Posted on 2009-12-03 11:49 UTC by Ville Reijonen.

As Nokia does not release updated versions in time, the community should do it by releasing parallel package with bugfixes. For example, Modest by Nokia would be in standard firmware release but the fixed version would be in extras with label reModest - re for released.. Alternatively, a separate repository could be created (cheers, Marcin :). This way there would not be any delay by the Nokia approval and release machine.

Solution #2: Independent applications

Posted on 2009-12-03 11:58 UTC by Ville Reijonen.

Instead of monolithic releases, all or nothing, have individual independent updates to applications when they are ready to release. The OSS applications should be independent even if Nokia supported. They should follow their own bugfix needs and release schedules. At least follow "release early, release often" with the OSS part of Maemo even if the closed core can not do that.

Solution #3: Separate bugfixes from development

Posted on 2009-12-03 12:18 UTC by Ville Reijonen.

Most of the linux distributions release frequent bugfix package updates. The development and bugfixing should be possible in separate tracks, so bugfixes are not tied with new features. Thus, new features do not need to be released before they are ready.

Solution #4: Provide your own line of SSU

Posted on 2009-12-05 23:24 UTC by Carsten Munk.

If you want your own updates, set up your own SSU, it is entirely possible and is what is being done in Community SSU for Diablo. Make a repository with daily builds of openly developed software (maemo.gitorious.org, etc). Chances are you will run into a dead end once next SSU comes out and you'll have to rebase on a fresh image. That's the cost of bleeding edge.

Alternative is providing an alternate SSU that only upgrades certain fixes instead of daily builds which may work better with SSUs.

Solution #5: Use Debian's method

Posted on 2010-01-18 00:31 UTC by Stefanos Harhalakis.

A well-known approach that addresses this is the Debian's method: There should be three types of repositories:

Stable: Which will hold the releases. After each new release, the stable repository will be updated.
Testing: This will be an on-going repository where new software will be deployed.
Unstable: This will hold new packages. After some period of time and as long as there is no other problem, the packages will move to Testing.

Debian's release policy can be used as guidelines.
Benefits:

End users (mostly developers) that want the newer software will be able to either get it from testing or even use testing as their base repository.
Users that use N900 (or any other device) as a phone (non-developers) will stay with the stable release. New images will be just snapshots of the (new) stable repository
Since the stable repository is also just a repository, it will be possible to deploy crucial updates without releasing a new flasher image with a lot of new software.
It is a well known method that works for Debian and there is a really experienced community behind that.
The software will be already tested when it reaches the stable repository.

Register