bugzilla.redhat.com vs upstream bug trackers

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

On 06/18/2013 06:24 AM, David Tardon wrote:
> On Mon, Jun 17, 2013 at 09:49:37PM +0000, "Jóhann B. Guðmundsson" wrote:
>>
>>  From my point of view If you are not involved with upstream ( at
>> least subscribed to their mailing list and have a account in their
>> upstream tracker ) you should not be maintaining package in the
>> distribution but should instead just be maintaining it in a side
>> repo.
> That is your opinion. Others can have their own opinions about the
> matter.

I never said they could not are you implying that I cant?

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

Basic triage stuff really...

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

>>>>> 2) There's a 100% chance that I don't have the time between work and
>>>>> family obligations.
>>>> We do not need unresponsive or poor maintained packages in the distribution
>>>> and if there is really need or demand for the component you maintain,
>>>> co-maintainers will appear or people to pick it up if you drop it so if you
>>>> dont have the time to properly maintain your component(s) in the
>>>> distribution then either find yourself co-maintainers or drop the package.
>>> Again, our key disagreement here is on the definition of "proper
>>> maintenance".  I have more than enough time to keep up with new
>>> versions as they are released (most of the time) or to pull a patch
>>> out of the upstream's version control and add it to the package. But
>>> even if I had the hardware I don't have the kind of time it takes to
>>> set up test environments to reproduce a bug, and then dig into the
>>> code and find the bug, develop a fix and then test 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.

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

>> Agreed that's inefficient but it's still a necessary and unavoidable
>> part of maintainers responsibility from my point of view.
> It is by no means unavoidable. In fact, it is very easy to avoid.

Yes at this point in time you can ignore bugs all you want and nobody 
said you could not but rather you should not.
> 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?

Anyway just because you are volunteering does not mean that you are an 
slave, cannot follow a set or rule or we cant have one.

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

JBG