Re: Many tested apps in Extras-testing are not promoted timely
 

There are two cases where a maintainer cannot promote a package because it depends on a not yet promoted user package.
eSpeak GUI Client 0.1-5 has 19 Karma but it depends on espeak-extra-data.
FCamera 0.1.3-1 has 12 Karma but it depends on fcam-drivers.
The second might show a bug, since fcam-drivers has 3 super tester votes but is not unlocked for promotion.

How can this be more clear for testers?

Re: Many tested apps in Extras-testing are not promoted timely
 

This isn't a bug - Current policy is that the three supertester votes will only unlock a package for promotion after 20 days, rather than the normal 10. The idea is that the three supertester votes unlocking a package are a last resort to prevent a not-very-popular package being locked in testing forever, it's not aimed as a replacement to getting 10 votes.

Generally speaking, dependencies should be non-user packages so that theyre promoted automatically when the user package is promoted.

In cases where the developer for one reason or another has a dependency that's also a user package so needs separate voting however, I see two potential solutions:
On the ad-hoc side, maintainers may wish to simply add into their descriptions or version notes somewhere that the package depends on another user package, so that once it's been tested, the tester can then also appropriately vote for the dependency, which they've also implicitly tested.
Alternatively, a change to the package interface could be in order so that any vote for a package also chalks up a vote automatically for any dependency that's also a user package - In this case, 10 votes for the original application will also register as 10 votes for the dependency. That's probably not a trivial change to the package interface, though.

Re: Many tested apps in Extras-testing are not promoted timely
 

Hm, quite torn among the suggested solutions... I'd prefer some combo, like 10 days after unlock supertesters can promote. I don't think it's feasible to get people to re-vote (I guess if you said it's good in the first place then it's a yes). OTOH I'm not a great fan of auto-promotion, maybe the author wants to synchronize a release with another package, a blog post, talk thread, etc.

Re: Many tested apps in Extras-testing are not promoted timely
 

The great thing is that you took the effort to explain this. It is exactly what is needed, we are human, we can be reasoned with, the goal of testing is not a race who can fail more apps. As said, I just skimmed over and skipped the package (as explained, lack of hardware), but did not give it as much thought as now when we have this issue on the table. I can now say OK, I understand what's going on and take a look and thumb it exactly because of this special consideration - that's why we have multiple votes required - sometimes the QA rules don't give a clear yes-no outcome in all contexts and that's why in those cases we need a majority vote. Reading back, I realize I'm quite confusing, I hope people at least get the gist of what I'm saying :)

I hope Ovi folks don't take this the wrong way, but we have standards :)

Lack of patience ? :) It's best for him to explain, but the point is that some people might disagree with the QA process - and that's OK as in we're not the thought police. One of the reasons we got a carte blanche for Extras, including being enabled on end-user devices by default on Maemo 5 (as opposed to Maemo 4.x) is exactly the effort we put in to make sure people don't get super-raw software that is plain broken. If you don't agree with the Extras terms, and do not wish to cooperate in working on it, improving it - you certainly are free to operate your repository (but then you don't get the Extras promotion and maemo.org infrastructure support).

Actually this idea has surfaced several tiems, and I even lobbied for a QA tester position in the maemo.org team, but our budget has been cut and we're struggling as is to rise above the level of pure maintenance mode. :(

Re: Many tested apps in Extras-testing are not promoted timely
 

Yes, I guess I understand what you have tried to say. And it's exactly my opinion.
My rant was not against the system. It was against the lazy users and how the system is sometimes handled. Especially the functionality testing has sometimes a to high weight. In my opinion you can do a full feature/bug check only with simple software. But, we don't own a Device from Apple. :)
And how long will you run the functionality test at a software like KOffice?

The functionality check happens mostly at extra-devel. If a developer has enought good feedback and he has considered to promote the package to testing the fundamental functionality should already work.

Personally I miss this standards at ovi. But perhaps it's only my own opinion. ;)

Ouh, I'm sorry. I'm not a native speaker. I didn't mean it like that.

Let my correct my sentence:

Conclusion: I like more the Idea to let a professional, skilled tester look for problems with my application without the possibility of a 100% functionality test instead of forcing 9 clueless community members to vote for my package and in the end to promote it, with my final (own) 10th vote, to extras.

I wouldn't ask for a paid tester. Sorry. :)

What I tried to say is: In my opinion it is dangerous to ask all the time the users of your own application to vote for your package. They are attached to the developer because they want updates and more features. "Could you do me a favor? - Yes, of course. I like your work." And in my opinion the risk is very high to get this way votes from total noobs and in the end a low quality package promoted to extras.

What about to create a rule that a package in testing needs at least at minimum a single positive vote from a senior tester additionally to the other votes from the normal users?

Re: Many tested apps in Extras-testing are not promoted timely
 

The auto-promotion should be a check box the author can activate if he wants to. But I think the reminder email solution would be something that is easy to implement and would catch a good amount of the forgotten packages.

Re: Many tested apps in Extras-testing are not promoted timely
 

As I learned he rule is 3 positive super tester votes and at least 20 days in Extras-testing promotion is unlocked.
Did you inform anyone about this error?

Re: Many tested apps in Extras-testing are not promoted timely
 

While somehow off-topic, here's a thought to help the extras-testing procedure:

Whenever a new version of a package is uploaded, send an e-mail to users that voted a previous version and ask them to test and vote again:

Here is what I think:

• I vote for a program (yes or no)
• A new version comes out
• I receive an e-mail that notifies me of the new version and asks me to evaluate it and vote it.
• (perhaps) after a couple of days, I receive another mail asking me to vote for this package (in case I forgot - a couple of days should be enough for testing it)

The method could use two user options:

• An option per user, per package, where each user can ask not to be notified about new package versions.
• An option per user, indicating that he is willing to test new apps.

The first option can be a new per-package in extras-testing option "Notify me for new releases" which would be auto-enabled whenever I vote for it.

The second option can be omitted and be considered as implicit since (in theory) whoever votes for an application in extras-testing is testing it.

This will also help in cases where someone thumbs-down an application and removes it. Currently he will not find out of a newer release.

From the user's POV, this method would be like a list of all packages that she evaluated.
From the developer's POV, this will be like sending e-mail to all previous voters.