Thread: The initial focus of Mer
View Single Post
Stskeeps's Avatar
Stskeeps is offline Stskeeps
2009-08-21 , 23:06
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#2
Originally Posted by Tomaszd View Post
My main concern is feature parity with Diablo. I don't want history to repeat itself. Let me explain.
I'll just begin with saying I do agree with everything you say, so what this is, is just added information to get a full picture.

Having full hardware support, few apps and a bare interface is much better than the opposite situation. A lot more people can get involved, to develop apps for it and test it. Hardware support is really low-level stuff that few people understand. Reporting bugs of a media player is easy, but not being able to actually use a media player and thus not have any bugs to report is a shame.
There's however also a danger to this approach - see OpenMoko & the Freerunner. A lot of the focus has been to make the hardware play right. And frankly, most of the interfaces i've used on my Freerunner made me want to throw the phone across the room in a raging fit. People have difficulties using the interfaces - the interfaces feel like demos on top of raw APIs.

What we -do- try is to work separately on hardware support for different devices and on the core system.

However, if we do yet another distribution just for N8x0, we would quickly be irrelevant as a project. Hence why we spend time embracing the core of the system. Which often takes resources from HW support. We're a limited set of skills still.

I used to be involved in another project (won't name names), which also aimed at being a replacement of a well estabilished, commercial one. Unfortunately, the developers were not interested in getting feature-parity first, they were only interested in experimentation and technology previews that eventually went nowhere and have been discarded or simply abandoned.

Eventually people who were testing this product got frustrated, and rightfully so. The product couldn't have been used full time, because the essential, basic needs were not met. No-one wanted to test the product's superfeatures, because it was just painful. Every time they complained the developers would jump out with another experiment, and people would eat it up. This went on for years. Eventually everyone lost faith, it was clear the project would never achieve its goals.
This story should be told often to many open source projects.

This little anecdote is an attempt to draw some parallels with Mer to avoid such a dismal situation.
And I thank you for bringing it in.

We need sound working perfectly and out of the box on the NITs, so that people actually use Mer for more than five seconds. Mer shouldn't be degraded to just another toy.

Currently, enabling sound is a painful process and sound works rather terribly. I refuse to "eat my own dogfood", because I'm not going to use a crippled system.

We need the GPS to work out of the box on the NITs, instead of a huge wiki page with instructions on how to enable it. With GPS we can then port Maemo Mapper, Carman and other cool Maemo applications that would attract users.
This is blocked mostly by the fact we have to set up the logistics of providing GPS driver and DSP tasks for sound legally to users. And provide images for these. Yes, we can make it work at this moment with potentially illegal methods but I'd rather be safe than sorry in this matter.

These logistics is actually one of my tasks this month in maemo.org sprints - to establish a set of tasks for maemo.org employees to push through, what Mer needs to do. And the reason we don't have it yet, is my own fault - I have had to take care of a bunch of personal issues so Mer didn't harm my personal life

Regarding GPS, it's not as easy as you might think .. as Mer is Fremantle code and runs Fremantle API, and Maemo Mapper uses libgpsmgr/libgpsbt which is a leftover from Diablo .. We need open implementation of liblocation-dev to make this happen. And make Maemo Mapper use this.

We obviously need to support the LEDs, the light sensor and the camera as well. And have an event manager to handle things like popping the camera out on the N800 or sliding out the keyboard on the N810 (+handle its backlight).
Agreed, which lbt is now working on. Finally someone took the task to do it. LEDs are actually already supported but noone wrote a open set of LED signals (.. mce.ini).

Also, we should not ship with showstopping bugs which
prevent Mer from booting randomly.
There's good and bad sides to firmly set deadlines for release. One is that we won't spend 3 years like Enlightenment to get things right. The other is that we have fresh snapshots to test, develop and such on. But this also means crap will come out once in a while. At least we're tracking the issues. I once ran a release that took two years to finish. But damn, it was solid. But users started using our betas very early - which was a problem since we were still developing it.

Then, only then can we focus on software, on porting more apps, on sprucing up the interface. Mer is going to be just an irrelevant toy if we don't get these things done, no matter how beautiful we make it with those fvwm scripts.
FVWM is really not for beauty, but for a need - to get rid of hildon-desktop 2.0.19, which is actually responsible for many of the bugs you experience :/

Again, thanks for the discussion. This is a open project after all, so any constructive criticism is always welcome. My advice is: Write up a list of 10 things that you believe should be fixed. That helps us plan through seeing what -you- think is madly wrong.
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 26 Users Say Thank You to Stskeeps For This Useful Post: