| 1 |
Daniel Goller wrote: |
| 2 |
|
| 3 |
>On Tue, 2006-04-11 at 09:36 -0400, Stephen P. Becker wrote: |
| 4 |
> |
| 5 |
> |
| 6 |
>>Eldad Zack wrote: |
| 7 |
>> |
| 8 |
>> |
| 9 |
>>>Hello, |
| 10 |
>>> |
| 11 |
>>>Sometimes it becomes a problem whenever a new release or a tricky bugfix comes |
| 12 |
>>>up for a certain package. |
| 13 |
>>>To improve QA we can let our userbase help, especially people who use certain |
| 14 |
>>>packages quite heavily - they can provide good or even superior QA than devs. |
| 15 |
>>> |
| 16 |
>>>I think it would be a nice idea to keep a userlist for anyone who'd like to |
| 17 |
>>>volunteer testing packages they regularly use. |
| 18 |
>>> |
| 19 |
>>>We can consider a web interface for enrolling users to specific packages, and |
| 20 |
>>>maybe even get a bug.g.o account for the list, this way a bug can be opened |
| 21 |
>>>for the testers to comment on whenever a change that requires testing or |
| 22 |
>>>maybe just aiding arch teams to stablize packages. |
| 23 |
>>> |
| 24 |
>>>Maybe this was already pitched but it has just occured to me. |
| 25 |
>>> |
| 26 |
>>>Comments? |
| 27 |
>>> |
| 28 |
>>> |
| 29 |
>>> |
| 30 |
>>> |
| 31 |
>>Isn't this why we already have the arch tester position as described by |
| 32 |
>>GLEP 41 (http://www.gentoo.org/proj/en/glep/glep-0041.html)? |
| 33 |
>>Furthermore, are you saying that users would enroll themselves via this |
| 34 |
>>hypothetical web interface, or that an arch team would do so for users |
| 35 |
>>who have proven themselves to be worthy? If the former, this would be a |
| 36 |
>>serious step back in terms of QA (think about sorting out all the crap |
| 37 |
>>reports from ricer overlay users with OMGFAST CFLAGS from the decent |
| 38 |
>>ones). If the latter, I think the arch tester position already covers |
| 39 |
>>this sort of thing. |
| 40 |
>> |
| 41 |
>>-Steve |
| 42 |
>> |
| 43 |
>> |
| 44 |
> |
| 45 |
>didn't he ask for people who know a particular application very well? |
| 46 |
>i think there is a big difference between agreeing to test one |
| 47 |
>particular package since they know it very well and want to make sure |
| 48 |
>noone breaks it vs. being a full AT with all the things they get asked |
| 49 |
>to test |
| 50 |
> |
| 51 |
> |
| 52 |
I understand the idea, and I like it. However inorder to really get this |
| 53 |
to work smoothly and be useful some type of user-feedback tool that |
| 54 |
would help report back the exact build environment with times dates and |
| 55 |
warnings & errors + user notes would really make this type of system shine. |
| 56 |
|
| 57 |
For example, package xyz-1.1 comes out, and user is on this hypothetical |
| 58 |
list and gets notified of it. |
| 59 |
package xyz-1.1 is ~arch (given), user decides they want to test it and |
| 60 |
they emerge it the usual way. |
| 61 |
After emerging version 1.1, user should (inorder to give his report) run |
| 62 |
a tool that will send the ebuild's environment (CFLAGS, etc) and prompt |
| 63 |
for the user to it a "rating" (value of whether or not the package |
| 64 |
works) & give some notes (say, special requirments to make it work, or a |
| 65 |
patch, or just simply , "Works".) |
| 66 |
|
| 67 |
Anyways, I like the idea. +1 |
| 68 |
|
| 69 |
Regards, |
| 70 |
Andrew |
| 71 |
-- |
| 72 |
gentoo-dev@g.o mailing list |
Archives