Reply
Thread Tools
Posts: 159 | Thanked: 122 times | Joined on Nov 2009
#31
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?
 
Posts: 278 | Thanked: 303 times | Joined on Feb 2010 @ Norwich, UK
#32
Originally Posted by hschmitt View Post
The second might show a bug, since fcam-drivers has 3 super tester votes but is not unlocked for promotion.
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.

Originally Posted by hschmitt View Post
How can this be more clear for testers?
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.
 

The Following 5 Users Say Thank You to nidO For This Useful Post:
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#33
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.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following User Says Thank You to attila77 For This Useful Post:
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#34
Originally Posted by helex View Post
Sometimes the functional test is in its entirety not possible. Sometimes it could be enought to test the starting of a app, is the setting screen working, are the data properly stored, are there no privacy problems and the QA system has to trust that the rest of the app works. In my case it is only a small part untestable. If you don't have such a special kind of receiver at the other end of your network connection you got simply a red dot at the network info symbol instead of a green one. Thats all.
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

The ovi store makes no kind of functionality testing: Cube Touch! And I'm sure the other, dangerous, criteria are also handled in a lax way.
I hope Ovi folks don't take this the wrong way, but we have standards

What is the reason for Khertan to not longer upload his great applications to extras? (I used his pygtkeditor a lot during my development)
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).

EDIT:
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.
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.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following User Says Thank You to attila77 For This Useful Post:
helex's Avatar
Posts: 543 | Thanked: 802 times | Joined on Apr 2010 @ Germany
#35
Originally Posted by attila77 View Post
Reading back, I realize I'm quite confusing, I hope people at least get the gist of what I'm saying
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.

Originally Posted by attila77 View Post
I hope Ovi folks don't take this the wrong way, but we have standards
Personally I miss this standards at ovi. But perhaps it's only my own opinion.

Originally Posted by attila77 View Post
Originally Posted by helex View Post
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.
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.
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?
__________________
I was a Qt Ambassador!

Please DONATE if you like my work!
It's the best way to motivate me to create more stuff for your Device.

Last edited by helex; 2010-08-03 at 00:48.
 
Posts: 159 | Thanked: 122 times | Joined on Nov 2009
#36
Originally Posted by attila77 View Post
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.
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.
 

The Following User Says Thank You to hschmitt For This Useful Post:
Posts: 159 | Thanked: 122 times | Joined on Nov 2009
#37
Originally Posted by epage View Post
<snip>
EDIT: Small correction: I got the promotion email at below 10 thumbs up and it error'ed when promoting. Unsure which part was the bug (since there had been talk at one point of super-testers bypassing the 10 vote rule) but never got around to filing it. I then didn't know when I hit 10 votes and could promote.
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?
 
Posts: 376 | Thanked: 511 times | Joined on Aug 2009 @ Greece
#38
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.
 

The Following 2 Users Say Thank You to v13 For This Useful Post:
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 12:20.