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
