Active Topics

 


Reply
Thread Tools
Posts: 93 | Thanked: 30 times | Joined on Sep 2009 @ Sydney, Australia
#51
Originally Posted by Bratag View Post
Agree. Optified indicator would be very beneficial
The process of promoting an app from Extras-devel to Extras-testing should FAIL if the app is NOT optified.

That way all apps in Extra-testing would be OPTIFIED.

If necessary, demote all existing apps from Extras-testing back to Extras-devel and only let the OPTIFIED ones be re-promoted.

That way, the only repository that may contain a non optified app is Extras-devel.
 

The Following 5 Users Say Thank You to Zelig87 For This Useful Post:
Flandry's Avatar
Posts: 1,559 | Thanked: 1,786 times | Joined on Oct 2009 @ Boston
#52
Originally Posted by Zelig87 View Post
The process of promoting an app from Extras-devel to Extras-testing should FAIL if the app is NOT optified.

That way all apps in Extra-testing would be OPTIFIED.

If necessary, demote all existing apps from Extras-testing back to Extras-devel and only let the OPTIFIED ones be re-promoted.

That way, the only repository that may contain a non optified app is Extras-devel.
Uh... that's great except there's currently no automated test for this. That's why it's on the list of things for testers to check...

Many of the things in the QA list could be automated, but it's easier to get people to test than to get them to write a testing app and test it. I'm sure that such code would be welcome, though.
__________________

Unofficial PR1.3/Meego 1.1 FAQ

***
Classic example of arbitrary Nokia decision making. Couldn't just fallback to the no brainer of tagging with lat/lon if network isn't accessible, could you Nokia?
MAME: an arcade in your pocket
Accelemymote: make your accelerometer more joy-ful
 
ossipena's Avatar
Posts: 3,159 | Thanked: 2,023 times | Joined on Feb 2008 @ Finland
#53
Originally Posted by Flandry View Post
It's a lot more time-consuming to edit the wiki, but i hacked most of that into the http://wiki.maemo.org/Help_testing_software page. I was going to just merge everything into extras-testing, but some of the material seemed a bit verbose and trivial for that page. If someone else can find a good way to consolidate everything into extras-testing and redirect the help-testing-software page to it, that would be great. Just remember that we need a concise but simple description of how to test. The extras-testing page is getting rather long, so the best bet might be to split it into one page describing the nature of the repo and how to add it, and put everything else into the qa checklist page it links to.

So much to do, so little time. Anyway, fresh pair of eyes now that i distilled that new info into the wiki would be good. We really do need a better/more complete testing guide.
that was the point for help testing software page:
being as simple instruction collection as possible.

then extras-testing can include all dev -stuff etc and new people to sw testing don't get frightened and run away..
__________________
Want to know something?
K.I.S.S. approach:
wiki category:beginners. Browse it through and you'll be much wiser!
If the link doesn't help, just use
Google Custom Search
 
Posts: 434 | Thanked: 325 times | Joined on Sep 2009
#54
Originally Posted by Flandry View Post
Uh... that's great except there's currently no automated test for this. That's why it's on the list of things for testers to check...

Many of the things in the QA list could be automated, but it's easier to get people to test than to get them to write a testing app and test it. I'm sure that such code would be welcome, though.
Everything that could be automated should be as soon as possible. This should be the priority now! As the user base for Maemo devices increases, there will be more developers for it too. This will mean more applications to test and this backlog will become only worse if something is not done to make the testing faster/easier.

The problem is that many of these new users have a very limited experience with Linux (like me) or no previous experience at all. Therefore something as "simple" as checking optification might already discourage potential beta testers, who might be more than qualified to check the functionality of the application and provide valuable feedback.

Last edited by Sasler; 2009-12-18 at 06:43.
 

The Following 2 Users Say Thank You to Sasler For This Useful Post:
Posts: 93 | Thanked: 30 times | Joined on Sep 2009 @ Sydney, Australia
#55
My point is that given being OPTIFIED is virtually a critical requirement of any app, I think whatever needs to be done to AUTOMATE that check during the promotion from Extras-devel to Extras-testing should be done ASAP.

I realise almost any test *could* be automated if enough resources were dedicated to developing an appropriate testing app, but surely given how important being OPTIFIED is, we could at least get that automated ??

I'm surprised this wasn't one of the first things done once the problem was discovered and /OPT was chosen as the solution.

Seems crazy to allow more non-optified apps into the Eco system, even if there are warning everywhere about enabling Extras-testing.
 

The Following 4 Users Say Thank You to Zelig87 For This Useful Post:
hypoxic's Avatar
Posts: 23 | Thanked: 20 times | Joined on Dec 2009
#56
From my experience this is what is considered part of a Build Acceptance Test and comes before any kind of integration is done with the larger code base. Terminology may differ depending on your environment, but the idea is that there are a class of bugs that are so critical that it is a waste of a Tester's time to install them if they fail. Sure we could have 10-50-500 people install an app while being helpful testers and then report the bug, but if we just filled up their memory and bricked the device, I'm sure they all would have preferred that a simple go-nogo test was done before they were put into a compromised situation, and will be Much less likely to help out with Testing in the future.

This has to be a problem already solved, and likely automated by Nokia/Maemo. If I'm just dreaming, will someone who has some info please let me know.

If Nokia/Maemo hasn't got the tooling or is able to share with the Community, then we Testers need to understand better what happens between -devel and -testing and how the promotion testing occurs and how it could be improved upon.
 

The Following 5 Users Say Thank You to hypoxic For This Useful Post:
smegheadz's Avatar
Posts: 387 | Thanked: 566 times | Joined on Dec 2009 @ Dublin
#57
what happened to the alpha and beta naming and v0.4 etc of apps?
it's universal. everyone generally understands that terminology.

My suggestions for making the testing of apps better are:

have a dummy hello world type app for noobs and first time testers to help which covers some of the basic functions apps could have. have a guide what to check and they can learn etc.

have an application that takes system snapshots. (see my previous post page 5) maybe have it as a bug tracker app, allowing quick feedback to maemo.org

allow people to tag an app as testing it so a user can see who and how many people have downloaded it to test and they can message each other about tests they have run etc (already implamented)

Make it easier to do things, 1 login rather then 3 for the site. it just gets annoying. people will get lazy and just not bother because they have to make another account.

when i get my n900 i'd like to help in testing apps and making it so people who just want a cool phone are able to take part without being a nix hacker, majority of people are from a windows background and haven't really scratched dos or scripting. Theres more user's then developers in the world so making it easy for them to test safely is ideal, gives people who can develop more time to do the more advanced testing and developing

Last edited by smegheadz; 2009-12-18 at 13:02. Reason: updating
 
blubbi's Avatar
Posts: 288 | Thanked: 113 times | Joined on Dec 2009 @ Germany
#58
I am used to the Gentoo installation system.

One thing that comes in very handy is the "fake root filesystem".

Every ebuild installs itself in a fake root, replicating the directory structure there. If everything was okay during the install, this directory just gets (in simple words) copied to the live file system.

This could make testing a bit easier cause you can check if everything is optified without affecting the live filesystem. This done, copy those files to the live system and start testing the app.

Is there a similar mechanism in apt?

Cheers
Bjoern
 

The Following User Says Thank You to blubbi For This Useful Post:
anidel's Avatar
Posts: 1,743 | Thanked: 1,231 times | Joined on Jul 2006 @ Twickenham, UK
#59
Originally Posted by stara View Post
After enabling extra-testing, I noticed that the yellow box started blinking. Xournal and Load-applet had new versions available. I assume from extra-testing side?

While I wait garage registration complete, very very slow, quick notes:

Xournal seems to work, thumbs up.

Load-app seems to require reboot :-/ My first reboot since getting N900 (been running it two weeks straight).
Xournal for a while had three different versions in each repository.
There was package 13 in Extras, one in Extras-Testing and one in Extras-Devel (package 21).

I promoted package 21 to Testing a month ago and that's probably what you got when enabling Testing.

Yesterday, though, I promoted it to Extras, but you've got it already installed. So no need to update there.

Aniello
 
smegheadz's Avatar
Posts: 387 | Thanked: 566 times | Joined on Dec 2009 @ Dublin
#60
i think this should be stickied to make more people aware that they can help with bringing more apps to their n900
 
Reply

Tags
testing apps


 
Forum Jump


All times are GMT. The time now is 00:46.