The in-development Maemo 5 Community SSU - Page 4 - maemo.org

Active Topics

Is there a section to talk about Java ME? Apps, etc. (6)
to General by Kalatti - 4 days, 8 hrs ago
more...

Page 4 of 544

Thread Tools

	Jaffa	2011-01-14 , 09:07
	Posts: 2,535 \| Thanked: 6,681 times \| Joined on Mar 2008 @ UK	#31

Thanks for the input, much appreciated.

Originally Posted by Viqsi

I'd stick to improving existing OS packages, and let "useful" stuff stay in Extras. If the community wants to get involved in endorsing other nice things (like, oh, I dunno, fMMS or similar), that sounds like a separate project to me.

Agreed.

Ditto for FOSS replacements of closed Maemo apps.

Or, IOW, I wouldn't mind having the ability to, say, uninstall Modest (since I never use it), but I don't want that sort of silly side preference to hold up getting other bugfixes going quickly.

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):

Code:

Depends: ..., mediaplayer (= 1.3-4+0m5), ...

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

Would the Open Media Player want to be installable alongside the original one?
If it was designed to replace it, would the main package in Extras depend on community-ssu-enabler?
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?

__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org

The Following 2 Users Say Thank You to Jaffa For This Useful Post:
joerg_rw, OVK

	Venemo	2011-01-14 , 09:54
	Posts: 1,296 \| Thanked: 1,773 times \| Joined on Aug 2009 @ Budapest, Hungary	#32

Originally Posted by Jaffa

Would the Open Media Player want to be installable alongside the original one?

If it was designed to replace it, would the main package in Extras depend on community-ssu-enabler?

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?

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

__________________
You should follow me on Twitter!

Apps: Puzzle Master, IRC Chatter for Harmattan, IRC for Sailfish

The Following 3 Users Say Thank You to Venemo For This Useful Post:
Jaffa, OVK, tswindell

jonwil	2011-01-14 , 12:21
Posts: 567 \| Thanked: 2,965 times \| Joined on Oct 2009	#33

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)?

The Following 3 Users Say Thank You to jonwil For This Useful Post:
Jaffa, joerg_rw, OVK

	Jaffa	2011-01-14 , 12:50
	Posts: 2,535 \| Thanked: 6,681 times \| Joined on Mar 2008 @ UK	#34

Originally Posted by jonwil

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)?

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

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

That's a much better policy question :-)

__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org

The Following 3 Users Say Thank You to Jaffa For This Useful Post:
joerg_rw, Mentalist Traceur, OVK

TiagoTiago	2011-01-14 , 23:31
Posts: 1,522 \| Thanked: 392 times \| Joined on Jul 2010 @ São Paulo, Brazil	#35

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

__________________
NOKIA N900: IT'S OVER NINE THOUSAND

How to use HotspotShield in the N900
Google Voice from outside the US + Free international calls: LEARN HOW HERE!!!

Last edited by TiagoTiago; 2011-01-14 at 23:34.

The Following User Says Thank You to TiagoTiago For This Useful Post:
joerg_rw

Mentalist Traceur	2011-01-14 , 23:54
Posts: 2,225 \| Thanked: 3,822 times \| Joined on Jun 2010 @ Florida	#36

Originally Posted by Jaffa

Would the Open Media Player want to be installable alongside the original one?

If it was designed to replace it, would the main package in Extras depend on community-ssu-enabler?

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?

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.

The Following 2 Users Say Thank You to Mentalist Traceur For This Useful Post:
j.s, joerg_rw

	Viqsi	2011-01-17 , 02:15
	Posts: 115 \| Thanked: 136 times \| Joined on Mar 2008 @ Central Ohio	#37

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.

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.

Last edited by Viqsi; 2011-01-17 at 02:19. Reason: can never remember which forums are ok with HTML and which aren't, grar

The Following 6 Users Say Thank You to Viqsi For This Useful Post:
j.s, Jaffa, joerg_rw, lsolano, Mentalist Traceur, sixwheeledbeast

	Jaffa	2011-01-18 , 09:42
	Posts: 2,535 \| Thanked: 6,681 times \| Joined on Mar 2008 @ UK	#38

Originally Posted by Jaffa

I've put that list on the wiki, but wikis are bad places to have discussions. I'd suggest one of maemo-developers, maemo-community or talk.maemo.org would be best.

I've added a new one:

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

__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org

The Following User Says Thank You to Jaffa For This Useful Post:
OVK

gazza_d	2011-01-18 , 12:40
Posts: 961 \| Thanked: 565 times \| Joined on Jul 2007 @ Tyneside, North East England	#39

Originally Posted by Jaffa

As you'll know that a lot of discussion happened in the thread "Fremantle Community SSU" on maemo-developers (a better home for in-depth technical discussion about the vagaries of HAM), which you participated in. Many of your questions then were about policy - and, as stated above, this hasn't yet been discussed (let alone decided).

OTTOMH, some of the big policy questions to be decided are:

Who ultimately owns the CSSU?
Council?

How will included improvements be decided? (Matan)
Will there be an inclusive policy - every improvement that someone is willing to work on will be included - or will there be a gatekeeper that will decide what to include? (Matan)

Is the scope limited to improving packages which are included by Nokia in the OS; or should it grow to include "useful" stuff?

Should wholesale replacement of apps (such as Media Player) be done with open source, feature- & UI-compatible versions; if available?

How will testing be organised?
Positive

Negative

Regression

Installation from scratch

Upgrade from previous version

How will it be advertised?

How will it be supported?
Bugzilla

IRC?

Forum

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.

__________________
______________________________

Nokia 770 (2gb) since Aug 2007
Nokia N800 (32gb) since Dec 2007
Nokia N810 (16gb) since Sep 2009
Nokia N900 (64gb) since Aug 2010 ______________________________

The Following 4 Users Say Thank You to gazza_d For This Useful Post:
Jaffa, OVK, Texrat, vkv.raju

gazza_d	2011-01-18 , 12:43
Posts: 961 \| Thanked: 565 times \| Joined on Jul 2007 @ Tyneside, North East England	#40

Originally Posted by Jaffa

I've added a new one:

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

from the bug report page...

> Internal bug is closed as WONTFIX for Maemo5 - reflecting state here.

However it is included in the Community SSU
(http://gitorious.org/community-ssu), however Mohammad hasn't merged in the
updated Modest into that project yet.

At what point do we change this to RESOLVED FIXED?

* Now?
* When the CSSU "officially" includes Modest in its project?
* When the CSSU launches for widespread testing?
* When the CSSU launches for end-users?
* Never?

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

The Following User Says Thank You to gazza_d For This Useful Post:
Jaffa

Page 4 of 544

Active Topics

Is there a section to talk about Java ME? Apps, etc. (6)