[mythtv] [mythtv-commits] Ticket #6899: Detect programs damaged by their broadcasters and notify the user for rescheduling
Michael T. Dean
mtdean at thirdcontact.com
Mon Mar 1 20:32:49 UTC 2010
On 03/01/2010 03:00 PM, f-myth-users wrote:
> Instead, you seem to be saying, "We hope eventually that 3872 will
> grow to encompass all the ways recordings might be damaged and will
> arrange to tell the user and/or reschedule automatically." That's
> nice, but it's been open 3 years with zero progress, so let's just
> say that I don't trust this assertion as far as I can throw it.
Don't take this as official MythTV or MythTV developer position, but at
least from my (personal) perspective, what I would be saying is, "I
don't care to maintain your hack in official MythTV. We plan to do it
right or not at all."
(Note, also, that "hack" is not meant as an insult. I write a lot of
hacks--and I have a ton of hacks that I use throughout my network
because sometimes "doing it right" just isn't worth the effort when
there's a quick solution for a problem I'm trying to solve. Also, in
many cases, my hacks develop over the years into better solutions just
because I gradually improve them over time. That said, I would never
expect any of my hacks to be accepted by someone else into a code base
they maintain. Still, I've offered some of my hacks to other people to
use when the scripts were helpful for them. That's pretty much exactly
what happened with your scripts--they're up there for others to use if
they find them helpful.)
> So what we have here is some tested, working code that could help
> people TODAY to know immediately---not days/weeks later when they
> finally sit down to watch something that is no longer being repeated
> ---that a recording they were looking forward to was munched by
> something upstream of Myth.
And it's still there in the ticket for anyone who feels it's necessary
for their particular situation.
> It has absolutely no impact on Myth if
> the user doesn't arrange to run it, because it's not compiled into
> Myth. And it's version-independent of Myth---anyone running Myth
> from the last 5 years (and probably the next 5 years) could use it.
> Myth has, in the past, taken stuff in contrib as a testing ground
> for things that might eventually make it into the mainline. I'd be
> perfectly happy if 6899 was in contrib for as many releases as it took
> for its functionality to wind up directly in Myth, and then it left
> contrib again because it was a part of Myth.
And what we have now is a mish-mosh of unmaintained, legacy,
use-at-your-own-risk code in contrib that we can't throw away because
people have come to expect that the (often-dangerous) scripts are an
official feature of MythTV. Therefore, developers are now wasting too
much time on these broken hacks and on the data breakage and other
problems they cause. (I'm not commenting on your scripts, but,
specifically, I'm thinking of the myth_find_orphans.pl and
myth.rebuilddatabase.pl scripts. There are many others in contrib that
are equally bitrotted.)
> But throwing away a working solution for a vague promise that sometime
> in the future someone else will reimplement the same code, maybe, and
> that we shouldn't solve the problem right now because some year
> someone else might do it instead seems peculiar to me, and feels like
> a case of not-invented-here syndrome. It certainly doesn't motivate
> me to send any more enhancements. I'm sure that's not the goal here,
> but it may well be the effect.
It's not thrown away. It's still in Trac, and it's available for anyone
to use in an unmaintained, use-at-your-own-risk fashion--just like what
we used to do for contrib. We've just learned since then that putting
something in contrib gives users an expectation that it will be
maintained--by us (even the authors tend to disappear and leave all
maintenance for the already-busy developers). Reference all the tickets
on myth_find_orphans.pl and myth.rebuilddatabase.pl. So, why do the old
ones get to stay when the new ones aren't accepted? Well, I,
personally, am writing the functionality to do what myth_find_orphans.pl
and myth.rebuilddatabase.pl scripts do, but doing it correctly--in
mythbackend and mythfrontend--so we can delete those 2 scripts.
And, really, would it be any better if we left #6899 open but unreviewed
and never included in contrib until MythTV 0.54, when we finally provide
all of the functionality you want inside MythTV, and then close the
ticket as "fixed" with a different approach?
We do appreciate your contribution, and there may be other users out
there who find it useful and use it. If so, I'd like to thank you for
the work you put into creating it and, especially, for helping others to
make their systems better. However, I think that leaving the scripts in
a ticket on Trac is better than putting them into contrib and making all
users see them as an official/approved/promised-to-be-maintained-by-us
solution for any recording problems.
More information about the mythtv-dev