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

["Jóhann B. Guðmundsson"]

On 11/22/2011 12:35 PM, Aleksandar Kurtakov wrote:
> Comments inline.
>
> ----- Original Message -----
>>

<snip>
> 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?

Certainly I value the person more that bothered to use the component and 
go through all the necessary step to report the bug he came across 
against that component than an indvidual that drop in to say hey after a 
year.

The overall quality of the bug report and how to improve along with 
lowering reporters expectations is something we need to deal with and 
solve @QA

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

You may consider this an sloppy I however do not as I see it the how to 
debug page for your component is necessary since without having spoon 
feeding information on how to do that the reporter will never be able to 
provide you with the information you want.

We simply can not improve reporting in general without having the 
necessary documentation on how to obtain that information and what 
minimal information the maintainer wants (  the how to debug pages ).

<snip>

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

The how to test is was aimed an more general QA activity ( building test 
cases either for reporters to use or automation )

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

Again to the point with the purpose of the how to debug pages =)

Before filing a report --> follow how to debug page for the given component

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

If you lower the barrier of entry and at the same time introduce more 
components to the distribution you at the same time are effectively 
lowering the overall quality of distribution however  if you can keep 
low barrier of entry without introducing new component at the same time 
you could increase the quality of the distribution as in by doing 
something like you have to be a co maintainer for x release cycles 
before maintaining a component on your own in the current ownership 
model without the ownership model he would be just dropped into the pool 
off the contribution for the relevant SIG and followed what ever policy 
that SIG has set in place for their contributors.


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

Agreed this thread is about identifying and managing non responsive 
maintainers.

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

Agreed to the extent as I mention in the above barrier entry.

JBG