Andrew Flegg wrote: > On Wed, Nov 4, 2009 at 09:03, <tero.k...@nokia.com> wrote: > > > > Two days later I notice a blinking orange light in my status bar. I > > see a new version of the application. I install, I check what has > > changed (minor or major?), I run my tests and thumb it up again. > > Aside: how do you check what has changed?
For the stuff in garage it's simple; skim the source, and for others see what the package installed, and see if everything is still there. > > I didn't loose too many minutes or hours of my life, no one > got killed > > or injured, and the punitive damages to all parties appear > to be zero. > > Life's good and I get a cup of coffee. > > Trouble is, developers (myself and others) are saying the > current process of resetting to zero on every single > promotion is incompatible with "release early and release > often". The theory about resetting to zero is that testers > will do the full QA process again (check it still uses /opt, > check a bug hasn't been introduced which introduces battery > management issues, check that it both installs, uninstalls > and upgrades cleanly). Yes, none of those are so hard that I wouldn't do it. (Ok, I sometimes skimp on the uninstall testing for apps that will never leave my device. I'm a bad person) > > In other words, I test applications that I use or leave on device. > > It's not something I do randomly. I believe that the author > of the app > > has committed to the app, so in return I commit to it as well. The > > rules and process are a good thing, but in the end it is > people who do > > the things. No matter if it is the developer, the tester or > the user, > > it's about the people. > > Yep, however I now disagree with the logical conclusion of > your statement (which has been expressed elsewhere) which is > "when we have lots of users it'll all work itself out". I still think that. 10 votes from an installed base of fifty, a few hundred or say ten thousand is a different thing. > [and your original statement] > > Too complicated. Referring to the complex schemes of saving the karma points. Sounds too complicated to start counting things like time, rate times or things like that. It might be cool to implement, but does it make sense? Just do something really simple like new version get's the old votes if the app is still in testing. The tester will see the new version and change her/his mind if necessary. > We seem(ed ;-)) to have a consensus between this thread, and > the QA marathon feedback, between both developers and testers > that resetting to zero was causing more problems than it > solved. We've now moved on to ways of maintaining some app > karma from one release to another, but it sounds like you > disagree with that consensus? I see issues in saving the karma, but they can most likely be worked out. Either dump the votes or keep them. Just don't make it too complicated. > It may be that there are two > kind of testers: > > * Dedicated QA browsers. Will install any app from the QA queue > to evaluate and score it. Will be done whenever they have time. > > * Dedicated application users. Will install upgrades of > apps they've > installed and evaluate/score them as pushed to. This most likely is the case. I do admit to random testing once in a while, but it is more to see whether there is something I could start using occasionally. Tero > Cheers, > > Andrew > > -- > Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ > _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
