maemo.org - Talk - View Single Post - The cohesive community: from talking to doing

	allnameswereout	2009-01-12 , 23:06
	Posts: 3,397 \| Thanked: 1,212 times \| Joined on Jul 2008 @ Netherlands	#59

Originally Posted by tso

same with debian. things go in at the testing end, gets bumped to unstable, and finally reach stable.

(Experimental ->) Unstable -> Testing -> Stable.

And, this goes very slowly. SSU are like security.debian.org and perhaps some backports for reliability and stability. But for sure not full backports also heavily providing functionality. One must be careful with the latter; these for sure introduce all kind of regressions. So this is not viable for a Stable tree such as Diablo. Hence; SSU.

If you wish to compare to Debian then every Maemo version is a new Debian version with a Debian Unstable and Debian Testing tree internal.

What you appear to wish for is those trees public?

but with the ssu you cant. its either all or nothing. you cant tell the app manager that you dont want the kernel updated as you have rolled your own. no you have to take the kernel or the ssu package wont go in, and therefor none of the other packages will go in either.

(See my comment about the function of SSU.)

You should have your SDK ready to apply the patches, and then use APT to recompile. On a desktop or server this is easy, and creating the package goes fast. On a mobile/embedded device this is a bit harder. Most people here do not do this; they wait on the packager of the source to fix this. This is our choice. We, as community, can have something like Mer and use this as base and backport from Maemo directly instead. Even then, you will want stable device and Testing is relatively Stable but not suitable for mission critical usage.

and its not really clear what the ssu will touch on, until its rolled out.

Changelogs would be welcome. On a Debian(-like) system you do not know this either unless you install e.g. apt-listchanges. BTW, apt-listbugs is also very useful.

The reason why this matters a lot on Maemo is because users modify the core system a lot.

One is free to do this, but Nokia provides a disclaimer as well. You're on your own when you do this.

and as the diablo dialog is not open source, people are left with no chance of a fix, especially as they dont know if fremantle will be new hardware only, or not.

the only real saviour here is mer, but it seems hellbent on doing the maxium change rather the minimum change (ripping out and replacing nokia's closed bits).

A lot of Maemo is open source; this is open source spirit. This is much different than TiVo. Nokia is opening more and more, and alternatives such as Mer have less obstactles so you can get something equiv to a public Debian Testing.

to me, nokia needs to decide if they want to get into the open source boat, or stay on the closed source pier. right now they seem to hope they can evolve some very long legs by keeping one in each, with the boat sailing...

I, for one, will judge based on the number of closed source components in Maemo Fremantle and the progression made with the closed source components in current tablets. I'll also thank those who put the effort in Mer from my heart because they're part of the alternative 'ROM' making it happen.

Compared to what happened with Sharp Zaurus this situation looks much more bright... there, we had to use Linux 2.4 for a long time, and had no changes in the firmware/ROM at all!

__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!

Quote & Reply |

The Following User Says Thank You to allnameswereout For This Useful Post:
danramos