On 11/22/2011 08:51 AM, Aleksandar Kurtakov wrote:
Can I be added to the list of maintainers that need help very badly
from the beginning?
If such an list existed I dont see why that should be a problem.
I maintain a number of packages that are very low in the Java stack
and would force the whole Java stack to be removed if they are removed but noone wants to
maintain them.
That's how I gained them! If such a policy is adopted it would be very bad decision
if there isn't a mechanism prior to that for maintainers to list packages that they
maintain to keep the distro integrity but don't care about them personally. I bet that
there would be a very big list of maintainers that would list a number of there packages
in this list.
Not sure what you mean about distro integrity since arguably shipping
few but well maintained components is better then shipping many poorly
maintained or not maintained at all.
But basically you winded up being stuck with them since you wanted to
ship component A but to do so you required B), C) and D) but nobody
is/wants maintain B),C) and D).
Nothing can actually be done here since that's the price one has to pay
wanting to ship component A).
To give a better estimate - I'm owner of 69 packages(139
comaintainer) of these I would like to maintain only 11 (eclipse*) packages but the rest
is crucial to something. The problem should be obvious now - I would like to list this 58
packages as something I need help with. And to explain things better - yes I do fix bugs
when they arrive in this packages- but just a real bugs (broken functionality, crashers,
etc.) and let aside bugs asking for new version update, new functionality, pony:) until I
need them. It's volunteer based effort and NOONE has the right to put more burden on
packagers or you will lose them.
Nobody is putting burden on anyone other then the maintainers themselves.
Either they do it directly to themselves ( by maintaining more things
they can handle which eventually may lead to burnout ) or it's being
done by other sloppy/non responsive/absent maintainers indirectly
through the component they are supposed to maintain ( which they aren't
doing which results in other maintainers have to do all the leg work
themselves encase their components depends on the one that he maintains
) or through various policy's/processes we in place trying to deal with
those.
Which is what I would say is just another symptom of the underlying
problem that needs to be dealt with as in active maintainers themselves
are paying hefty price for those inactive once.
Through bureaucracy and what you are experiencing above amongst other
things.
And everyone stop telling the story about disappointed bug reporters,
why noone is saying about disappointed maintainers? My experience is quite the opposite at
least 7 out of 10 bug reports are from people that don't want to help. I'm
speaking for bug reports that stay needing info from reporters for weeks and months before
I close them as INSUFFICIENT_DATA. If a decision to orphan packages is made a similar
decision should be made to ban bugzilla accounts that don't respond to information
requests from maintainers. If a packager is losing time for reporters if he doesn't
respond, there are for sure reporters that lose time of the packagers. In my case they
lose me so much time that I would have probably fixed some of the bugs that I haven't
responded to!!!
Does the previous paragraph sounds right? HELL NO!! There should be an effort to make
more people help as much as they can (even if it's one day per year), not an effort to
put more burden on people that are already doing work.
We actually have process in place to deal with that name Triagers
however a while back I and James I believe and perhaps few others in QA
went ahead with How_To_<component>Debug pages to try to deal with that
problem in an attempt to educate and have proper documentation for
reporters and Triager to follow. Aiming for a workflow like this...
Report comes in ( preferably containing proper information to begin
with ) --> Gets triaged ( if == insufficent data point reporter to how
to debug page for a given component and wait until he provides proper
data ) --> Flag Triaged and hand it to maintainer for further processing.
At that time we had what roughly 6000 - 7000 components in the
distribution and I quickly realize that we could not write all those how
to debug pages without maintainers participation in the process ( which
went lala depending on who you were dealing with ) at least we needed
to prevent further components being introduced into the distribution
without having that information available so we eventually gradually
would manage to work on those 6000 - 7000 components and slowly bringing
that number down. ( We even had played with the idea if we could
integrate this to Bugzilla somehow as on components page would be a link
to the how to debug page )
But no the proposal made to FESCO/FPC winded up in *Recommendation*
instead *Requirement* which automatically made that process and effort
to be in vain since I knew that maintainers would not provide that
information if they did not have to and guess what I turned out to be right.
Same thing goes for "how to test" since maintainers would have to
provide us with the information what was the best way to test their
component ( for the most part anyway ). Without that information process
like proven testers is just a waist of time and unnecessary bureaucracy.
( just one of the issues why something like proven testers does not and
will not work ).
As ( with my QA hat on ) we have done what we can to try to improve the
situation from reporters stand point ( ofcourse we can always try to do
better and I'm pretty sure armed with the knowledge/experience above
played a significant part in why Red Hat started investing more in ABRT
and AutoQA ) however it always boils down to the same thing to improve
overall quality of the distribution we need to deal with that on
maintainers level and preferably without "punishing" those active and
responsive maintainers which are doing what they can when they.
Increase/tighten the requirement for maintainers to join the distribution.
Drop the ownership model and assign all components to their relevant sig
like all java components get assigned to the java sig etc. then each sig
could try to come up with a way to distribute that load evenly amongst
it's members
Seriously let's try to come up with something and try that which is
better then doing nothing and allow things to continue as they are.
JBG