[mythtv-users] Patching .21-fixes for HDPVR

[Brad DerManouelian]

On Dec 25, 2008, at 8:10 AM, Michael Tiller wrote:

> Don't worry, I understand that you are trying to reign in the chaos  
> that such a situation could create and to prevent it from being a  
> distraction for others.  I certainly didn't take this as a personal  
> thing.
>
> I really have just two comments.
>
> First, I'm confused because as the maintainer of the HD-PVR page,  
> there is a whole section titled "Steps to Add the HD-PVR as a  
> Capture Device in MythTV" that discusses applying patches.  It isn't  
> clear to me why that section is superior to the patch set I  
> referenced (they may even be the same).  Do those patches not  
> trigger DB issues?  Should they be considered a preferred  
> alternative to the route I was looking at?

These are steps if you are running code from trunk which already has  
the database changes in it. Once you upgrade to this schema, there is  
no going back to the stable release code. It's a really big commitment  
and definitely not good in a production environment.

> Second, this is a very interesting situation and I wonder what we  
> could learn from it.  On the one hand you have the trunk which has  
> all this nice functionality but there are "danger" signs posted  
> everywhere about using it.  There is also a very strongly vibe from  
> the developers (and *understandably so*) about non-developers  
> venturing into the trunk.  I can appreciate the trouble that causes  
> and so I agree nobody should take that route lightly.
>
> On the other hand, you have a strong sentiment to not provide a back- 
> port of these features to 0.21.  Philosophically, I can understand  
> this approach as well (not wanting to move backward but rather  
> forwards).  But this closes off another potential avenue to users.

Just like Adobe doesn't backport new features from Creative Suite 4 to  
people who have Creative Suite 3. It's not just to get them to spend  
money to upgrade. It's extremely difficult and often impossible to  
make features work in previous releases. The side-effect of open  
source software is that people see code and features long before they  
are ready.

> Finally, you have the people who (for example, with these patches)  
> are trying to "make due" until a new release by coming up with a  
> kludge applies "on the side".  This approach is also frowned upon  
> (for reasons you pointed out).
>
> The result of this situation is that it seems to create tension  
> between the developers who, naturally, want to focus on moving  
> things forward rather than hand holding and users who, naturally,  
> want to get the most of out their system.  The downside of this  
> situation is that you have users with lots of enthusiasm for the  
> overall project and a willingness to spend not insignificant amounts  
> of money on putting together systems met with what probably feels to  
> many like a sentiment of "sit down, be quiet and wait for the next  
> official release".  I want to be clear that I don't see anybody at  
> fault here but it just seems like a shame to be in such a situation.

I'm not a developer, but I do follow the -dev and -commit lists and  
have a good understand of where the code is and the stuff that is  
broken. I also have a machine dedicated to development that I try new  
code out on before moving it to my production machine. Even with that  
safeguard, I've had my myth box down for a day or two while sorting  
through issues. My family isn't happen when it happens, but it happens  
often enough for them to ask, "Is Myth working?" before grabbing the  
remote. That should be some indication of what you get yourself into  
when you run unstable code from trunk. If the -users list started  
popping up with questions every time a situation like that occurred in  
my house I'd be kicked off the list for sure.

> So the question is...is there any strategy we could follow that  
> would avoid this situation and make things easier for both parties.   
> I'm not sure there is but I figured it was worth considering.

Don't upgrade until the next release. If you do, move to trunk (not  
some hack) and deal with the issues there. Don't ask the -dev or - 
users list when something is broken. Instead, consult with trac and/or  
figure out how to fix it or move back to a version before the problem  
exists (and deal with whatever problems that version has).

> I'm still not sure where this leaves me... :-(

It leaves you with hardware that is not yet supported, but will be  
when it all works correctly. I had my HD-PVR for about 3 months before  
I even plugged it in. I waited for the code to be stable enough (in my  
opinion) to start using it. In return, I sacrificed a lot of  
functionality on my box that was broken (I still can't get MythWeb to  
work since moving to QT4, MythNews is a no-go as well since it's tied  
to MythWeb, Parental controls in MythVideo don't work, lots of the UI  
was broken but is slowly getting better, I get segfaults every week or  
so, etc, etc.).

The bottom line - the put it bluntly - is that your impatience is not  
our problem. Go ahead and upgrade to trunk, but don't bother us with  
the problems you run into.