This thread is part of the Maemo Brainstorm 2010

What can be improved in the packaging & testing processes and interfaces for Maemo application developers?

Propose your ideas and suggestions here, let's talk about it, and summarise the best ideas and conclusions in the Brainstorm 2010/Packages wiki page

As we're getting more and more devices, I think that it should be made as easy as possible for developers to support older hardware as well as the latest batch. What can we do to help make testing and deployment as easy as possible to all applicable Maemo/Meego devices?

Since the average active Maemo developers will become an active MeeGo developer soon, it would be good to have the testing and publishing processes aligned.

What about taking as a benchmark the use case of an application developer using the Qt SDK and OBS to go from source code to packages ready for Maemo 5, MeeGo (rpm) and Harmattan (deb). Then having a simple way to publish the packages in the channels where the users are.

Solving this default use case will help solving all the alternate cases. Concentrating on a specific alternate use case while not addressing this one looks like a more troublesome path. The driver of the use case propose is the MeeGo project. Maemo contributors interested could just join the discussion and work there, making sure the maemo.org implementation is consistent with this plan.

Packages already supports multiple repositories / OS versions, so I think the next good step would be to hook it up with OBS to make builds for also MeeGo.

Last week we made some significant improvements to the Open Collaboration Services APIs that Packages provides, so making third-party application catalogues and other interesting stuff based on those should be very easy very soon.

Documentation link please, or it didn't happen.

Local, local, local. If you cannot reproduce whatever magic OBS does _without_ registering an account somewhere on the WWW, I'd say failure

(and yes this includes the magic autobuilder is currently doing with regards to deps :P but at least I've tried to document how to switch a local scratchbox setup...)

As soon as the changes go live.

Well, AFAIK Qt SDK allows you to compile for Maemo locally. But Packages is more than just building stuff... it is also about the QA process, and about distributing stuff to devices using the App Downloads client.

As for quality: I don't know where the hook for such a mechanism would be in the current and future build infrastructure, but I think there's room for an automated "How to further improve your package" section that developers get to see as early is possible, even in -testing.

It may include hints like:

• We noticed you use *po files for Italian and German. The N900 currently also supports French, Spanish, <add official languages here>. You may want to actively use community resources like talk.maemo.org or transifex.net to add more languages to your project. More here: wiki-link
• We noticed the package description field is only one line of text. This may be enough for very simple applications, but please consider making it more verbose and clear for end users.
• We noticed that the package description field you provide is in English only. The N900 currently also supports French, Spanish, <add official languages here>. You may want to actively use community resources like talk.maemo.org or transifex.net to translate descriptions to all of these languages. More here: wiki-link

In an ideal world, the flipside of this mechanism would feed a new portal called "Where can I help" that allows end-users to provide non-technical input to such projects without having to activate -devel or -testing at all.

I noticed, that last month i got time outs on certain repos, and i don't want to discuss which fault it is(server, nokia's or whatever) i would like to make some mirrors. it will help to get rid of traffic on same server and to have faster connection(as server can be even in your town). a lot of gnu/linux or unix-like distors have those and i think a lot of servers would be happy to help us(some institutes or companies like google that love opensource). For now i think it would be nice to have only packages and needed for installation files on that servers, and all the info about packages on main server. and if for example the mirror you selected(in package manager preference) doesn't have needed file it would try to download from main one. I know i'm not that good in explanation so i'll give an example. i use gentoo. and i sync portage with main server (gentoo.org) but all packages i install are from Israel(i live here) server. Israel server get all the packages from main one once a day. and if i'm trying to install something that is not on israel server yet, it tries to get from main one. also there is option to sync with portage itself with israel server, but as i said before i think it's not healthy as some critical things can be fixed in the same day and you would be able to get them only after local server update.

second thing i would like to have is not thousand repos like extra-dev, extar-testing and so on. as we understand it's the same server, so why just don't make it same repo but mask packages as extra-dev, extra-testing and so on. so if you wouldn't check the this package type in preference the appmanager would just ignore it.

p.s. i think it's connected to maemo community and brainstorm and if i'm wrong - i'm sorry.