Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 23 hrs, 28 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 18 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 3 hrs ago - more...
|
2010-01-26
, 00:49
|
|
Posts: 53 |
Thanked: 49 times |
Joined on Jun 2007
|
#32
|
Just thinking..
I'd like to have diff -y view of the project changes and LOC for changeset size. This could be against the last accepted package or the first one put in the testing queue if there is no previous package in extras. This way the changes could be verified (their size and what they are). This could be helpful in two cases:
1) Package in extras, a new version is submitted to extras. Large changes (+new features) -> more testing, small changes -> less testing. Concentrate on what has changed.
2) Package is in testing queue, the maintainer updates the software. Changes can be verified to be small -> no need to reset all test cases to zero.
I'd like to have diff -y view of the project changes and LOC for changeset size. This could be against the last accepted package or the first one put in the testing queue if there is no previous package in extras. This way the changes could be verified (their size and what they are). This could be helpful in two cases:
1) Package in extras, a new version is submitted to extras. Large changes (+new features) -> more testing, small changes -> less testing. Concentrate on what has changed.
2) Package is in testing queue, the maintainer updates the software. Changes can be verified to be small -> no need to reset all test cases to zero.
 |
|
2010-01-26
, 11:23
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#33
|
Originally Posted by attila77
In the perfect world it shouldn't make any difference, but I've seen voluntary/collaborative 'jobs' turned in paid jobs. When someone has the obligation to do something a large number of people will step away for that, that's in our nature. Of course if the paid person is a good leader, he will minimize the damages and probably can still get a lot of help for his tasks.
Why ? (out of curiosity, I don't see why being paid would make any difference if the level of authority is the same). Just trying to understand problems to refine the idea.
Originally Posted by attila77
Agree with your points.
I wanted to avoid it being an overburdened position that results in tester fatigue in the end. I see the tester admin or QAmaster position being more of a 'grease' kind (exercising authority only on testing errors or resolving a status quo), rather than a heavy-batted, control-oriented one. If we DO have a group of people who can (on the long run) predictably dedicate an amount of their time and are capable to do this - all the better !
|
|
2010-01-26
, 13:24
|
|
Posts: 268 |
Thanked: 304 times |
Joined on Oct 2009
@ Orlando, USA
|
#34
|
Originally Posted by attila77
Fully agree. Having a group of dedicated admins is a good thing to start things off. Who knows, maybe down the road, a paid position would be warranted.
I wanted to avoid it being an overburdened position that results in tester fatigue in the end. I see the tester admin or QAmaster position being more of a 'grease' kind (exercising authority only on testing errors or resolving a status quo), rather than a heavy-batted, control-oriented one. If we DO have a group of people who can (on the long run) predictably dedicate an amount of their time and are capable to do this - all the better !
The Testing concept was created by the community and having apps piling up in the queue simply looks bad on maemo.org and discourages developers.
The admins could become the de facto point men for testing related help/questions and perhaps well-positioned for "recruiting"/"mentoring" testers. All that is required is a group of dedicated individuals.
| The Following User Says Thank You to archebyte For This Useful Post: | ||
|
|
2010-01-26
, 23:03
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#35
|
Group created: https://garage.maemo.org/projects/testingsquad/
We're looking for committed members for the testing squad that can spend some time testing stuff, and also leading the testing squad in some weeks(that would be easy
). Feel free to request membership at garage.
Those that doesn't feel ready or without enough skills, please keep following the group activities and doing some testing in the easier areas.
More news soon.
We're looking for committed members for the testing squad that can spend some time testing stuff, and also leading the testing squad in some weeks(that would be easy
). Feel free to request membership at garage.Those that doesn't feel ready or without enough skills, please keep following the group activities and doing some testing in the easier areas.
More news soon.
 |
|
2010-02-02
, 01:14
|
|
Posts: 609 |
Thanked: 243 times |
Joined on Jan 2010
@ Eastern USA
|
#36
|
Originally Posted by VDVsx
By skills, do you mean the ability to identify a solution to the problem (i.e. looking through the code)? Or simply knowing what to do when encountering a bug (reporting, etc.)?
Those that doesn't feel ready or without enough skills, please keep following the group activities and doing some testing in the easier areas.
Also, I think that somewhere along the road, we should have a mandatory revision of app descriptions (solution #9: http://maemo.org/community/brainstor...ll_basket-002/), as it would help the newcomers (because Maemo 5 and beyond is supposed to target a larger audience) who are unfamiliar with the said app.
I'm not trying to tarnish developer's reputations (I'm definitely in no position to do such a thing), as they clearly worked hard on their respective projects, but rather to benefit the end-user.
Originally Posted by Sasler
Going along with benefiting the end user, I second this.
I would even go so far that the Admins should post a list of the apps that should be tested now. Critical updates would get priority and for the rest there could be a simple FIFO (first in, first out) procedure.
|
|
2010-02-02
, 09:14
|
|
Posts: 52 |
Thanked: 10 times |
Joined on Jan 2010
@ London, UK
|
#37
|
Got to say great idea !!!
I have noticed the App's section is getting faster at releasing stable updates and fresh apps.
Nice work
I have noticed the App's section is getting faster at releasing stable updates and fresh apps.
Nice work
|
|
2010-02-02
, 10:12
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#38
|
Originally Posted by xomm
For the first option would be very difficult to encounter candidates, we've lot of distinct software built with difference languages and tools.
By skills, do you mean the ability to identify a solution to the problem (i.e. looking through the code)? Or simply knowing what to do when encountering a bug (reporting, etc.)?
What I mean, is the skills to test some (or all) of the testing points[1], and as you said, the ability to report any issues encountered. Is not a hard task
[1] - http://wiki.maemo.org/Extras-testing/QA_Checklist
|
|
2010-02-02
, 23:11
|
|
Posts: 2 |
Thanked: 0 times |
Joined on Feb 2010
|
#39
|
I'm not an expert on programming or Maemo but I want to help to improve the apps. How is the process? Some administrator will indicate the apss that I'll test?
Excuse me the poor English...
Excuse me the poor English...
|
|
2010-02-02
, 23:32
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#40
|
Originally Posted by pabloresende
Yes, we'll publish a list of apps each week, more news soon.
I'm not an expert on programming or Maemo but I want to help to improve the apps. How is the process? Some administrator will indicate the apss that I'll test?
Excuse me the poor English...
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc