[mythtv-users] ticket locking

[Remco Treffkorn]

On Wednesday 18 June 2008, Kevin Kuphal wrote:
> 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

No, it didn't. The ticket was locked. That's the problem with this list, no 
attention span ;-)

-- 
Remco Treffkorn (RT445)
HAM DC2XT
remco at rvt.com   (831) 685-1201