Yeah, I think the "human intervention required" step suggested by GA isn't very scalable.

How about:

1. Upgrades: New version gets promoted to extras-testing whilst there is already one there: its votes get halfed and any super-votes required removed.
2. Demotion: If an app requires X votes to promote from extras-testing to extras, receiving -kX votes will demote it from extras-testing to extras-devel. (Where k could be 1, I dunno).

In Diablo we have repository promotion as follows:

extras-devel -> copy package -> extras

In Fremantle we introduced Extras-testing, but this should not change the flow:

extras-devel -> copy package -> extras-testing -> copy package -> extras

The same unchanged package gets copied from one repository to the next. It doesn't get removed from the origin repository. (At least not until we do some cleanup run to remove anything older than the last 3 versions or so)

I think we all agree that 'rejected' packages should be removed from the testing queue (page). But would it also make sense to remove the package from the repository? It is a waste of effort for people to keep testing an already rejected package.

This whole QA part can be as elaborate as we want it to be, but basically we would already gain a lot by just determining if the application "works". If you take that concept forward, then it makes sense to view every package version uploaded as a completely different package.

It shouldn't inherit votes from a previous version. Votes represent the state it is in now. You can easily break an application with a small fix, even if your previous versions worked perfectly.

X-Fade has a point. If the resetting is too onerous, we could look at some kind of inheritance based on version numbers; but let's suck it and see?

In terms of removing packages from the extras-testing repository, I think so. I imagine a use-case might be something like:

1. User enables extras-testing
2. User browses through App Manager for interesting things to test
3. User installs one and then finds its QA page to vote on their experience

If they find a package, but no page, they may assume the package has come from Extras.

If a promotion for a package has been rejected, the page won't go away. It will display that the status of the package is 'Package promotion rejected' and it will not be listed in the QA queue.

I could add a promotion rejected list, if that would help.

Criteria for promotion to Extras drafted at
http://wiki.maemo.org/Extras-testing...n_.2F_Demotion based on the feeedback received in this thread.

* At least 10 days of quarantine
* Karma 10 or more (1 vote up = 1 karma point / 1 vote down = -4 karma points)
* At least 3 members of the testers group have voted.

(((what is the testers group needs to be defined, but they are meant to be senior and reliable contributors)))

Can someone please document the steps needed for a developer to promote their packages from extras-devel to extras-testing?

http://wiki.maemo.org/Extras-testing...extras-testing

We should widen the call to promote apps to extras-testing but it's better to do this once the steps are clearly documented.

Also, could you Niels/Jeremiah clean the xurrent extras-testing repo to make sure that the apps there are only the ones that the own developers have promoted?

With all this I can also make an internal call to those having a unit to test Maemo 5 apps and get involved in the earliest evaluation. Maybe we can even get some apps in Extras sooner than you think?

Please give me until tomorrow

I am working on removal at the moment and expect to have that done today.

There are still some apps waiting for promotion, but I didn't want to let them through to testing until I cleaned up the current version.

Once things are going through to Extras, should/will there be a "5" button added to maemo.org/downloads/ ?

Yes. It doesn't make sense to have it active before that as the download should point to Extras.

I'd still like this particular rule relaxed for security updates, assuming adequate testing has been done of course. It doesn't seem appropriate to hold those back for arbitrary reasons and let users still go on using the vulnerable versions in the meantime.