Fedora clean up process seems to be seriously broken...

Tue Nov 22 12:35:59 UTC 2011

Comments inline.

----- Original Message -----
> From: "Jóhann B. Guðmundsson" <johannbg at gmail.com>
> To: devel at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel