Editing Talk:Extras-testing/QA checklist

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

== What is unacceptable power usage? ==
*Waking the device from sleep every minute?
*Waking the device at all if not in foreground?

This is complicated. Maybe someone can define rules this way? For starters, I think is good to concentrate on user perceived issues: do you feel the battery lasts less time since you installed that widget? Then hopefully at least the top apps in terms of downloads should be tested using the right tools.--[[User:qgil|qgil]] 11:11, 23 October 2009 (UTC)

There are power tools available, just that their documentation isn't there yet.
The internal limits of waking up were pretty tight. But it really is about the type of application, if you want to wardrive for WLANs, then you accept the fact that your battery will be flat really fast.
At least widgets shouldn't do anything if not on screen.--[[User:tekojo|tekojo]] 20:02, 24 October 2009 (UTC)

== Security risks? ==
* Connecting to the net without a reason?
** The trick is to know when it's "without a reason" or even if it's the app who is creating the connection or something else. In any case these random or unrequested connections can be cause of a bug and might have an impact in power management and even financial loss, so it's good to ask about them.--[[User:qgil|qgil]] 11:11, 23 October 2009 (UTC)

* I'd rephrase "MUST NOT contain known security vulnerabilities" and  
"MUST specify a security vulnerability reporting contact point".
** This would take the ambiguity out of a security *risk* (almost nothing  
is risk-free). Vulnerabilities, however, are more tangible. There is,  
of course, still a class of vulnerabilities that could result in a  
debate, but much less so than when talking about risk.
** "Known" is also tricky - known by whom? - but it could suffice, as if  
anyone who is actually involved in this QA checking "knows", it would  
trigger this.
** The contact point would usually be an email address and perhaps an  
associated GPG key, but the bug tracker could also suffice if the  
project is really keen on full disclosure. --[[User:avs|avs]] 18:30, 28 October 2009 (UTC)

== Qt ==
* How about the criteria for Qt applications? Current Qt -> Maemo look is coming. That can't block the way.
** The toolkit is totally irrelevant in the QA process. As long as the app goes through the usual testing without blockers, it can go to Extras.--[[User:qgil|qgil]] 11:11, 23 October 2009 (UTC)
** What if testing finds an issue that is in Qt (or Python for that matter)? Can we trust that the underlying level is ok? 
** And if we can, it might make some parts of testing really simple, just check what parts of Qt the app uses and based on that skip most test cases.--[[User:tekojo|tekojo]] 20:07, 24 October 2009 (UTC)

== Checking root filesystem usage ==

Quick'n'dirty script:

<pre>
#!/bin/sh

if [ -z "$1" ]; then
        echo "Usage: $0 <packagename>"
        exit 1
fi

if dpkg -l $1 > /dev/null ; then
        NONOPT=$(dpkg -L $1 | egrep -v "^/(opt|home)" | while read path; do
                [ ! -e $path -o -d $path -o -L $path ] && continue
                echo "$path"
        done)
        [ -n "$NONOPT" ] && du -ck $NONOPT
fi
</pre>

== Bug tracker ==

XSBC-Bugtracker is a "blocker". However, many applications are often too trivial to make it worth the admin. There are three options:

# ''XSBC-Bugtracker: mailto:foo@example.com'' is a supported and encouraged solution.
# It is not a blocker.
# It is considered part of the spec that if ''XSBC-Bugtracker'' is missing, it is implicitly the maintainer's email address.

--[[User:jaffa|Jaffa]] 12:03, 26 October 2009 (UTC)

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Talk:Extras-testing/QA_checklist"

Personal tools

Navigation

Views

Editing Talk:Extras-testing/QA checklist

@@ Line 13: / Line 13: @@
 ** The trick is to know when it's "without a reason" or even if it's the app who is creating the connection or something else. In any case these random or unrequested connections can be cause of a bug and might have an impact in power management and even financial loss, so it's good to ask about them.--[[User:qgil|qgil]] 11:11, 23 October 2009 (UTC)
-* I'd rephrase "MUST NOT contain known security vulnerabilities" and "MUST specify a security vulnerability reporting contact point".
+* I'd rephrase "MUST NOT contain known security vulnerabilities" and
-** This would take the ambiguity out of a security *risk* (almost nothing is risk-free). Vulnerabilities, however, are more tangible. There is, of course, still a class of vulnerabilities that could result in a debate, but much less so than when talking about risk.
+"MUST specify a security vulnerability reporting contact point".
-** "Known" is also tricky - known by whom? - but it could suffice, as if anyone who is actually involved in this QA checking "knows", it would trigger this.
+** This would take the ambiguity out of a security *risk* (almost nothing
-** The contact point would usually be an email address and perhaps an associated GPG key, but the bug tracker could also suffice if the project is really keen on full disclosure. --[[User:avs|avs]] 18:30, 28 October 2009 (UTC)
+is risk-free). Vulnerabilities, however, are more tangible. There is,
+of course, still a class of vulnerabilities that could result in a
+debate, but much less so than when talking about risk.
+** "Known" is also tricky - known by whom? - but it could suffice, as if
+anyone who is actually involved in this QA checking "knows", it would
+trigger this.
+** The contact point would usually be an email address and perhaps an
+associated GPG key, but the bug tracker could also suffice if the
+project is really keen on full disclosure. --[[User:avs|avs]] 18:30, 28 October 2009 (UTC)
 == Qt ==