[mythtv-users] What's appropriate to use/distribute in MythTV

[Jean-Yves Avenard]

Hi

2009/5/21 Robert McNamara <robert.mcnamara at gmail.com>:
> "I never created a bug!  Except that one time..."  Just because you're
> unaware of the bugs you've created doesn't mean you haven't created
> them.

that's very true...

But provided of the extensive amount of mails received, all related to
generic issues and never once about an actual crash I introduced, the
likelihood is rather low

> Jean-Yves, have you ever noticed how I'm the only one bothers to
> respond to your questions on the dev and theming lists?  You're right,
> it's hearsay.  But that doesn't make it any less *accurate*.  I'm not
> telling you that you're rubbing people the wrong way for my own
> benefit.  For some reason, I continue to waste time trying to explain
> how you might go about assuaging that ill will and seeing some
> traction on patches you've written.  Each and every time, I get bitten
> by you.  I'm out of patience with it.  If you don't want to fit in,
> that's out of my hands, but I'll simplify your life and not try to
> show you how any more.

That's very true ... None of my development questions get answered. I
usually find the answer sooner or later by myself but it's a bit of a
waste of time.

Now if I don't get an answer because it was *me* who posted it, I
guess it's too late to do anything to get back in the dev's good
books.
Which according to you isn't ever going to happen

> Again, an instance of "That's not true, except for when it is!"
again, only one instance ...

I guess whenever I submit patches, I could simply not lodge any patch
applying to the vdpau backport.. It's an easy thing to do.. Actually
it's easier that way.

> We *do* do this.  But when we spend a fair amount of time diagnosing
> the issue to see what's going on before someone thinks to ask "Are you
> running that backports repository," that's time wasted.

A one-liner on the IRC prompt could be enough then...

> You've been requested not to associate your backport with this
> project, yet you continue to use this list as a platform from which to
> espouse it.

Fine, I won't answer any more questions regarding VDPAU here...

> And yet it seems that neither request has been heeded, as this list is
> constantly used to troubleshoot your fork, and we've seen multiple
> tickets about it.  Also, as previously mentioned, we see semi-regular
> visitors in IRC about it.

I can't be held responsible for people lodging tickets about the backport ...
And as for troubleshooting issues, I'm pretty certain that *all* of
those would apply to anyone running trunk. Those would be
configuration issue of course. MythTV has never been the simplest
thing to install and configure

As such, in the long term it can only help with the stability of the
*future* stable 0.22


> You have built it in to your build system and made it as easy as you
> could to add it, and you announced it here.  This is enormously bad

So was the original discussion about the HD-PVR....
And I only provide a compilation of what's already existing in mythtv wikin


> form.  You are *endorsing a change that will prevent an upgrade to
> .22*.  Who is it you think it will fall to when .22 is out and those
> people have failing DB upgrades?  So I ask you again, what upgrade
> path do *you* intend to offer to those people to fix it?  The
> simplicity of the fix is unrelated to the brokenness of the
> implementation, so that's a moot point.

I'm not endorsing anything. The people who would add HD-PVR support to
0.21-fixes would have to compile myth themselves.

> So will you be handling all those support requests, then?  Will you
> provide a .22-JYA package that adapts the DBcheck.cpp to un-break the
> breakage you've endorsed?

The information on how to upgrade to the future 0.22 from the HD-PVR
backport is all in the mythtv wiki
I only compiled existing information.

> You are choosing to read selectively here.  You are including lots of
> other people's patches which most definitely *have* caused real issues
> for people, and on which I and others have wasted our time.  You not
> believing it and it being untrue are totally unrelated.

Most of the patches from others I've included in mythtv actually made
their way into trunk or were provided in the original mythbuntu
distribution.

Here is the list of patches I apply to my build:
02_settings.pro.dpatch - Original Mythbuntu patch
08_default_directory.dpatch - Original Mythbuntu patch
09_perl_bindings_prefix.dpatch - Original mythbuntu patch
10_mythfilldatabase_log.dpatch - Original mythbuntu patch
11_add_myth_prime.dpatch - Original mythbuntu patch
12_add_firewire_tester.dpatch - Original mythbuntu patch
16_hal_shutdown.dpatch  - Original mythbuntu patch
23_video_device_symlinks.dpatch  - Original mythbuntu patch
24_fix_h264_frame_counting.dpatch - Original mythbuntu patch
29_fix_mythwelcome.dpatch  - Original mythbuntu patch
30_python26_transition.dpatch - Original mythbuntu patch for Jaunty only
40_openglmod.dpatch - Mark Kendall's OpenGL mods, which have been in
mythtv-vid branch in a very long time and made their way to trunk
several month ago.
41_vdpau.dpatch - the infamous vdpau backport
44_audioencoder.dpatch - ticket 5900, AC3 upmixer with a lot of personal mods
45_softvol.dpatch - ticket 6279, provide software volume for AC3/DTS passthrough
#46_hdpvrsupport.dpatch, compilation of the changes in mythtv wiki,
provided but not applied
50_audiooutput.dpatch - Add entries to the list of default audio, make
it easier to set up sound over hdmi
51_mpegps.dpatch - This is a backport of the mpegps change in trunk,
and is often referred to when people can't play some media in 0.21
54_fix_video_fallback.dpatch - Original mythbuntu patch
55_skiploop_option.dpatch - Original mythbuntu patch, adapted to work
after vdpau backport
60_fixes-latm-aac.dpatch - Add LATM/AAC support, this is required to
watch any FTA in New-Zealand and other
61_pythonbindings.dpatch - Add entries to the python bindings to work
with some mods I made on imdb/tmdb (in mythplugins)
94_browse_alltuners.dpatch - Original patch Ronald Frazier patch,
merged in trunk. The one I'm running is a backport of the change in
trunk, rather than the original patch from Ron
95_osd_fcnfont.dpatch - same as above
96_MePo_theme.dpatch - Just the MePo theme..


> It matters because neither they nor you are suited to make decisions
> about what should and should not be called "stable" MythTV.  Nobody is
> preventing you from distributing JYA-TV.  Just *don't* call it MythTV
> and most importantly, don't delude yourself or others into believing
> that it's "stable" MythTV.  That's a farce.

I'm fairly confident it is as stable as the 0.21-fixes code.
> Not my house, but at least I know how to live in it without taking a
> dump on the couch and wiping myself with the curtains.

:)

Except following your analogy, the dump was already there before I
came in, I provided a new sets of toilets but no one wants to use
them.


> Not having commit access and not having plenty of code in myth are two
> entirely different things.  I have plenty in there, and I don't *need*
> commit access to feel a certain ownership and investment in the code

Obviously you do, as you love reminding people on who you are, how
much code you've provided etc...

> "uprightness" of this project.  I *like* that the devs take a strong
> stance against stealing.  And when people decide to chime in about how

We had this discussion in the past.. This isn't stealing, at worse a
copyright infringement.

> some rule that is designed to protect people who *do* have code in
> real MythTV, I take issue with that.  I like the Myth devs, by and
> large, and I don't want the words or actions of someone who hasn't
> done a thing for the project to endanger them.  As always, the squeaky
> wheels are the ones who stand to lose *nothing* if someone comes after
> the project.

That's a fair point, I doubt that any of the doom you're talking about
will ever happen to mythtv.
Actually, one way to protect the dev better against any of this would
be for them to open slightly more their code to modifications. It
becomes impossible to prove who did what.

> If you don't care, then by all means, continue with your current
> infallible attitude.

The fact that I'm responding to this (much more rational) message of
yours, show that I would like things to change.

Haven't had much success there.
Following your suggestion on getting a feel of where the myth devs
where going, I asked in the dev distribution like about what's next
and where they would like help with, I got no answer.

I don't like to stand still...