bugzilla.redhat.com vs upstream bug trackers

[David Tardon]

On Mon, Jun 17, 2013 at 03:55:57PM +0000, "Jóhann B. Guðmundsson" wrote:
> Because if you cannot properly maintain the component in the
> distribution the community is better of without it.
> 
> ...
>
> Then you should not be maintaining that component
> 
> ...
>
> 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.

You have this persistent idea that there are hordes of potential new
maintainers out there. Well, there are not. Trust me. I looked.

In all likelihood, what is going to happen if someone orphans a package
is that some other _existing_ maintainer picks it up. Either because he
uses it or because one of his packages depends on it (I had been a
"maintainer" of bsh for more than a year. I have never used it and have
only a vague idea what it does. All I know is that it is used by
libreoffice's scripting framework.)

> 
> >
> >3) Even though I'm an excellent programmer, well versed in C and
> >Python, and decent in Perl, Ruby, et. al.  I probably don't have the
> >familiarity with the codebase to even know where to start looking for
> >a bug.
> 
> If you aren't familiar with the component you are packaging and
> maintaining why are you doing it et all?

Have you even read the sentence? He does not talk about using something,
but about _debugging_ it. We do not expect maintainers to be developers.
And even if they are, we definitely do not expect them to be faimiliar
with the source code of every package they maintain.

> 
> >
> >4) Most software is complex enough that even configuration problems
> >are best handled by upstream because I'd be familiar with a small set
> >of configuration scenarios, but everyone's situation is unique and
> >understanding what exactly a configuration option does (especially in
> >edge cases) often requires an understanding of the code behind it.
> >
> >All of this means that I'm a speedbump in the way of getting the bug
> >fixed, at least until there's a patch that needs to be applied to the
> >package, or a new release to upgrade to.
> 
> It's component's owner responsibility to be in touch and contact
> with upstream and the man in the middle role of the
> packager/maintainer can never be entirely gotten rid of.

Yes, it can.

D.