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

[Newbury]

Sent from my iPhone

On 2012-03-08, at 14:03, Paul Harrison <mythtv at sky.com> wrote:

> 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.
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-dev

Yes if it not a comedy then it must be a tradgedy, and then you have to cry.
G