Notices

The same option they would have had if Nokia had made PR1.4.

You know where is this from, right?

The Community Seamless Software Update (CSSU) is being developed by the Maemo community as a continuation of, and expansion on, Nokia's update support.


I am not saying we should behave the same way Nokia did, but there are times one have to make choices. And if I have to choose between no more CSSU updates (because, lets be honest, we lack the manpower to change the -mp thing and transform it according to some better FOSS standard) and to make CSSU unavailable to a couple of people using some the-best-kernel-ever-made (while fixing the long-standing nasty bug in omap1) or don't like the exact color of a button in the resolution change dialog in nikocam, I'll choose the latter in an instant.

Wrong, CSSU will not depend on a particular kernel, but on a kernel feature, patches are FOSS, so anyone can port them to the fancy kernel he uses and stay compatible with CSSU

Apart from my personal doubt if users in general are really waiting for these kind constructions, I wonder if it is even feasible. I can imagine core developers like Pali and Freemangordon primarily want to focus on the software components itself.

As I attended that meeting also, I remember that we agreed upon a similar path you described. Merlin1991 would make some adaptions in HAM to start with. But he soon gave up on that, and I have no indication that he (or anyone else) is interested in taking up this challenge.

Challenge? Lack of manpower?
What in my last posts sounded like even as much as days of work? Even hours?

I'd say you're simply not willing to even consider it.

What The F...k is the challenge and needed manpower in removing a package from MP???
I very consciously blame you for abusing/exploiting MP as a cheap excuse to forcefeed your personal preferences onto all CSSU users.
Or is this just a glitch in communication?I never suggested to "change/transform the [whole] MP thing", at least not short term. We actually don't have the manpower for THAT. But what's an inevitable demand is that new (replacement) packages don't perpetuate that broken MP thing but rather use a better way to package and distributing them - a way that's independent of MP and absolutely not introducing any significant overhead. Thus your argumentation of "take it or leave it" is not honest.

Oh, and Ade, when you actually attended that meeting and the following chats, you pretty well know that HAM was no way a core requirement for implementing independence from the buggy broken Nokia-MP. We knew from very beginning that apt can handle all that just fine and it's only HAM and its user UI that needs some patches. Nothing like " make some adaptions in HAM to start with." Rather we decided to implement/package packages the right way to start with.

Just again, since it seems you still don't grok it: we don't need any patches in HAM to change packaging towards some scheme that allows powerusers to remove/replace CSSU-FOSS-alternatives by the core Nokia fremantle package (read the last statement again! make sure you got the meaning right!). Those power users can use apt for that. And you - the developers and maintainers - don't need to distribute/ship your new FOSS packages via HAM and MP, you as well can use apt and a tiny script for that (at least I hope you know how to do that). The only thing you lose is 30 min for creating such script (one-time effort, adding new packages is as little as 30s) and your "option" to force those new packages onto all users since they can't opt out of them when those packages are in MP, even when they are willing to use apt.
Not that the amount of work was any legit argument for forcefeeding something onto users based on "we have no manpower for that" aka "we're too lazy or not experienced enough and not willing or not capable to consider the topic". Not even when the correct packaging would make up to 50% of development effort. Basically the rule applies: "if you can't do it the right way, rather don't do it at all than in a way that makes things worse".
But in THIS VERY CASE the effort is as neglectable as it can get, it's simply you who are not willing to even discuss it. If you think this is a false assumption then educate me what's the unbearable amount of work in doing it the right way, please!

I am not forcing anything to anyone (as you have the habit to throw in as an argument at people that do not agree with you on this). Every decision one makes, doing nothing, go left or right, effects other people and can thereforce be interpreted as "forcing".

Now how can we proceed in your view? Can you make Merlin1991 interested again (you guys frequently meet on IRC). Can you perhaps play a role in these HAM changes? I lack the knowledge for sure. I am not that must interested how we get there (your proposed way, seperate repos or whatever), but that some progress is made this after 18 month.

P.s. and just my humble advice (not forcing anything on anyone ): try to stay away from the unneeded F-words. It would make this place so much more relaxed...

P.s. 2: I see you edited your post and now stating that HAM changes are no longer needed? Did your view change on this? It was very clearly defined as a condition back then.

The HAM changes are needed to give users a GUI where they can pick alternatives. It's NOT needed for proper packaging. Never been.

I heard arguments like "we won't package in a correct way since some GUI in HAM is missing to use the additional options this would provide" (ignoring that all users still could use apt to use the additional options)
and even "we won't contribute any more when our packages are not forced onto all users via HAM/MP" (The latter explicitly stated, claiming that devels "have a right that all users use their package when those devels bother to provide such awesome piece of software"). I think this pretty much explains why I'm not very polite on the whole topic anymore.

And again: Sticking with old broken MP way of packaging for new alternative packages IS forcing them onto all users of CSSU, since no user has the knowledge to handle a system where the new package got replaced by the old one. Actually there IS no proper way to handle such a system (except maybe by building your own private MP and replacing the mp-community-pr by it).



How to proceed? See point a) in my prev post (remove package from MP), which already is accomplishing 90% of the "fixing the issue" that's needed. Then deal with the remaining 10% which are "how do you nevertheless make sure all users get the package (update) on next CSSU release?". For the latter I suggested a simple postinstall-script-only package that uses apt directly to update the new package when it actually already got installed, and otherwise maybe asks user "do you want to install new package XYZ?" when it never been installed yet. I'm sure you guys are smart enough to figure some shell 10-liner to accomplish sth like that. The only relevant point is: user must have a choice to keep the old Nokia package if she wants.

[edit] A very low effort (and almost silly) approach would be: make a NEW mp-community-pr-all-addons and simply move the new packages from old mp-community-pr to the new *-all-addons. Do NOT include the new *-all-addons MP to the original mp-community-pr, but rather allow users to opt-in (or even opt-out) by simply installing/removing the mp-community-pr-all-addons metapackage. All users that have such package installed will continue to get all the alternative FOSS new packages, while those few users who don't want (some of) the new FOSS stuff simply will uninstall the *-all-addons and are free to install an arbitrary selection of CSSU FOSS addon stuff manually then. A careful manual apt-get upgrade will still get them all the updates on those addon packages, while the stripped mp-community-pr will pull in the updates and new *mandatory* packages on all further CSSU releases as usual.

/j

Looks like a proper subject for the next cssu-meeting, just to get all noses in the same direction and give it a followup this time.

ehm, as I understand it we are all pretty much in agreement regarding the core statement "bundle FOSS-replacements in CSSU but give the users choice to revert using apt" so why the tension?

Seems like as only 4 to 6 posts ago everybody was really busy finding arguments why we can't do exactly this giving users a choice. Since 18 months I get flames where users worry about workload of devels and devels worry about percentage of users interested in such freedom of choice and nobody worries about the CSSU chief maintainer and what he declared is our official policy and path ahead, 18 months ago. And some continuously call me all kinds of names for my silly figthing for the most natural thing in FOSS ever: allowing users to select their own arbitrary set of packages to get installed on their system.
You ask why the tension? Because I'm really kinda stressed about all that odd mindset.
Happy that you as well as Ade finally agree though. :-)

/j

what the heck is testing for ?
been over a year but still nothing !
oth every single rewrite is exellent but they are in repos not in cssu testing ?
why cant things be pushed to cssu testing and see how they pan out and adapted accordingly ?

http://wiki.maemo.org/Community_SSU/#Testers
http://wiki.maemo.org/Community_SSU/...log#Tmaemo10.1