Re: Ask the Council!
 

Thanks for the input, much appreciated.

Agreed.

The reason I mentioned FOSS replacements is that they've currently got a hard-dependency into the image, making installation of replacements harder. However, it could well be the same solution for both of your requirements: I think the CSSU could ensure that nothing depends on modest or mediaplayer, allowing an Extras package in Section: user/multimedia to come in and replace it; or an advanced user to do apt-get remove modest etc.

For example, from mp-fremantle-generic-pr (the core SSU):

Once the SSU is installed, having something which replaces all aspects of it becomes easier. A few random thoughts OTTOMH:

1. Would the Open Media Player want to be installable alongside the original one?
2. If it was designed to replace it, would the main package in Extras depend on community-ssu-enabler?
3. Could it work that Open Media Player is installable alongside, but has a small sibling package - or menu option - to remove the original one and slide into its place: iff the CSSU is installed?

Re: Ask the Council!
 

The new media player should replace the old one completely as part of the Community ssu.

Re: The in-development Maemo 5 Community SSU
 

Is the intent for the SSU to work towards possible replacements for lower level nokia closed binaries (e.g. things like bme or the connectivity libraries)?

More specifically would such things be accepted if someone was to create replacements (and if they were properly tested and etc)?

Re: The in-development Maemo 5 Community SSU
 

The CSSU itself is a delivery mechanism. It could deliver those if they existed.

That's a much better policy question :-)

Re: The in-development Maemo 5 Community SSU
 

Regarding the FOSS replacements, perhaps it would be good to have one repo for replacements that completly replicate the original functionality (even the quirkier rarelly used options, there is always someone that will miss them), leaving those untouched except for bug fixes (and other fixes that doesn't do away with functionalities nor does any major reworking of the parts of the programs users deal with), and have a separated repo for the more radical replacements (perhaps make some sort of standard for version numbers giving the ones in the radical repo a huge distance ahead of the plain recreations repo so that at least until a century or so from now the version numbers in the plain replacements repo will never reach the earliest version in the radical repo, or just use fractional version numbers on the plain repo and in the radical repo use the fractional part to indicate what plain version the radical was based on and the rest of the number for the actual version number for the radical repls. ; or whatever you guys consider the best way to do it )


edit: the plain and the rad repls. repos could each have -testing and -devel companions like extras, or whatever you think is better

Re: Ask the Council!
 

Oh dear (diety name here), please do not make things depend on other things unless they literally are the only thing that could realistically be expected to make it work.

Even if Open Media Player is supposed to replace the main package, it should be left to the end user to make that decision unless a horribly un-work-around-able reason makes it a PITA to make that happen. Even if your Open Media Player is the best media player that ever walked the earth, someone will want to have both on their system, and if they want it, they should be able to have it. So no ____ conflicts with _____ just because some dev didn't think normal people wouldn't want both, no ____ depends on ______ unless the latter actually HAS TO have the former, and if you're going to do that you should also be watchful of other things that other developers might make that fulfill that dependency. (EG, Kernel Power Settings shouldn't depend on JUST Kernel Power, it should optionally depend on kernel power, UBoot-for-kernel-power, and any other package that flashes the power kernel to your kernel partition. Etc.)

So I say the latter is fine, however, the ideal solution in my opinion is just exterminate all the 'dependencies' that aren't actually necessary when you make the CSSU (IE, no, my FreOffice, FM Radio, or whatever else I want, does not depend on my having the preinstalled hildon-application-manager on the device, and don't you dare try to tell me otherwise Nokia), but don't make it so that the new stuff replaces dependencies - someone might not want to have a media player on their device, at all. That's odd, and that's unlikely as hell, but it's feasible enough that if someone does feel that way, they should be able to do it without having to muck around with .deb control files for every little thing.

So, my recommendation is, kill the unnecessary dependencies, don't make any new ones unless they literally HAVE TO be there, and everyone developing the FOSS replacements to the closed source apps, I say do the same thing: Don't stick any conflicts between the two unless they have to be there.

Re: The in-development Maemo 5 Community SSU
 

Simplified version of Mentalist Traceur's post (which I largely agree with):
Please endeavor whereever possible to have conflicts-depends based on technical necessity, not End-User Experience or politics or what someone else thinks might be nifty or whatever. Maybe we could have someone add Recommends: display support to fapman (or the original HAM), if such a delivery mechanism is absolutely needed. :D

Personally, though, I say for the starting effort, stay focused on bugfixes for the apps we can get to. I don't know enough about how Maemo does its dependencies to know whether or not it's worthwhile to try to uncouple End User-Experience type apps from the base OS or not. I'd love the option... but I'm more interested in getting silly bugs fixed without having to install .debs by hand. :) Stuff like that can always be added in later updates, anyways, IMO.

Re: Ask the Council!
 

I've added a new one:

• At what point do bugs get set to RESOLVED FIXED? Such as #3700

Re: Ask the Council!
 

In my opinion....

1. The CSSU should be owned and steered by the council, for the good of the community.

2. Improvements should be limited to bugfixes, and improvements to the core OS. I think either seperate packages should be created for replacement of core apps, or a metapackage which will offer the ability to install apps such as MAG's portrait varients, and the new QT media player. A good example of how this could be implemented is the Maemodder package, which lets you pick and easily install common mods via GUI, and allows regression. An alternative for OS alternatives may be as a distinct section within the Repos, and to prefix the packages appropriately so "upgrades/replacements" can be easily found.

3. Testing - should be as an upgrade from PR1.3, with regression back to it on removal. Testing should also be limited to the specific fixes/enchancements which have been changed, otherwise it'll take ages.

4. Should be advertised by forum initially for keen/adventurous/power users, and then barring any major issues, be advertised heavily on the seperate sections of maemo.org including MWN.

5. Official support should be via bugzilla for confirmed issues, There will be forum threads regarding any CSSU anyway.

Re: Ask the Council!
 

from the bug report page...

I would suggest when the CSSU has been launched and passed widespread testing.