On 11/05/2010 07:47 AM, Frank Murphy wrote:
> On 05/11/10 07:27, Alexander Kurtakov wrote:
>
>> So what if I got 100 bug reports and didn't answered 10 bugs you will want to
>> orphan my package?
>> Welcome to the world without gtk, openjdk, eclipse-platform, kdelibs ....
> I think maybe  it is meant more as "You have 100 bugs, 80 are not
> acknowledged.
>
>> I can't see why can't we just admit - This is our best feel free to join us
>> and help ?? (someone should find better wording)
> Is this not where added manpower can help?
> At least a group who can be put together (existing?),
> to look at reproducing\unable to bugs, to help the maintainers.
>

We already have QA dedicated group to aid maintainers and it's called 
triagers and a whole range off testers which can be pinged on irc or on 
the test-list even for a period of time we had a automatic responce 
reply to all bugs which was to "lower" the expectation of 
new/inexperienced reporters but it did not fix the underlying problem..

Reports came in --><-- Auto responce reply back to the reporter --> QA 
verified try to duplicate bug --> Bug set to maintainer --> Bug stayed 
like that until EOL....

We have had watercooler discussion on irc amongs ourself in QA on and 
off through several release cycles now to assign or ask a tester/triager 
to spesific components which have an actual maintainer behind them ( not 
speaking about packagers here ) to take the load of develepers and in 
some cases testers have done so on their own initiative because they 
just love the application they are running as a potentiall solution but 
we have not written anything down or come up with some concrete plan to 
aim at and work on.

One of the problem to solve with that is how we can equally cover all 
componets since we fear that users would cherry pick and jump on the 
component they love and leave more underthehood critical components out.

Basically popular component nr1 has 30 testers/triager while more vital 
critical component nr1 has 0..

Perhaps assign/rotate method would work in this case users a and b 
assign to component a this day/week while c and d take care of component 
b but as I mentioned all of this is just more or less ideas in our heads 
and have been so for a while.

Ofcourse this would only apply to responsive ( upstream ) maintainers 
but not packagers and unresponsive maintainers since nonresponsive 
maintainer is still a nonresponsive maintainer and spending anykind of 
community resources on them is just a waste of everbodys time..

QA service like this might actually attract more upstream developer to 
participate and join the project.

JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to