I recognize the hard work done. But if that is the case, promotion interface is not ready for the prime time. Developers must not be forced to use it in order to get their applications into Fremantle devices. (If you make the ecosystem too complicated and hostile for developers, it will not attract them.)

Not again, please.

The description may be bad, but the main issue lies in Hildon Application manager.

Microfeed is a metapackage that depends on libraries, providers and utilities of the Microfeed backend. It is provided for convenience to enable users to update the backend separately from applications utilizing it.

The Microfeed backend is utilized, for example, by Mauku 2.0 and Mauku Widget and hopefully also other applications in the future. So, there are more than one application that depends on the backend.

New providers ("drivers" that provides access to different web services), for example, can be added by just adding a new provider into the Microfeed backend. An application does not need know anything about that addition.

Now, let's imagine that one has added Facebook provider into Microfeed backend. If there was no backend package in the user/* category, how an user could update the backend to gain that improvement? He could not, because the Hildon Application Manager does not inform or allow the update of non-user/* category packages.

Thus, there is the microfeed metapackage visible in the user/* category that can be used to bump up versions of the backend packages.

Got it? If not, please, consider at least twice before suggesting that application packages must be updated to depend on the new version of the backend. It is not an option, because a) applications has nothing to do with it, b) application packages can be huge (graphics, media etc.) and user does not want to download those again and again every time some other package has been updated, and c) application packages may not be under the control of the backend library developers.

So, if you want to hide these kind of packages, Hildon Application Manager should be fixed. One possibility would be that there was a new category between user/* and non-user/* categories. Let's say, support/* category. Applications in that category would not be visible in the list of installable applications, but appear in the list of upgradeable packages when updated.

OK, sorry didn't know this (and this much of explanation would have been enough). Changing the description closer to your paragraph above would actually be good description for the package.

I'm sure that at some point Application Manager is going to cause a major headache for example to python maintainers.

I might be wrong but... if a user has a package from Extras installed and a new version is published... won't the Application Manager call for an update no matter whether such package is in user/ or not?

If you install a non user/* application, you have either done it through red-pill mode or apt-get. I think red-pill will warn you.

Regular users don't install non user/* applications probably, so there is reason to Henrik's madness Now I have taken a closer look and evaluated all the options, I agree with him that this is the best solution for now. How inelegant it might be.

This promotion part is to be considered beta, just like the SDK. I run promotions manually to be sure I didn't make a mistake and pull in the complete 1000 package extras-devel tree for example.

Once testing has completed, promotion will be almost instant. I expect this to be there soon.

Please keep in mind that we're not here to make things more difficult for you, we try to give the end user a better experience. This makes it a bit harder for developers at the moment, but will make for a better product in the long run.

Small clarification: End users do install non-user/* packages, but only if those are dependencies of user/* packages. They do that without knowing they have done it. (And thus, the category between non-user/* and user/* packages in terms of HAM visibility could potentially be confusing, I do not know.)

And big thanks for trying to solve this. I am sure there are also other packages that may benefit from the solution. (As mikkov already mentioned Python packages, for example.)

I think that idea for separate extras-testing repo is very good but it will be always a long process to get a new version of package in the extras...if there is everytime 10 days quarantine etc. before getting from extras-testing to extras? Or does this apply to only new applications getting extras for the first time?

I´m just found a problem with the automatic promotion of the dependencies. I´m not sure if this is my problem or something general...
I promoted Conboy 0.5.3 to testing. Conboy depends on libjson-glib. So libjson-glib-1.0-0 0.6.2-5 was also promoted to testing.
Now for some reason libjson-glib-dev 0.6.2-5 reports a missing dependency on the promoted lib.

Before the promotion the dependencies were ok. Also all files are still in extras-devel, so there shouldn´t be a problem finding them?!

Is there something I can do about? Also in the latest version (0.6.2-6) I changed the maintainer (should be me now) that I get the reports concerning wrong packaging, but the package web interface still shows 'Emmanuele Bassi' as the maintainer. He´s the author and was in the maintainer field earlier...

Thanks!

I dont think this will be a problem in practice.

How often do regular apps release updates to their users? You can have your very minor releases for those in "unstable" but then prepare a public release when it actually makes sense.

Probably with due time we can work on a "reputation track" system based on app karma and good quality of past submissions. Imagine that eCoach has got 5 fremantle releases to Extras, all impecable and users love the app. Well, it makes sense to have a positive pre-judice to a 6th eCoach release, somehow.