Your cart is currently empty!
Maemo Application repository – A suggestion
One of the things which I like about Maemo is the way they arrange an application repository structure go with a development cycle of an app.
Rather than simply writing something, and making it available in an appstore when you’ve made it ‘perfect’ there is a tiered structure.
The structure has 3 layers, at the top there is ‘extras’ this is the main application repository, it comes enabled by default, and can be considered similar to an appstore (except the apps are all free) The things here are finished or at least considered to be consumer ready applications.
Beneath this there is extras-testing, and below that extras-devel. It’s a sensible idea, as a developer the first thing you can do is submit your application to extras-devel, from here you can try installing the app through the real mechanism, check that things are basically working and generally use it as a staging ground to try new things.
Once happy with a version of your app, you get the chance to ‘promote’ the application from the development repository to the testing repository. The community is encouraged to get involved with apps from the testing repository, and provide feedback to the developer about any bugs found. The community gets to vote on versions in the testing repository to show whether they think the app is basically ready for general availability in the extras repository. The rules around this are that the app is stable, does as it claims to, and all the relevant info is provided, such as a bug tracker where people can raise defects. This does not mean the app is *good* just that it works as described with no nasty side effects.
I really like this idea, and as a developer can see the value beyond just being left to make an application available to everyone with no differentiation of stable/finished versus unstable in development.
However, there is a gaping flaw in the way this is all implemented on the device.
Most people, shortly after getting the phone, find out that a bunch of cool apps exist in extras-testing, that aren’t in extras yet. They accept the warnings and go enable it.
Then they realise that all the bleeding edge cool on one particular app they love is in extras-devel. They ignore the severe warnings about the potential to brick their device and enable extras-devel to install the latest of their beloved app. And it’s great! this app works just fine in devel and they get the newest features quickly. Before you know it they aren’t disabling the extras-devel repository any more.
But the application manager doesn’t really differentiate when showing updates, which repo they are from. Sure, you can find out, but it just shows a list of updates and an ‘update all’ button. So all those people just pick up the latest versions, forgetting that these are all from devel. They should just ‘remember’ to disable it again. However I think it would be nicer if there was a persistent visual indicator, and a much more obvious way to chose which apps you are prepared to update from which repository. The reality is that people don’t remember, so in the interests of usability I think there should be a better way.
I discussed this on twitter with @benjezzy who suggested a simple red/amber/green identifier to show which repository this update is from. I think something like that could work. What I’d really like is in the update panel to see what version I have right now, and which repository I installed it from, and which repository the upgrade is available in. Along with the option to say ‘notify when in extras’ or extras-testing etc. all per app. There are some apps I’m happy with, they do what I need, and I would be happy to just pick up mature changes from extras. There are others that are in early development, rapidly changing and marching towards being awesome, and I’d like to track that progress more closely picking up frequent updates. I guess it often boils down to the apps I use daily, I want stability. Those which are just cool toys, but less frequent use, I want to try every new update, and it won’t effect me too much if there are some backward steps.
Speaking for my self, and witter. I use devel to try stuff and get some valuable feedback from a hardcore few who (hopefully) don’t judge me too harshly when I break it, or introduce massive regressions. But every time I do this, I get comments from others who complain it’s just ‘stopped working’ or react as if they think a given change is final. I’d rather these people return to the safety of extras-testing, which I at least try not to break. I promote stuff here when it is in at least reasonable final form. I don’t want to turn off users with a feeling that witter is unstable, but I do want a place to let some people try early attempts before I get too far along implementing something.
Other more conscientious developers may deliver perfect updates to extras-devel, and just be frustrated by how long it takes them to push their awesome code through the system to extras, and I don’t want general users not to be able to get those updates quickly and easily. But they should be able to make this choice easily on a per app basis.
Of course Maemo is basically dead now, and the new meego taking it’s place. I’ve not played at all with meego, but assuming it will inherit some of these concepts, perhaps they can look to make some improvements here, I really think the tiered repository is a good idea (for developers like me) and with a few tweaks could avoid frustration from users getting instability they weren’t expecting, and developers getting complaints based on mismatched expectations.
To those that do live dangerously, and take the latest, half baked updated from Witter, and manage to provide constructive feedback. Thank you.
13 responses to “Maemo Application repository – A suggestion”
Getting a change into Application Manager (HAM), would be tricky. But achipa has started a project called “KISStester” which aims to show you a list of applications you have installed from Testing which you haven’t yet voted on, which haven’t yet got to Extras:
http://talk.maemo.org/showthread.php?t=60158
@Andrew: Tricky? Be serious: it’s never going to happen, because Like the OP said, Maemo is dead. Nokia has given up on fixing their broken software, and we all know MeeGo is never going to be well-enough supported on the N900 to be useful to average users. I don’t blame the Community Council for Nokia’s monumental failures, but really, why haven’t you guys resigned in protest yet? We all got shafted!
@OP: Your suggestion is good, but I think the QA process has other flaws as well. It makes sense for an app to go through the 10-day/10-vote routine once, but after an app is stable enough to have been promoted to extras, is it really beneficial to delay every single minor bugfix update for another 10 days?
A bit off topic, but has to do with the repositories, I think there is a need of a greater policing the repositories, as you find a lot of themes and localisations in quite many different groups (desktop and system), there should be more groups for applications, one for localisations and another one for themes.If we have some people would act as police and correct the location of applications, they maybe could also perform some sort of application testing and see to that the applications gets moved upwards in the repository hierarchy.
@anondev: I said “tricky”, because it’s perfectly possible for the community to push a new HAM to Extras (or a new community “Fremantle Updates”) repo in exactly the same way has been done for Diablo.
I’m not sure what the *Community* Council resigning would do with regards to Nokia’s *commercial* decisions about numbers of Fremantle updates or them pushing, as an official OS update, MeeGo (or MeeGo-Harmattan HE).
@Andrew, I was suggesting that the council members should resign in protest of Nokia’s planned obselescence model, and their complete failure to respond to the needs of the community. You should resign to send a message to Nokia. I (and many other longtime Maemo developers from whaat I hear) will be conveying our disapproval by not buying or developing for Nokia products any longer, but you are in an even better position to protest their unnacceptable practices.
Sorry for all the typos in that last comment. Typed it out quickly on my N900.
anondev is an Android shill spreading FUD. MeeGo is coming to the N900 as a dual boot option. If you want to help the process along vote MeeGo Bug 5136 – Multi boot option at least for N900 http://bit.ly/cNDEux.
Actually Dave, the N900 is my only phone, and I’ve never owned an Android device.
Obviously it will be possible to dual-boot Maemo 5 and some form of MeeGo (you can already install the unstable handset UX) but the fact is, Nokia has said they have no plans to make an official/end-user ready MeeGo release for N900.
Average users don’t know or care what dual-boot means – they just want a stable/usable phone. Maemo 5 development appears to have ceased (even though it’s still riddled with bugs) and it seems unlikely that MeeGo will ever be viable as a primary OS for N900 users without official support from Nokia.
I too own an N900 as my only phone and have been following the debate on maemo.org. Nokia have never stated that they are not providing the N900 with more updates and fixes. They have also not stated that it won’t get MeeGo. What they have said is that it will get a non-supported version of MeeGo. I have no problems with my N900 running Maemo that I haven’t found a community workaround for. Maemo is way more powerful than Android or iOS. They just had a headstart with more apps for now. I would rather Nokia spent time right now on the MeeGo phone and N8 than Maemo so as to ensure that a lot more Qt apps come to the N900. Qt makes the N900 future proof. I guess we all have our priorities.
Qt will make cross-platform development fairly easy, but my impression is that developers will still have to build separate versions of packages for MeeGo and Maemo 5 since they use different package management systems. By the time a MeeGo phone hits the market, most MeeGo devs won’t have an N900, and many won’t bother to build Maemo 5 versions of their apps, no matter how easy it may be.
Regardless of how many new apps are made for Maemo 5, Quim Gil has confirmed that the OS will be receiving just one more maintenance update and only critical bugs have a chance of being fixed. There are countless “minor” but still very annoying bugs I know of no workaround for, and it appears they will never get fixed. The OPs suggestion is a great idea, but it came too late since Nokia is long past the point of responding to enhancement requests. Maemo 5 is a dead-end platform, and without an officially supported MeeGo release N900 users have no real upgrade path.
I’ve been using Maemo since 2005 and I wanted to see it succeed as much as anyone, but Nokia has failed too many times for me to keep supporting them.
I’ve twice posted something on maemo.org/talk when witter isnt working but not because I wanted to be a critic or say it’s no good – quite the contrary, it is a great app and one of my favourites on N900. It’s just easier to post on Talk and get other peoples ideas and work arounds quickly. If I knew the correct way of logging errors/bugs I would be happy to post them in the right place. Maybe a link on the first post would help with this?
Hope you understand we are not dissing your app, or trying to make you feel bad – not at all, as we appreciate your work and are just trying to help get it working 100% by letting you know of any issues we find on the Dev version. 🙂
The idea of an identifier for updates coming from testing/dev would be very good, very informative.
All the best,
Ian
to be honest, it’s more the people i see tweeting compliants about #witter who don’t take the time to provide bugs through any mechanism. i don’t mid feedback, it’s just a shame that i believe some/many inadvertantly wind up picking up devel versions and forget that things will break.
[…] Would, developer behind the impressive Witter app for the N900, writes an in-depth article about what he thinks could be improved in the Application distribution system used on the […]