[mythtv] [mythtv-commits] mythtv commit: r25364 - in branches/release-0-23-fixes/mythtv by gigem

Chris Pinkham cpinkham at bc2va.org
Sun Jul 18 01:30:31 UTC 2010


* On Sun Jul 18, 2010 at 10:17:52AM +1200, Robin Gilks wrote:
> That being the case then why not just leave it broken until 0.24. Now if I
> move beyond r25364 I'll have to update *ALL* my backends and frontends
> which I've never had to do on a fixes branch before and its a PITA since
> they are different processor families with different video drivers that
> can't use a common config across boxes.
> 
> Perhaps now is a good time to move to trunk since fixes exhibits the same
> level of stability :-(

Since you're compiling from source, you always have the option of reverting
the related changesets in your local checkouts and living with the bug.

A lot of people on the other side of the fence would rather have a working
version even if it comes with a little inconvenience.  You don't have to
compile MythTV with the latest and greatest compile options or architecture
settings.  I use a common compiled version across everything from P3-733
boxes to VMs to a semi-recent Core Duo.

If you're upset about having to recompile everything now, you'd be
shooting yourself in the foot if you ran trunk.  Please stay away from
that.  I think we've updated the binary API version 10+ times over the
past few weeks, requiring a full recompile each time.  -fixes sounds
much more stable than that. :)

As Raymond stated, we do prefer not to update the binary or protocol
versions in the -fixes branches, but with out shorter release cycles,
it may be required at some points in the future.  A lot of people aren't
going to want to upgrade their systems 2-3 times a year unless they are
looking for new features, so we may decide to push out certain changes
to -fixes to make it more stable and bug-free.

--
Chris


More information about the mythtv-dev mailing list