<div class="gmail_quote">On Wed, Jun 18, 2008 at 1:24 PM, Remco Treffkorn <<a href="mailto:remco@rvt.com">remco@rvt.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>
<div></div>
<div class="Wj3C7c">On Wednesday 18 June 2008, Brad DerManouelian wrote:<br>> On Jun 18, 2008, at 9:23 AM, Udo van den Heuvel wrote:<br>> > Paul Bender wrote:<br>> >>> That supports my idea that my observation was really a special case.<br>
> >><br>> >> Congrats.<br>> >><br>> >> You admit believe that your problem is a special case yet you<br>> >> refuse to<br>> ><br>> > refuse?<br>> > can't/don't know/etc.<br>
> > Don't make me appear as unwilling to assist insolving a case.<br>><br>> You said you won't load valgrind. Now you'll have to wait until<br>> someone else reproduces your situation WITH valgrind in order to give<br>
> the devs something to start with.<br>><br>> > Also I was believing that MythTV was designed to (also) record TV.<br>> > Over here it does so, 24/7 for 3 channels using 7 virtual tuners on<br>> > one<br>
> > real card.<br>> > Because recording is all it does and because recording is the main<br>> > feature of MythTV it was strange to see it grow this big. This should<br>> > have been notice before by someone else!?<br>
><br>> You're the first. If you can't provide the devs with the information<br>> they request, you have to wait patiently until someone else runs<br>> across the problem and can provide the information required to<br>
> investigate.<br>><br>> If this were a corporate software company, the Quality Assurance team<br>> would replicate your environment as closely as possible and run<br>> valgrind to see where the memory leak is. This is open source. There<br>
> is no QA department. We are all QA and you're the only one with your<br>> environment that is causing the issue.<br><br></div></div>Sorry dude!<br><br>A bug report of any kind is information. As it ages its significance declines<br>
if no data is added. Eventually it can fade away...<br><br>The open source development model is not different from closed source in the<br>handling of bugs. If the "customer" reports a bug, but can not provide<br>
detail, the report stays active till dis-prooven or it dies of old age.<br><br>A statement like "There is no QA. We are all QA..." is confusing to me.<br>
<div class="Ih2E3d"><br>And "you're the only one with your environment that is causing the issue"<br></div>sounds a lot like blaming the user.</blockquote>
<div> </div>
<div>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.</div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><span id=""></span><br><br>I maintain both o/s and commercial s/w. I treat all my "customers" the same.<br>
They help me make my s/w better. Every bug report helps me. If I can not get<br>enough information from the user, I say "Thank you" and let the bug stand<br>till somebody else provides input, or it ages...</blockquote>
<div> </div>
<div>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?</div>
<div> </div>
<div>Kevin</div></div>