[mythtv-users] A clustered PVR just rocks...

[Brad DerManouelian]

On Jan 25, 2008, at 1:06 AM, f-myth-users at media.mit.edu wrote:

>> I agree. If there were only some way to TRAC the bugs that are found
>> in mythtv. That would make things much better. Something that is http
>> accessible and open to the public.
>> Something like http://svn.mythtv.org/trac would be excellent.
>
> It's not clear to me whether you're being sarcastic, or whether you're
> trolling, so I'll play the sucker and take you at face value.

Can it be both?

> The reason I suggested a wiki page is because Myth uses Trac in a  
> highly
> unusual way:  rather than tracking user-submitted bugs that don't have
> immediate fixes (as pretty much every bug-tracking system I've ever
> seen gets used), Myth intends Trac to be used solely to keep track of
> -fixes- for bugs---bug reports that are submitted without patches are
> simply closed.  [Myth doesn't appear to use Trac as a BUG-tracking
> system so much as a PATCH-tracking system, and saying so in huge
> blinking neon letters in lots of places might be helpful, but that's
> a different discussion.  And before anyone nitpicks, yes, I know that
> bugs which come with backtraces, e.g., ones that cause an actual  
> crash,
> are an exception, as are occasional other narrowly-defined issues, but
> in general, Trac is being used as a patch-tracker.]

That's not true. If you find a bug, you submit it in trac and it is  
tracked there as a bug even if you don't have a fix for it. It gets  
assigned to a developer and they will fix when they it rises to the  
top of their radar. However, if you submit a FEATURE REQUEST without a  
patch, it is removed since it's not a bug, but a feature request  
without a patch. Feature Requests WITH patches are happily accepted  
into trac and considered for inclusion into the code.

> Yes, this is highly idiosyncratic behavior and yes, it seems to
> confuse just about -every- new participant---witness the large number
> of people submitting bugs to Trac (and attempting to have  
> conversations
> there) only to be yelled at and to have them closed out from under
> them---but it's clearly not going to change.  It's -especially- not
> going to change for this particular subject, when you consider that
> it's the core developers who (a) know best which bugs are relevant to
> tunerless backends and (b) think least that these bugs are actually
> important enough to fix, and hence (c) are unlikely to want to put 'em
> into Trac w/o fixes.

Clearly it confused you because you feel like trac isn't being used as  
a bug tracking system here when it in fact is.

> Hence, we're left with wiki pages, and hoping that those might get
> enough traction (in the "what's going to be a problem here?"
> direction, and the "is anyone going to get motivated to suggest
> a patch to a mentioned bug?" direction).

Discussions don't belong on the wiki. Answer do. Discussions belong in  
the forums. Like this one.

> If nobody cares enough in either direction to create or edit the page,
> well, so much for the suggestion.

You're somebody who seems to care enough. Why leave it up to someone  
else to do?

To get back to the initial discussion which prompted this:
Tunerless backend system is a feature request since that's a feature  
(having a backend without a tuner) that is not currently a feature of  
mythtv. So if you want to have the feature of having a backend without  
a tuner, you would need to supply a patch and post it to trac.

Remember: A bug is something that is supposed to work and doesn't  
like, "In my supported config, I get a segfault". A feature request is  
something you would find useful that currently isn't available like,  
"I would like to run mythbackend without a tuner even though that code  
path has never been considered by development."