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.