[mythtv] [mythtv-commits] mythtv/master commit: fd1800a11 by Gavin Hurlbut (Beirdo)

Paul Harrison mythtv at sky.com
Thu Mar 8 19:03:27 UTC 2012


On 08/03/12 17:52, Kenni Lund wrote:
>
>
> 2012/3/8 R. G. Newbury <newbury at mandamus.org
> <mailto:newbury at mandamus.org>>
>
>     On 03/07/2012 07:40 PM, Gavin Hurlbut wrote:
>     > On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
>     > <michael at thewatsonfamily.id.au
>     <mailto:michael at thewatsonfamily.id.au>>  wrote:
>     >> Why not place a message in file specified in --logfile of the
>     changes
>     >> required to fix the setup, and allow backend to carry on
>     without logging.
>     >
>     > Simple.  Most people will not look at the logs until something
>     breaks,
>     > so it may be months before they need the log files, and at that
>     point
>     > they don't have any.  Better to make part of the upgrade include
>     > making a conscious decision as to how you want the logs to be
>     stored,
>     > whether done by the user personally, or by the packagers that
>     bundled
>     > it up for the user.
>     >
>     > There is no need for extra command line arguments to tell you "you
>     > need to change this" when it will be obvious (and documented).  This
>     > is where RTF(ine)M comes in handy :)
>
>     In the meantime, the backend *should not break*. It should continue to
>     work as previously expected.
>
>
> When I make the decision to upgrade some software from one major
> version to another, I *expect* that a lot of stuff has changed (that's
> why it's a new major version) and that something probably needs to get
> fixed. When I just update with minor updates, say security- or
> bug-fixes, I expect the software to work with no action required from
> me. I don't consider my setup "broken" if I actively make the decision
> to upgrade my stable 0.24-fixes setup to a brand new and shiny 0.25
> release, and the backend doesn't start, as I'm giving it some obsolete
> argument....
>
>  
>
>     I can think of circumstances when you would NOT want the frontend to
>     fail to run on first launch, but merely announce the requirement for
>     change. (Proud mythtv user showing off setup to prospective accolyte:
>     'I've just upgraded the box to the new ,25 version.'  And getting it
>     running takes 5 minutes of script revision. VERY PROFESSIONAL. And
>     completely avoidable.
>
>
> If you're your own packager, eg. you compile MythTV yourself and you
> have created your own init scripts, you'll surely figure out how to
> fix it within a few minutes...either by RTFM or looking at the output
> from mythbackend. If you're not compiling MythTV yourself, your
> packager will already have fixed the init script.
>
> Even though this change was included a bit late in the release cycle,
> I still see it as a non-issue. Everyone who might not be capable of
> identifying the issue, will likely receive the MythTV package from
> some packager, who already has corrected the logging argument - the
> user will never notice.
>
> Best regards
> Kenni
>

Heh! I think it's really funny there's this big push to make Myth more
user friendly then we go and do something like this that deliberately
breaks many users systems. What makes it even funnier is many of the
devs supporting this have in the past criticized ffmeg for changing the
command line parameters each version. You've got to laugh :-D .

Paul H.



More information about the mythtv-dev mailing list