[mythtv-users] ticket locking

Kevin Kuphal kkuphal at gmail.com
Wed Jun 18 18:33:14 UTC 2008


On Wed, Jun 18, 2008 at 1:24 PM, Remco Treffkorn <remco at rvt.com> wrote:

>  On Wednesday 18 June 2008, Brad DerManouelian wrote:
> > On Jun 18, 2008, at 9:23 AM, Udo van den Heuvel wrote:
> > > Paul Bender wrote:
> > >>> That supports my idea that my observation was really a special case.
> > >>
> > >> Congrats.
> > >>
> > >> You admit believe that your problem is a special case yet you
> > >> refuse to
> > >
> > > refuse?
> > > can't/don't know/etc.
> > > Don't make me appear as unwilling to assist insolving a case.
> >
> > You said you won't load valgrind. Now you'll have to wait until
> > someone else reproduces your situation WITH valgrind in order to give
> > the devs something to start with.
> >
> > > Also I was believing that MythTV was designed to (also) record TV.
> > > Over here it does so, 24/7 for 3 channels using 7 virtual tuners on
> > > one
> > > real card.
> > > Because recording is all it does and because recording is the main
> > > feature of MythTV it was strange to see it grow this big. This should
> > > have been notice before by someone else!?
> >
> > You're the first. If you can't provide the devs with the information
> > they request, you have to wait patiently until someone else runs
> > across the problem and can provide the information required to
> > investigate.
> >
> > If this were a corporate software company, the Quality Assurance team
> > would replicate your environment as closely as possible and run
> > valgrind to see where the memory leak is. This is open source. There
> > is no QA department. We are all QA and you're the only one with your
> > environment that is causing the issue.
>
> Sorry dude!
>
> A bug report of any kind is information. As it ages its significance
> declines
> if no data is added. Eventually it can fade away...
>
> The open source development model is not different from closed source in
> the
> handling of bugs. If the "customer" reports a bug, but can not provide
> detail, the report stays active till dis-prooven or it dies of old age.
>
> A statement like  "There is no QA. We are all QA..."  is confusing to me.
>
> And "you're the only one with your environment that is causing the issue"
> sounds a lot like blaming the user.


It is just the reality.  We all run Myth in production of some sort, if we
were all seeing this leak, it would be easier to diagnose, but since it
isn't been widely seen, it will likely require more than "It's leaking" to
diagnose.  In fact, through his defense of his refusal to provide
information, he's provided much of the information needed to understand that
this is likely a very unusual bug that would not affect a majority of the
users.  Furthermore, he's been given a route by which to become active in
the process (which most users ask for when reporting bugs...I can't fix it!
How can I help?) and provide valgrind information to track down the leak.
Unfortunately he won't, so it will sit most likely.

>
>
> I maintain both o/s and commercial s/w. I treat all my "customers" the
> same.
> They help me make my s/w better. Every bug report helps me. If I can not
> get
> enough information from the user, I say "Thank you" and let the bug stand
> till somebody else provides input, or it ages...


Which is precisely what happened in trac.  Ticket open, request for info,
none provided, aging.  Except now this hypothetical user is complaining to
you that you're not fixing the problem rather than accepting your "Thank
you".  What then?

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080618/dd688acd/attachment.htm 


More information about the mythtv-users mailing list