[mythtv-users] A clustered PVR just rocks...
myth at dermanouelian.com
Fri Jan 25 15:14:22 UTC 2008
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
> 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
> 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
> 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."
More information about the mythtv-users