bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Tue, Jun 18, 2013 at 09:13:23AM +0000, "Jóhann B. Guðmundsson" wrote:
> On 06/18/2013 06:24 AM, David Tardon wrote:
> >
> >>Agreed but at least they should know how to debug their own
> >>components which when I started the how to debug initiative a while
> >>back in QA revealed many of them did not even know how to do that.
> >>
> >And how is this relevant here?
> 
> This for example is relevant to debug the component in question and
> or provide that reporter with that debug information encase he needs
> to provide the packager with the proper report so the packager can
> forward the proper information upstream.

Or the packager can send the reporter upstream, where there are people
who understand the package.

> 
> Basic triage stuff really...

All right, if you want triaging, you can try to resurrect the old
BugTriagers SIG... Btw, in libreoffice upstream it is QA who is doing
the triaging (Hint .-)

> 
> >>So here is where I see things go wrong for many packagers they fail
> >>to understand or rather we fail to provide proper info on how much
> >>time it takes to maintain a package in the distribution.
> >Because there is no way to quantify that. Because the world is not black
> >and white and it differs from package to package.
> >
> 
> Yes there is a way to quantify that and provide an base time at best
> conditions

So, since you are so confident about it and since you are part of the
"we" who fail to provide proper info to packagers, would you care to do
it?

> 
> >>When you decide to maintain a component in the distribution you need
> >>to ensure that you have enough time to perform steps a) b) c) d) and
> >>e) not only steps a),b) and c).
> >What are these steps?
> 
> The once that you conveniently cut out when responding to this.

I thought so, but that list was denoted by numbers, not letters... So I
was not sure if there was another list.

> 
> >
> >>The load or rather the time of the maintenance can however be
> >>distributed between co-maintainers and between existing sub
> >>communites in the distribution or for packagers/maintainers
> >>themselves by building a sub-community surrounding the component(s)
> >>in question.
> >I see two interpretations of the above paragraph:
> >1. You imply that the solution is to put every existing maintainer into
> >    several groups/sub-communities.
> >2. You think that there are hordes of people eager to become
> >    co-maintaineres, if only we had given them the chance.
> >
> >Both are wrong.
> 
> No you interpretation of my response is wrong.

What is the right interpretation then? Neither co-maintainers nor
sub-communities can be created without _new_ packagers. Otherwise the
load on the _current_ packagers will not be alleviated, just shuffled
around a bit. And new packagers are not there. That is the main fallacy
in your reasoning.

> >Says who? The people around here are _volunteers_, not slaves. One does
> >not create a community by forcing rules on others.
> 
> 
> Trying to follow your logic hence the question do o you think we
> increase our user and contributing pool by delivering broken
> components in the hands of our userbase?

Which components are broken, concretely? That a packager does not
respond to bugs reported to his component does not mean anything is
broken, except maybe your idea about how package maintenance works.

> >This is purely your interpretation.
> 
> Yes this is my interpretation and findings after being over 5 years
> in the QA community, working on feature that spans multiple packages
> and more.
> 
> I'm allowed to have one right?

Yes, you are.

D.