Talk:Extras-testing/QA checklist

Contents

[edit] 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.--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.--tekojo 20:02, 24 October 2009 (UTC)

[edit] 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.--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. --avs 18:30, 28 October 2009 (UTC)

[edit] 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.--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.--tekojo 20:07, 24 October 2009 (UTC)

[edit] Checking root filesystem usage

Quick'n'dirty script: 

#!/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

[edit] Bug tracker

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

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

--Jaffa 12:03, 26 October 2009 (UTC)

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