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.

http://marcin.juszkiewicz.com.pl/201...sitory-online/ describes my repository with system updates.

I was tired of waiting ;D

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.

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.

The repository check frequency is determined by a value in GConf. See: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.

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.

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

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.

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.