Comments inline.
----- Original Message -----
From: "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>
To: devel(a)lists.fedoraproject.org
Sent: Tuesday, November 22, 2011 1:36:53 PM
Subject: Re: Fedora clean up process seems to be seriously broken...
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.
We seem to disagree here. I value every maintainer even one that steps in once in a year.
And yes I value him more than someone that would open 10 bugreports without instructions
how to reproduce.
So someone inactive for you seems to be active for me, right?
> 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.
Hmm, this sound like a sloppy excuse to me. It's well known that first thing requested
is how to reproduce.
Do you have an idea how many of the bug reports have this information? My experience is
less than 10%. If someone wants to help
maintainers he can do that but just closing the bugs that don't have clean howto
reproduce procedure written.
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 ).
Do you really think that one can write a simple howto test page?
Huge numbers of bugs are results of interpackage dependencies and
every next day we try different approach in testing because we have new knowledge about
some change somewhere.
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.
Would you agree to tighten the requirement for reporters too?
If you can't do a debug build and provide me the output you're not qualified to
report an issue.
It sounds stupid I agree but you see the point now.
Requirements to join should loosen in order for Fedora to gain a critical mass and
adoption
and not to become a niche distro for the pseudo-elit. And yes every distro is destined to
fail by trying to ship only
a given subset of packages because users don't care for few hundreds of perfect
packages but having the packages they use ready.
And there are no 2 persons that have the same set of packages installed.
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
Changing the ownership model is one thing, putting more requirements on the maintainers
are unrelated things.
And if such thing should be discussed it should happen in different thread.
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
The only solution I see is to get more things involved not to show Fedora as hostile
community and lose even the contributors we have now.
Alex
JBG
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel