Reply
Thread Tools
VDVsx's Avatar
Posts: 1,070 | Thanked: 1,604 times | Joined on Sep 2008 @ Helsinki
#41
Originally Posted by X-Fade View Post
A list of voters is shown in the details page, so you can see who voted. This makes it easier to spot if somebody is creating a lot of accounts.

How about this:

The application needs to have > 10 karma, of which at least 3 positive votes of (people with karma > 100 OR people in specially created community testers group)

We could create a community testers group where we add people who have a proven track record within the maemo.org community?
Agree, some kind of grandfathering is needed here, IMO

Also notice that a app can be voted by 10 users, that can't see/evaluate a security flaw for e.g. Some distinctions between the voters/vote should be also considered.
__________________
Valério Valério
www.valeriovalerio.org
 
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#42
Originally Posted by lma View Post
["questionable" content]Hm, a can of worms that one. I'd prefer we never saw those kinds of apps personally, but I would like arbitrary censorship even less. I guess ultimately Nokia would be legally responsible for whatever is published, so we should go with whatever Finnish law allows.
If there is a subjective test about whether the app is "questionable" there should be a clearly published guide for authors and testers. The last thing we need is an iTunes App Store-style debacle over rejected apps and long delays[1].

What about if there was a separate item: vote up/down & report questionable content. This is a "I've evaluated this and I want someone else to make the call". That can be a separate group of high karma owners, the council, Nokia, whomever.

The default position should be open, so if it's just sexually explicit, rude, violent etc. Fine. Stuff can be objectionable but that doesn't mean it shouldn't get through.

(I assume that content refers to what is present in the packages themselves, rather than content that could potentially be accessed by the application, so it wouldn't apply for example to an email client that could at some point receive a v!@gra spam containing dubious images).
Hear hear.

[1] Scalability of this process being the other thing to contemplate as we hope the Maemo 5 lead device launch will lead to a mass of new users, developers and applications.
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 

The Following 4 Users Say Thank You to Jaffa For This Useful Post:
Posts: 152 | Thanked: 620 times | Joined on Mar 2008 @ Netherlands
#43
Originally Posted by qgil View Post
But does a thumb down mean that it should go back to extras-devel? Or just stay in extras-testing? How do we tell "still not ready for Extras but don't send it back to extras-devel"?
When a package doesn't meet the promotion criteria, the package should be removed from the queue and from extras-testing. The package will still be available through extras-devel though.

What shall we do when a developer promotes a newer version of a package which is still waiting in the QA queue? Shall I automatically drop the 'older' package from the queue and allow the new version in?

I don't think it makes sense for people to still test an older version when there is a newer version available already?
__________________
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
 
GeneralAntilles's Avatar
Posts: 5,478 | Thanked: 5,222 times | Joined on Jan 2006 @ St. Petersburg, FL
#44
Originally Posted by X-Fade View Post
What shall we do when a developer promotes a newer version of a package which is still waiting in the QA queue? Shall I automatically drop the 'older' package from the queue and allow the new version in?
I'd say drop the older version, then send the new package into some sort of administrative approval situation where an admin will be required to examine the update and confer with the maintainer before the package can be promoted (as opposed to resetting the votes entirely).

Can we detect that an uploaded package is an update to a package in the queue and require the uploaded to enter a paragraph or so explaining the update?
__________________
Ryan Abel
 
Posts: 1,208 | Thanked: 1,028 times | Joined on Oct 2007
#45
Originally Posted by GeneralAntilles View Post
Can we detect that an uploaded package is an update to a package in the queue and require the uploaded to enter a paragraph or so explaining the update?
There's a debian/changelog, no need to duplicate things
 

The Following User Says Thank You to mikkov For This Useful Post:
Texrat's Avatar
Posts: 11,700 | Thanked: 10,045 times | Joined on Jun 2006 @ North Texas, USA
#46
Could this be enhanced as well?

Welcome to the package management interface. This interface can be used by developers to promote their package to another repository. Community testers can use it to test packages waiting in the QA queue and give feedback.
"another repository" is vague. Could the available respositories be listed in parentheses? Such as:

Welcome to the package management interface. This interface can be used by developers to promote their package to another repository (repo1, repo2, repo3). Community testers can use it to test packages waiting in the QA queue and give feedback.
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
 
qgil's Avatar
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#47
Originally Posted by X-Fade View Post
When a package doesn't meet the promotion criteria, the package should be removed from the queue and from extras-testing. The package will still be available through extras-devel though.
Really? I thought this process to be like in Debian, where an app in testing might not make it to stable yet, but won't be demoted to unstable if it has a 'testing' quality.

In practice this might make life of testers easiers, having extras-testing activated in their devices but not extras-devel, and till having somewhat functional devices themselves, avoiding to see apps disappearing when they update.

Therefore a package would disappear from extras-testing only when a more recent version substitutes it? Unless the package is so buggy that must go back to devel.

I think a new version would reset the evaluation of a previous version no matter what. This makes developers prepare better their releases, saving not onle extra evaluations of minimal changes but most importantly saving downloads and updates of minimal changes to end users.
 

The Following 2 Users Say Thank You to qgil For This Useful Post:
GeneralAntilles's Avatar
Posts: 5,478 | Thanked: 5,222 times | Joined on Jan 2006 @ St. Petersburg, FL
#48
Originally Posted by qgil View Post
I think a new version would reset the evaluation of a previous version no matter what. This makes developers prepare better their releases, saving not onle extra evaluations of minimal changes but most importantly saving downloads and updates of minimal changes to end users.
That also increases the barrier to entry more, though, which may be something we want to avoid at this stage. Especially with the large influx of new-to-the-platform developers who may miss some of the smaller Maemo-isms when they're packaging and may need to ship some small updates to correct that.

Perhaps a policy we should look to enforce farther down the road, but maybe not for the first 6 months or so?
__________________
Ryan Abel
 
qgil's Avatar
Posts: 3,105 | Thanked: 11,088 times | Joined on Jul 2007 @ Mountain View (CA, USA)
#49
I'm just trying to emulate mentally the situation:

2009-09-01: Developer promoted App v1.0 to extras-testing
2009-09-05: App v1.0 has got only 5 positive votes. Mixed feedback. Waiting.
2009-09-06: Developer promotes v1.1 with changelog, based on feedback received.

GA scenario (correct me if I misunderstood it):

One admin needs to look at the update and decide whether the 5 votes are still good or new review is needed? looks like a confusing situation with many possible variants

qgil scenario:

Counter resets. v1.0 is forgotten and v1.1 is now under review. The 5 voters look the changelog and check the app only to confirm their previous +1. Others can now check that the issues are addressed and vote. If v1.1 is good it will go to Extras in 10 days.

If the developer doesn't want to stop v1.0 because it looks like it will gather enough support within the first 10 days then he can just keep polishing v1.1 and release it once v1.0 has made it to extras. We are talking about only 10 days between stable releases! That is already fast compared to anything you regularly see even in the Linux desktop.

And just like it happens in the Linux Desktop, if power users want to get the fresh meat sooner and more often they can always decide to move to -testing or -devel. But it's good that average end users are kept away from so frequent updates. Specially considering that such fast iterations carry always a risk of regressions.
 

The Following 3 Users Say Thank You to qgil For This Useful Post:
Jaffa's Avatar
Posts: 2,535 | Thanked: 6,681 times | Joined on Mar 2008 @ UK
#50
Yeah, I think the "human intervention required" step suggested by GA isn't very scalable.

How about:
  1. New version gets promoted to extras-testing whilst there is already one there: its votes get halfed and any super-votes required removed.
  2. 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).
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
 
Reply

Tags
extras-testing


 
Forum Jump


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