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
> 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.