[mythtv-users] Ticket #7668: ffmpeg errors with nuvexport on Ubuntu 9.10

[Ian Forde]

On Jan 3, 2010, at 10:22 AM, David L <idht4n at gmail.com> wrote:

> On Sat, Jan 2, 2010 at 6:33 PM, Brian J. Murrell  wrote:
>> On Sat, 2010-01-02 at 20:41 +0000, MythTV wrote:
>>> #7668: ffmpeg errors with nuvexport on Ubuntu 9.10
>>> ---------------------------------------- 
>>> +-----------------------------------
>>>  Reporter:  brian@…                     |       Owner:  mdean
>>>      Type:  defect                      |      Status:  new
>>>  Priority:  major                       |   Milestone:  unknown
>>> Component:  Contributed Scripts & Apps  |     Version:  0.22
>>>  Severity:  medium                      |     Mlocked:  1
>>> ---------------------------------------- 
>>> +-----------------------------------
>>> Changes (by robertm):
>>>
>>>   * mlocked:  0 => 1
>>>
>>>
>>> Comment:
>>>
>>>  We don't need "me too"s and this isn't a help forum.
>>
>> Wow.  One single user confirming that a particular bug is not  
>> isolated
>> to the reporter and a ticket gets locked down with a "sod off".  It
>> might not have been so bad but not even a single developer (or anyone
>> for that matter) bothered to comment on the bug, confirming it,  
>> denying
>> it, asking for more information or anything at all.
>>
>> I don't think it was at all unreasonable, given the complete lack of
>> response from anyone otherwise, for another user to confirm that a  
>> bug
>> is being seen more widely than the single sighting by the reporter  
>> and
>> asking if there was any known solution or work around.
>
> Well, it is documented that the bug system isn't for "me too" or
> enhancement requests.  However, I'm not sure I understand the
> rationale for these rules.  The bug tracking system seems like
> a natural place for these things.
>
> A "me too" report servers at least four purposes:
>
> 1) It gives a developer that wants to test a potential fix a pool
> of testers and an easy way to contact them directly.
> 2) It gives developers looking to squash bugs a sense for
> how many people are being affected by different bugs.
> 3) It provides an easy way for users who are affected by a bug
> to keep track of the status of that bug with a higher SNR than
> the list.
> 4) A correlation between the bug and architecture can sometimes
> be established (eg, all the reports are from mythora systems)
>
> As for feature requests, they are so similar to bugs, most bug
> reporting systems have integrated support to categorize
> them as enhancement or feature requests.  I've seen recent
> discussions on this list about where to request features.  I've
> seen some documentation point to the list and other point to
> a wiki.
>
>
> All that being said, rules are rules.  My question is what is the
> reason for these rules?  Is it due to limitations of the bug
> tracking system?
>
> Were you actually prevented from submitting a patch that
> would have fixed the original reporter's problem?  If so,
> that is clearly screwed up.

Not to keep this going, but an email to the list that: 1) references  
the ticket number, 2) requesting that it be unlocked, because, 3) one  
is stating that one has a patch, would have made this a much smoother  
process.

(The nuvexport breakage issue has been around for awhile on Ubuntu,  
and the devs are pretty happy to accept patches from folks willing to  
pitch in. Folks should just be mindful that the fact that the ticket  
wasn't closed as "invalid" or "wontfix" means that the devs know that  
it's a potentially valid issue. "me too" messages in that case aren't  
really needed. Patches, of course, are always welcome.)

   -I