[Under consideration] Undelayed bugfix releases for Nokia (OSS) packages.

[VRe]

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. 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.

http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_pa ckages-002/

Check brainstorm and discuss here..

[Soheil]

Agree. But any idea how long did it take for the full release of 41 to .42 to go public?

[ARJWright]

There are two sides of Nokia releasing an update to included software that should be considered:

One side that's probably not considered often here is that even though Nokia is using open source software the business processes might not be as open and so hence the delay.

Nokia isn't a small shop; there are governance and logistical dependencies on every decision. Some of these are good, some of these impeed such fixes.

Concerning updates on included software, the questions that have to be asked include:
- does the update address something that has no dependency on locale/carrier included parameters with an object?
- is the update a major or minor fix?

If its major and has no dependency, then the business process needs to adjust to allowing for updates to come out faster. This endears those outside to Nokia in that it more closely follows open source foundations which may not have as many layers.

If its minor and has no dependency. Release it. No questions asked.

If it has a dependency, how can Nokia communicate their process effectively without damaging stakeholder relationships?
- Maemo as a commnuity needs to help enable Nokia to be able ot answer this question.

[VRe]

One side that's probably not considered often here is that even though Nokia is using open source software the business processes might not be as open and so hence the delay.

I atleast though of the business process and I think it is exactly the problem. It does not need to be open, it needs speed. It just between 2005 and 2009 there has been already many years.


Concerning updates on included software, the questions that have to be asked include:
- does the update address something that has no dependency on locale/carrier included parameters with an object?
If it has a dependency, how can Nokia communicate their process effectively without damaging stakeholder relationships?
- Maemo as a commnuity needs to help enable Nokia to be able ot answer this question.

Funky, there were no operators involved before, so is this going to get even worse :) ? .. I don't know what the process involves now but it shouldn't be much more complicated than: check it fixes the bug, check that old bugs do not appear, check it does not create new bugs, update docs, update i18n if necessary, release. A bugfix diminishes liabilities too, so lawyers are not needed and they will be sad!

I would be content with at promise that a fix in the version control would be released as bugfix release in 5 days, in 10 for issue with dependencies. Just make it (tm) happen - figure out why it is not happening and then fix the process. If somebody would go and measure the current fix-to-release process and check the lead times between "processing" stages, I sure they would find out that the fixes are just waiting "in storage" 99% of the time. That is waste(d time).

[ARJWright]

VRe, if Nokia/Maemo hired me, process improvement would be the exact area that I'd be working in.

[VRe]

Why there is such a monolithic release system in place? Release when everything is tested, all has to be ready or nothing is given?

Nokia has done updates for phones and older tablets the same way. When you think how a phone was flashed to newest firmware in a backroom of a store, it is easy to understand the value of complete monolithic update package. You're not going to the shop every day or week. Now the usecase is different as we use OTA updates - there is no backroom and therefore monolithic update release is the way of the past days. Full images can still be made for those store rooms if necessary..

As community we should encourage Nokia to do something which would make them really shine!

See: http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_pa ckages-002/

[ARJWright]

Why there is such a monolithic release system in place? Release when everything is tested, all has to be ready or nothing is given?

Nokia has done updates for phones and older tablets the same way. When you think how a phone was flashed to newest firmware in a backroom of a store, it is easy to understand the value of complete monolithic update package. You're not going to the shop every day or week. Now the usecase is different as we use OTA updates - there is no backroom and therefore monolithic update release is the way of the past days. Full images can still be made for those store rooms if necessary..

As community we should encourage Nokia to do something which would make them really shine!

See: http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_pa ckages-002/

Nokia has never released without a *lot* of testing. What Maemo is experiencing is what happens when a large company is involved as the driver behind fixes.

Of course, this is an open source movement, nothing is stopping anyone from crafting fixes for everything that's not IP-locked within the platform.

[evad]

As an additional note to this discussion/brainstorm is that it'd be actually very helpful for everyone if Nokia would "officially" communicate to Maemo Community Council (hence to all of us) what is on their current development plate, ergo what's their platform development roadmap for near'ish future - but in quite low, single feature-wise level.

So, apart from bugfixes which are more-or-less traced via Bugzilla, it would be nice to know that "we are working on feature XYZ, we can't give you exact release date, but please stay tuned". That way end-users would know what to expect in future - but also that scenario would be very helpful for developers that are planning to develop (or already started developing) apps designed to cover these feature gaps.

I know that's just wishful thinking and we'll probably never going to see such communication in place, but I generally think that's a grand idea to consider.

[Jaffa]

As an additional note to this discussion/brainstorm is that it'd be actually very helpful for everyone if Nokia would "officially" communicate to Maemo Community Council (hence to all of us) what is on their current development plate, [...]

I won't comment on whether or not I think that's feasible, but I was going to say that posting such a request in an existing thread is probably not the best way to do it (except Texrat has Thanksed a couple of posts here already).

I'd suggest, in future, an email to council@maemo.org, pointing to appropriate threads and posts here.

[evad]

I won't comment on whether or not I think that's feasible, but I was going to say that posting such a request in an existing thread is probably not the best way to do it (except Texrat has Thanksed a couple of posts here already).

I'd suggest, in future, an email to council@maemo.org, pointing to appropriate threads and posts here.

I was actually thinking to set this up as a separate proposal in Brainstorm, however I haven't yet checked whether similar idea has been already posted, as I don't want to create pointless duplicates.

Anyhow, thanks for suggestion to point this topic out to council email directly. Should I do that or have you communicated it to council already by any chance?

[Jaffa]

Anyhow, thanks for suggestion to point this topic out to council email directly. Should I do that or have you communicated it to council already by any chance?

I would do it yourself as a valued constituent :-)

[Milhouse]

Seems to me that a combination of three strategies would cover all the bases for "open" packages:

1) Continued inclusion in periodic, monolithic, fully tested and supported releases (eg. FIASCO images and SSU)
2) Incremental, "release when ready" packages, independent from monolithic releases (but with quasi official support)
3) "Nightly" builds for testing purposes (no support - bleeding edge testers only)

2) and 3) could use new repositories designed for the purpose, which would need to be added or enabled after the user has accepted a suitable disclaimer. Not sure the brainstorm really addresses the above, but it seems to at least touch on #2.

I wonder though if the availability of new packages might cause problems for the SSU process.

[iKneaDough]

Seems to me that a combination of three strategies would cover all the bases for "open" packages:

1) Continued inclusion in periodic, monolithic, fully tested and supported releases (eg. FIASCO images and SSU)
2) Incremental, "release when ready" packages, independent from monolithic releases (but with quasi official support)
3) "Nightly" builds for testing purposes (no support - bleeding edge testers only)

2) and 3) could use new repositories designed for the purpose, which would need to be added or enabled after the user has accepted a suitable disclaimer. Not sure the brainstorm really addresses the above, but it seems to at least touch on #2.

Do you mean something like PPA's (https://help.launchpad.net/Packaging/PPA) for Ubuntu?

I use PPA's all the time to get newer versions of software which didn't make it into the release.


I wonder though if the availability of new packages might cause problems for the SSU process.

In Ubuntu on a distribution upgrade, the update manager sets the PPA repos to disabled, and checks for any conflicting packages, and removes them if necessary to allow for a smooth upgrade experience.

Even with all the extra junk, and unofficial updates to core packages that I installed from the PPA's my machine had no issues upgrading from jaunty to karmic.

[Milhouse]

Do you mean something like PPA's (https://help.launchpad.net/Packaging/PPA) for Ubuntu?
.

Not specifically, although one thing I would hope we can avoid is a proliferation of repositories each containing a single package, but an automated build process would of course be very desirable.

[ndi]

I, for one, love ATI/AMD's policy.

They release each version on the 15th each month. Version is 9.12 (2009, month December). Whatever they fix they integrate and release each month.

Sometimes they have 2 fixes, sometimes they have 100, depending on what is needed and what new devices enter. The wait isn't very long and it certainly makes the user sleep easier knowing there's no sleeping on the job. I, for one, consider it a high selling point on ATI GPUs and, frankly, it's the only thing I buy.

Do you think this is worth submitting? It's basically the opposite of "don't let the user know we work on it" policy.

[qgil]

As an additional note to this discussion/brainstorm is that it'd be actually very helpful for everyone if Nokia would "officially" communicate to Maemo Community Council (hence to all of us) what is on their current development plate, ergo what's their platform development roadmap for near'ish future - but in quite low, single feature-wise level.

So, apart from bugfixes which are more-or-less traced via Bugzilla, it would be nice to know that "we are working on feature XYZ, we can't give you exact release date, but please stay tuned". That way end-users would know what to expect in future - but also that scenario would be very helpful for developers that are planning to develop (or already started developing) apps designed to cover these feature gaps.

I know that's just wishful thinking and we'll probably never going to see such communication in place, but I generally think that's a grand idea to consider.

I don't even think it's wishful. :) The less secrets the Council has the better. What can be "half communicated" is already communicated through bugzilla & brainstorm resolutions. Precisely the origin of this thread is that you are seeing bug fixed without releases of apps. That is communication in advance.

As for the current top solution proposed:

Solution #2: Independent applications (http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_pa ckages-002/)
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.

This solution could be applied to open & closed applications. I mean, the only difference is that open apps with source code available in the repository can be compiled by yourselves.

Still, the Maemo team thinks that it's safer to organize maintenance releases and be quite between them, unless there is a critical bug with a fix ready. Testing is done on a regular basis but it can be concentrated on candidate releases. The same happens with the communication with end users. Not everybody wants/bothers to see the icon blinking having to go through an update if they don't get something "significant" in exchange.

I'm an Ubuntu user and almost every day there is some fresh packages to update. I do it most of times as it's part of my Linux user routine but... do I see the benefits every time? Not really, as said is a routine. I'm fine with the 6 months updates and, to be honest, I'm not that in a hurry to update Ubuntu releases as it was before.

In 3,5 months we have seen 3,5 releases: Summit release, sales releases, PR1.0.1 (that's the 0.5) and PR1.1. This is quite frequent already, if you think of it. I'm not saying we will keep this rhythm but...

[v13]

Still, the Maemo team thinks that it's safer to organize maintenance releases and be quite between them, unless there is a critical bug with a fix ready. Testing is done on a regular basis but it can be concentrated on candidate releases. The same happens with the communication with end users. Not everybody wants/bothers to see the icon blinking having to go through an update if they don't get something "significant" in exchange.


I've created a brainstorm for this and added an idea which (I believe that) solves almost all problems. Have a look here (http://maemo.org/community/brainstorm/view/improve_maemo_release_cycleis)

[qgil]

Thanks, but please create the corresponding thread for that brainstorm proposal not to mix discussions. Thanks!

[v13]

Thanks, but please create the corresponding thread for that brainstorm proposal not to mix discussions. Thanks!

Do you believe that I should add the proposal as a solution to *this* brainstorm instead of creating a new one?

EDIT: I did just that. Feel free to vote :)

[Milhouse]

I'm an Ubuntu user and almost every day there is some fresh packages to update. I do it most of times as it's part of my Linux user routine but... do I see the benefits every time? Not really, as said is a routine. I'm fine with the 6 months updates and, to be honest, I'm not that in a hurry to update Ubuntu releases as it was before.


Importantly, the Ubuntu user can choose how often to check for updates - daily, weekly etc. - which isn't the case with Maemo, which seems to have a hard coded daily check... so this would need fixing if incremental updates were to be made available, and perhaps should be considered as an enhancement in any case.

[Milhouse]

Still, the Maemo team thinks that it's safer to organize maintenance releases and be quite between them, unless there is a critical bug with a fix ready.

Perhaps an "opt-in" scheme could be implemented, allowing the more technical users to receive regular updates (nightlies/snapshots) in order to help progress the development/testing process, while "regular users" would stick by default with the monolithic releases.

Essentially this would be a compromise. Opting-in to the nightly/incremental upgrade process would void the normal level of support Nokia would be compelled to grant the user, which would be reserved only for monolithic and fully tested releases.

[Hrw]

http://marcin.juszkiewicz.com.pl/2010/01/18/system-updates-repository-online/ describes my repository with system updates.

I was tired of waiting ;D

[evad]

I can see Quim's point, applying approach from regular desktop distros might be quite diffucult here - especially when we take into account there are lots of non-geek users around who probably wouldn't be that excited to get minor'ish updates every second day. Other downside is that frequent mini-updates of single packages might lead to numerous problems with complex dependencies, broken applications, bad user experience etc. - which again would not be acceptable to regular users that simply paid lots of money for a device they expect to "just work".

However, suggested opt-in for frequent and single-package update approach seems like a best compromise indeed. I'd see that as SSU-Devel repostiory in application manager, which would get these little package updates, while regular SSU repo would still push big and monolithic updates every now and then.

[VRe]

I can see Quim's point, applying approach from regular desktop distros might be quite diffucult here - especially when we take into account there are lots of non-geek users around who probably wouldn't be that excited to get minor'ish updates every second day.

But if you use extras, you are already getting them. So what is the difference If we would have few other programs updating as well? Not daily but few times a month or so..

Other downside is that frequent mini-updates of single packages might lead to numerous problems with complex dependencies, broken applications, bad user experience etc. - which again would not be acceptable to regular users that simply paid lots of money for a device they expect to "just work".

Again why this would be any different than extras or how any other linux distribution do it? It's not like libc would be updated, platform is different thing. These are just programs as most of the other updated stuff.

[evad]

But if you use extras, you are already getting them. So what is the difference If we would have few other programs updating as well? Not daily but few times a month or so..

Again why this would be any different than extras or how any other linux distribution do it? It's not like libc would be updated, platform is different thing. These are just programs as most of the other updated stuff.

Well, yes and no. I wouldn't directly compare, say Hermes app from extras, with Phone app from core applications repo, for example. When I spot a bug in Hermes, I can live with it, but whenever Phone app gets released with some weird bug in it - I can probably live with it too until another hotfix gets released (or I downgrade), but imagine the whole bunch of non-geeky users around. That's why I'm slightly afraid of with desktop-a-like repository releases (although I did actually vote for that approach in Brainstorm).

Speaking of desktop, I remember some time ago a regular upgrade to my Fedora distro that suddenly made video card driver not loading properly, hence I couldn't start X.org or anything. I found a workaround, fix has been released shortly after, yet still not everyone would cope the same way, I guess.

Generally speaking, I am up for single core application update releases, but I also understand Quim's point on this, hence I think optional "opt-in", as suggested by Milhouse is a good compromise.

[sjgadsby]

Importantly, the Ubuntu user can choose how often to check for updates - daily, weekly etc. - which isn't the case with Maemo, which seems to have a hard coded daily check...

The repository check frequency is determined by a value in GConf. See:gconftool --get /apps/hildon/update-notifier/check_interval

Speaking with the confidence of someone who has never written a Maemo control panel add-on, I should think it'd be a fairly simple matter for someone to craft one that is a simple, finger-friendly gconftool front-end for this.

[qgil]

Let's forget for a while the trouble with end users getting more "unstability" than they wish and let's look to the changes that would be needed in the Maemo development before being able to offer such unstable releases.

There are several concepts that are intermixed (in Maemo and in this debate) and they need to be clearly decoupled to make some progress:

Upstream / downstream

The brainstorm proposal mentions as examples Modest and the Application Manager. Maemo is at the same time upstream of these applications (we develop them) and downstream (we distribute them). This is a different situation than in most of your preferred apps in your preferred distro, since distros usually don't develop the apps they integrate. Only in exceptional situations a fix committed today in an upstream project will end up as an update to your distro in few days/weeks, even in the unstable branch. Debian/Ubuntu have a powerful combo that is able to downstream many fixes quite fast. Then again these projects are specialized precisely in public integration & distribution, while our main focus is development and productization.


Platform / applications

As pointed out in "Solution #2: Independent applications", the first step is to decouple platform for applications. This is easier said than done when you are heavily invested in upstream development. Many times the new version of an app requires an update in a platform component because we are pushing both features and enablers as fast as we can in the internal development. This is also specially complex in the current setting with native apps and a GNOME-style API served by several components. Look in comparison a future situation with Web Runtime apps relying basically on WebKit and native apps relying basically in Qt. Maybe then it will be easier to decouple platform from apps being upstream & downstream in both?


Features / bugfixes

As pointed out in "Solution #3: Separate bugfixes from development", ideally you have in place a proper branching where you can develop features in the master while applying pure bugfixes in your stable branch. This is nice and cool in the paper, but starts being more complicated when you need to release not only bugfixes but also new features to your customers within months. This is a reason why "Solution #5: Use Debian's method" might not be the good idea you initially would think, since our process needs to be prepared for faster releases, often tied to a certain date.

x86 / OMAP3

When you release fresh code for x86 you know that there are several distros that will pick it up and will downstream it to a big park of Linux users, many of them used to update regularly their packages. Now compare this situation with Modest, the Maemo Browser, the Application manager, as for today used basically in the N900. Of course this is cause and consequence since working well on the previous points would help these apps getting more Maemo testers and perhaps a wider distribution to another OSs. But this hasn't been the priority and anyway you reckon that the OMAP3/mobile burden is not trivial to cross.


Said all this, we do see the purpose and the usefulness of this proposal. It's a good goal to aim, not only because of the goal in itself but also because achieving it implies a more solid and standardized platform. For users, for testers and for developers.

[v13]

As pointed out in "Solution #3: Separate bugfixes from development", ideally you have in place a proper branching where you can develop features in the master while applying pure bugfixes in your stable branch. This is nice and cool in the paper, but starts being more complicated when you need to release not only bugfixes but also new features to your customers within months. This is a reason why "Solution #5: Use Debian's method" might not be the good idea you initially would think, since our process needs to be prepared for faster releases, often tied to a certain date.


FWIW: Using debian's method doesn't imply non-often releases. There is no reason why you can't have one release per-month.

[ewan]

Other downside is that frequent mini-updates of single packages might lead to numerous problems with complex dependencies, broken applications, bad user experience etc.

This is a long since solved problem. The packaging system used on Maemo can deal with all of that completely automatically, and does so very successfully in much more complicated circumstances than this. If it can deal with the churn of Debian unstable (and it can) it can deal with individual package updates to Maemo.

I'm really not sure where the impression that Maemo is somehow a special case, or is more prone to failure than a desktop distro comes from.

[qgil]

FWIW: Using debian's method doesn't imply non-often releases. There is no reason why you can't have one release per-month.

The question is not how often you can have releases but how long does it take for an upstream bugfix package version to go through Unstable --> Testing --> Stable branches.

imho the Ubuntu model would fit much better: branch --> freeze --> release --> push bugfixes while starting a new branch.

Note: I have no decision and not even influence on the model Maemo might adopt in the future, if any.

[Texrat]

Note: I have no decision and not even influence on the model Maemo might adopt in the future, if any.

Not even influence???

Quim buddy... I find that disconcerting. : /

[wjbaird]

Features / bugfixes

As pointed out in "Solution #3: Separate bugfixes from development", ideally you have in place a proper branching where you can develop features in the master while applying pure bugfixes in your stable branch.



I've worked in commercial software development for a long time as both a developer and now a product manager, and this approach is workable, although it is a bit more work.

the product I've been product managing for the past 3 or 4 years is a little similar, in that there is a large amount of core code (similar to the platform), surrounded by a large # of smaller components that use the core code (similar to the applications).

The approach we take is to have major releases where the core code and the smaller components are both updated, and then much more frequent 'service pack' releases where some of the smaller components are updated, but we don't touch the core.

It's actually not that big a hassle to manage - we pull a 'maint' branch off after each main release, and then merge selected fixes for the smaller components from the main tree into the 'maint' branch as needed, and then create sub branches off the maint branch for each service pack.

As long as you are a bit careful about only populating the service pack branches with fixes that aren't impacted by changes in the core, the developers generally don't take long at all to move the fixes into the service pack, and the QA is pretty limited, since the core hasn't changed.

For quite a while we were doing service packs with 50-100 fixes about every 4 or 5 weeks, although we've backed off on that a bit.

If it allows you to do things like roll out fixes to issues like https://bugs.maemo.org/show_bug.cgi?id=6615 sooner, it'd help us users a lot! I've been hit by that one three times in the last 36 hours...

[Olvi]

I've been using Debian and Ubuntu(which use the same system to manage packages as Maemo) for years. Unless it has been a completely new major release version, I've never had to install updates in a huge lump like we do with PR-updates on Maemo, just install the packages that have been updated.

So why can't Nokia just upload at least some of the critical bugfixes straight to the repos instead of sticking them into these huge major releases (1.2 with Qt)? I mean there are LOTS of critical bugs for which many of us have waited fixes since the release 6 months ago! It's not like this is the iPhone which needs to be flashed completely to a new version, we HAVE a working package management for exactly this sort of thing.

So please, could someone smarter than me explain why I have to wait months (1.2 frozen week 9 AFAIK) for PR1.2 to finish testing until I can finally use mfe prperly(fix should be in 1.2?), for which the fix has been marked ready for ages! Surely not all of the fixes have such dependencies making this impossible?

Hopefully there is an actual reason, getting tired waiting months for PR1.2 to come with the numerous very important bugfixes...

[un-named_user]

@Olvi.

Dont know why Nokia doesn't separate bug fixes from updates/enhancements and insists on lumping everything into big monolithic updates. But it has been their policy considering they do the same with most of the Symbian devices updates.

There was a discussion going on about it here
http://talk.maemo.org/showthread.php?t=35793


And a Brainstorm. Dont know if this will help though considering it has had so many votes, but seemingly no concrete results.
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_pa ckages-002/

[Blinde]

Very good question indeed. It would be a lot easier that way.

[southwalesboy]

yer why dont they release bug fixes, and then have roll up updates, like windows Servce packs. that set the bar for minimum specs/requirements for software to install. its annoyin waitin months for a bug fix that was marked as done on the garage months ago!

[theflew]

Can't answer for Nokia but I imagine they do this so the platform is more stable and in a "know state". No one wants to see an update on their phone every couple of days like a desktop OS. It gives the impression that their is something wrong or not complete. Phones are closer to appliances and expected to just work not have constant updates.

[toto29820]

Because some programming bugs can just go away after other bugs got fixed. Nokia saves its effort this way. Just fix more crucial bugs and other small ones may just gone.

[kazuki]

nokia have been doing it all wrong. if they actually established their system to debian, all this pr1.2 pain would've been avoided. all they did is hold up all the crap and nobody knows how the everything is going work once its released. if nokia released their kernel like debian and ubuntu did, bugs would have been squashed so much easier since u can actually see if its buggy instead of speculating. the way nokia holding up pr 1.2 is ******ed.

[Siggen]

I agree with the Debian/Ubuntu method, I bought this device to feel like I had a netbook in my pocket, the way nokia releases maemo updates now feels like iPhone/Symbian (have not tried to update Android), where as my ideal desktop/laptop/netbook OS would have individual packages updated as they are finished.

And @toto29820 what your saying is the oposite of reality, bugs dont go away, even if their dormant their still there, clean code = less faults + higher performance + less battery usage. And its easier to fix and find bugs when its released in a modulatory system.

[sjgadsby]

The thread "Why huge firmware releases instead of single packages?" with eight posts has been merged into this thread.

[cfh11]

Bump... this doesn't get nearly the attention it deserves. Nokia - take a look at the way extras-devel and extras-testing works. Why wouldn't the same model work for bugfixes to the OS? You could still package all the fixes in massive firmware updates, but could get far more valuable feedback by releasing the "internal builds" to extras-devel (or a similar repository) for testing.

There... I said it. Not that anyone of influence will read it, but to me it is just common sense.

[cfh11]

Bumping again...Come on people MAKE SOME NOISE!!! lol

[Milhouse]

Bumping again...Come on people MAKE SOME NOISE!!! lol

Just to annoy you (actually, it annoys me too):

Google splits Gmail and Android (http://www.theregister.co.uk/2010/09/22/google_splits_gmail_and_android/).


"Gmail updates aren’t tied to Android version releases anymore. Now you can get new Gmail stuff faster without having to wait for system updates," the company said in a blog post.

This is what Nokia should be doing with most of their apps. No chance of it happening for Maemo5 of course, but it should be the norm for Maemo6 and MeeGo.