But what happened to "Release often releease early" then? I have some vague memory of that being mentioned together with Maemo and Linux. Isn't there a stable core to build upon? If they have to make what appears very large updates where all components are tuned to work together (there and then) then it seems to me that there are some problems with the core. Just my 2 cents on the subject...

No need for the attitude, it's why i phrased my post as a question. because i don't know about the process. So i'm asking to be corrected.

Do you have insights on why this scenario is not realistic?

Hmm. I'm not on the dev. team but maybe I can shed some educated guesses

1: Bob could be an engineering / product manager who is looking across multiple teams from engineering to QA to third-party developers (flash, mozilla , Skype and etc). Releases are NEVER perfect. The question is whether or not that particular release has the desired or acceptable fixes required without regressions. Rarely do they all line up and express readiness as a yes or no. Usually the answer is "it depends on what you mean by acceptable"

2a: If they knows all the problems and fixes then the answer is they'd release it
2b: If they found problems but have not isolated then its a matter of understanding how pervasive the problem is. Does it affect one component (UI causing memory lead) or is it kernel related that affects everything from memory management to browsers to the phone
2c: Once they've isolate the problem they have to reproduce it then make an guess as to what they think it will require to fix it, keeping in mind that they can't break anything else in the process.
2d: They then have to do the actual fix and then unit test and make sure that it does in fact fix what was broken and hasn't broken anything else
2e: Depending on the level of fix they may have to test everything all over again. Remember that code isn't isolated. They're not dealing with typos and misplaced semi-colons here. These may be large systemic issues that affect multiple components. A fix isn't just an isolated blob of code, but could mean a series of actions that can and will affect other pieces of code.

Just throwing out a random example. Let's say for 1.2 they made everything scroll smoother more realistic. Well in the past maybe hand gesture scrolling wasn't so good so individual app makers wrote / hacked code so that scrolling was acceptable to their app. Now that scrolling has been fixed the hack now makes the apps unusable or perform worse. The fix could be done by making changes to how the scrolling is done or it could be in the individual app. Again I want to re-iterate that I don't know the issues with 1.2 but wanted to illustrate that code is interdependent and answers aren't always clear cut.

More conjecture. One focus of this release seems to be performance related. The one thing I've found in the releases I've managed is performance related bugs are in layers. As you improve performance in one area that only shows the bottlenecks in the next, and so forth and so on. It's a good thing but this stuff takes time to sort out, there are no magic bullets. Again, just a guess.

To me anything that has taken this long means they're in a dependency nightmare or there are regressions. If for example Flash was the issue they'd just do what they did last time, disable flash and have flash update separately after. They aren't doing that because I think they are dealing with internal dependencies that affect all components. And if there are regressions. It's certainly not acceptable to start losing current functionality for a few new things.

3: How can they guarantee that they'll release this month or next without the proper timelines? For major releases usually there is a usually a beta and test window where features / bug fixes are frozen well before release. With updates like this there is feature creep and intermittent bugs which get added. Their intentions are good because the community clamors for all fixes but what results is a hairball where they probably should have done a more traditional test cycle because with the new features and major changes, this is more than just a 1.2 but maybe more like a 1.4 or 1.5 (when looking from a scale perspective). But hindsight is 20/20 right?

Or it could be some executive unilaterally decided to move half of the engineers to Meego to make that successful. Who knows.

All these speculations when the reason is simple.
Eero Tamminen, one of Nokia's principal Maemo engineers, has outlined some of the reasons why the forthcoming update to Maemo 5, PR1.2, has been delayed: "
As one example, when we optified some of the rootfs content to make more space on it (for SSUs), we had to deal with the slowdowns coming from those packages being now on eMMC (which is slower than rootfs especially when the device is swapping). This required quite a lot of iteration on what to optify, SSU issues, policy & memory locking finetuning, otherwise optimizing slow things etc.

http://lists.maemo.org/pipermail/mae...ay/026132.html

No smoke and dagger or conspiracy there.

Eh... Isn't it exactly what's written and linked to in the very first post in this thread?

Yeah my bad just came accross it on maemo-developer looks like the original source.

This is again a not very convincing excuse:

1. Optification process was decided (or at least) publicized by Nokia in Sptember 2009. This is more than 8 months ago. Surely performance testing does not take that much.

2. Assessing the performance impact of placement of system files is a task that is easily parallelized. If it takes too long it is because Nokia chose to put too little people to work on this task.

here is an example of a deep problem in my opinion: https://bugs.maemo.org/show_bug.cgi?id=5880
So bluetooth and wifi share the same physical antenna, and causes both bluetooth and wifi , to fail when used in conjunction.
this issue also appears in previous N800.
However nokia didnt fix it for the N800, and I doubt they will fix it in PR1.2
Sure hoped this issue was solved.
Niv

Interesting my bluetooth works fine now. I am using Motorola t505. No complaints so far from my friends when I call them using the bluetooth. (PR 1.1 fix my disconnection bluetooth problem though)

The only thing that I hate previously there is a speech commands (symbian model), so I could call up my contact from the button, and the phone will auto dial.

I normally just don't care about official release dates. I switch to the new version as soon as I'm convinced it is stable enough for my needs. Unfortunately, with Maemo this is not possible. Why is it so hard to make an unstable branch available to the public? It's just an APT repository with the latest development versions of Maemo's software packages. To soften the update process weekly images could be made available. It's very likely that those do exist anyway for internal testing processes.

When it breaks, so what? That's what the flasher tool is for. Before I choose to run the unstable branch I make sure that I don't have to rely on the device's availability and everything is fine. All major Linux distributions are doing it that way and it works. You don't have to make sure all dependencies are satisfied all the time as it is an unstable repo und therefore it's no disgrace if things are broken from time to time. If certain software lacks important functionality or is completely broken then that's probably the reason why it hasn't been pushed to stable yet so there is no problem with that also. It can't be so much work. Come on.

I just hope that MeeGo puts an end to this tragedy of developing behind walls. Take a look at Fedora if you seek for inspiration.