Mailing List Archive: MythTV: Dev

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

Index | Next | Previous | View Threaded

mythtv at sky

Mar 7, 2012, 3:37 AM

Post #1 of 13 (435 views)
Permalink

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

On 06/03/12 20:53, MythTV wrote:
> Author: Gavin Hurlbut <ghurlbut [at] mythtv>
> Change Date: 2012-03-06T12:51:02-08:00
> Push Date: 2012/03/06 12:53:16 -0800
> Repository: mythtv
> Branch: master
> New Revision: fd1800a11f041b63a3d7dc6365155b79529a99fa
> Changeset: https://github.com/MythTV/mythtv/commit/fd1800a11
>
> Log:
>
> Remove --logfile and -l parameters
>
> As there is no need to use --logfile anymore (use syslog functionality instead)
> and to force the update of old startup scripts that use -l (also for logfile),
> these command-line parameters have been removed.
>
> Modified:
>
> mythtv/libs/libmythbase/mythcommandlineparser.cpp
>

There's going to be a lot of angry user wondering why there BE wont
start up only to find it's complaining about an unknown --logfile
command. Seem like a very strange decision to knowingly break peoples
setups.

Paul H.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

stuart at tase

Mar 7, 2012, 4:01 AM

Post #2 of 13 (425 views)
Permalink

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

On Wednesday 07 Mar 2012 11:37:02 Paul Harrison wrote:
> On 06/03/12 20:53, MythTV wrote:
> > Author: Gavin Hurlbut <ghurlbut [at] mythtv>
> >
> > Change Date: 2012-03-06T12:51:02-08:00
> >
> > Push Date: 2012/03/06 12:53:16 -0800
> >
> > Repository: mythtv
> >
> > Branch: master
> >
> > New Revision: fd1800a11f041b63a3d7dc6365155b79529a99fa
> >
> > Changeset: https://github.com/MythTV/mythtv/commit/fd1800a11
> >
> > Log:
> >
> > Remove --logfile and -l parameters
> >
> > As there is no need to use --logfile anymore (use syslog functionality
> > instead) and to force the update of old startup scripts that use -l
> > (also for logfile), these command-line parameters have been removed.
> >
> > Modified:
> > mythtv/libs/libmythbase/mythcommandlineparser.cpp
>
> There's going to be a lot of angry user wondering why there BE wont
> start up only to find it's complaining about an unknown --logfile
> command. Seem like a very strange decision to knowingly break peoples
> setups.

Agreed, this is going to break all existing init scripts.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

blazej.lewcio at googlemail

Mar 7, 2012, 5:05 AM

Post #3 of 13 (418 views)
Permalink

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

Confirm, I had already to look for reasons why the backend does not start,
and fix the init scripts.

mtdean at thirdcontact

Mar 7, 2012, 9:42 AM

Post #4 of 13 (417 views)
Permalink

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

On 03/07/2012 07:01 AM, Stuart Morgan wrote:
> On Wednesday 07 Mar 2012 11:37:02 Paul Harrison wrote:
>> On 06/03/12 20:53, MythTV wrote:
>>> Author: Gavin Hurlbut<ghurlbut [at] mythtv>
>>> Change Date: 2012-03-06T12:51:02-08:00
>>> Push Date: 2012/03/06 12:53:16 -0800
>>> Repository: mythtv
>>> Branch: master
>>> New Revision: fd1800a11f041b63a3d7dc6365155b79529a99fa
>>> Changeset: https://github.com/MythTV/mythtv/commit/fd1800a11
>>>
>>> Log:
>>>
>>> Remove --logfile and -l parameters
>>>
>>> As there is no need to use --logfile anymore (use syslog functionality
>>> instead) and to force the update of old startup scripts that use -l
>>> (also for logfile), these command-line parameters have been removed.
>>>
>>> Modified:
>>> mythtv/libs/libmythbase/mythcommandlineparser.cpp
>> There's going to be a lot of angry user wondering why there BE wont
>> start up only to find it's complaining about an unknown --logfile
>> command. Seem like a very strange decision to knowingly break peoples
>> setups.
> Agreed, this is going to break all existing init scripts.

The problem is that if these users don't fix their init scripts to use
--logpath, their setup is broken, anyway. With --logfile, the program
is told it can write to the specified log file and only the specified
log file. Since the new logger no longer puts messages from child
processes into the same log file, that means that there is no logging
for the child processes.

Logging to the same log file results in confused bug reports where
people say things like, "Master backend locks up with invalid protocol
version," (where, in fact, some child program--like
mythpreviewgen--called by the master backend tried to connect to the
master backend and got the invalid protocol version message, but it got
thrown into the master backend log, so the user thought the master
backend was saying the protocol version had somehow become invalid).

The decision was made that if the user specified a log file, they were
not providing permission for us to write to other files in the same
directory. Therefore, unless users run with --logpath, they are not
getting proper logging, and we'll be left with a lot of angry users
wondering why their previews and commercial detection and transcoding
and metadata and ... aren't working--but with absolutely no way to find
out because they don't know they're using a broken log option.

This seems like the approach that is most likely to help them notice the
configuration is broken and fix it. And, FWIW, it seems that the
approach works--we've already had one user (Blazej) report that he was
"inspired" by this commit to fix his start script. :)

And, to paraphrase a smart developer's comments in IRC, if a user is
experienced enough to compile MythTV and write his own start scripts, he
should be experienced enough to know to test running the program in a
terminal to see any errors when it fails to start in the start script,
and experienced enough to edit the start script. If the user is using a
packaged version of MythTV, the packagers should be providing working
start scripts that work and that use proper logging (i.e. like Ubuntu
provides a script that starts MythTV and uses the syslog logger).

So, if we release 0.25 with --logfile allowed, users will be lacking log
output that they'll need to figure out why things don't work.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Mar 7, 2012, 3:37 PM

Post #5 of 13 (404 views)
Permalink

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

On 8/03/2012 4:42 AM, Michael T. Dean wrote:
> On 03/07/2012 07:01 AM, Stuart Morgan wrote:
>> On Wednesday 07 Mar 2012 11:37:02 Paul Harrison wrote:
>>> On 06/03/12 20:53, MythTV wrote:
>>>> Author: Gavin Hurlbut<ghurlbut [at] mythtv>
>>>> Change Date: 2012-03-06T12:51:02-08:00
>>>> Push Date: 2012/03/06 12:53:16 -0800
>>>> Repository: mythtv
>>>> Branch: master
>>>> New Revision: fd1800a11f041b63a3d7dc6365155b79529a99fa
>>>> Changeset: https://github.com/MythTV/mythtv/commit/fd1800a11
>>>>
>>>> Log:
>>>>
>>>> Remove --logfile and -l parameters
>>>>
>>>> As there is no need to use --logfile anymore (use syslog functionality
>>>> instead) and to force the update of old startup scripts that use -l
>>>> (also for logfile), these command-line parameters have been removed.
>>>>
>>>> Modified:
>>>> mythtv/libs/libmythbase/mythcommandlineparser.cpp
>>> There's going to be a lot of angry user wondering why there BE wont
>>> start up only to find it's complaining about an unknown --logfile
>>> command. Seem like a very strange decision to knowingly break peoples
>>> setups.
>> Agreed, this is going to break all existing init scripts.
> The problem is that if these users don't fix their init scripts to use
> --logpath, their setup is broken, anyway. With --logfile, the program
> is told it can write to the specified log file and only the specified
> log file. Since the new logger no longer puts messages from child
> processes into the same log file, that means that there is no logging
> for the child processes.
>
> Logging to the same log file results in confused bug reports where
> people say things like, "Master backend locks up with invalid protocol
> version," (where, in fact, some child program--like
> mythpreviewgen--called by the master backend tried to connect to the
> master backend and got the invalid protocol version message, but it got
> thrown into the master backend log, so the user thought the master
> backend was saying the protocol version had somehow become invalid).
>
> The decision was made that if the user specified a log file, they were
> not providing permission for us to write to other files in the same
> directory. Therefore, unless users run with --logpath, they are not
> getting proper logging, and we'll be left with a lot of angry users
> wondering why their previews and commercial detection and transcoding
> and metadata and ... aren't working--but with absolutely no way to find
> out because they don't know they're using a broken log option.
>
> This seems like the approach that is most likely to help them notice the
> configuration is broken and fix it. And, FWIW, it seems that the
> approach works--we've already had one user (Blazej) report that he was
> "inspired" by this commit to fix his start script. :)
>
> And, to paraphrase a smart developer's comments in IRC, if a user is
> experienced enough to compile MythTV and write his own start scripts, he
> should be experienced enough to know to test running the program in a
> terminal to see any errors when it fails to start in the start script,
> and experienced enough to edit the start script. If the user is using a
> packaged version of MythTV, the packagers should be providing working
> start scripts that work and that use proper logging (i.e. like Ubuntu
> provides a script that starts MythTV and uses the syslog logger).
>
> So, if we release 0.25 with --logfile allowed, users will be lacking log
> output that they'll need to figure out why things don't work.
>
>
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.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

gjhurlbu at gmail

Mar 7, 2012, 4:40 PM

Post #6 of 13 (403 views)
Permalink

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

On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
<michael [at] thewatsonfamily> 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 :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

michael at thewatsonfamily

Mar 7, 2012, 6:51 PM

Post #7 of 13 (400 views)
Permalink

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

On 8/03/2012 11:40 AM, Gavin Hurlbut wrote:
> On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
> <michael [at] thewatsonfamily> 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 :)
>
I dont like the concept of intentionally breaking a system, whether the
required fix is documented or not. Just the opinion of someone that has
worked in support for many years. (Why create additional support load
when it can be avoided)

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

newbury at mandamus

Mar 8, 2012, 8:51 AM

Post #8 of 13 (392 views)
Permalink

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

On 03/07/2012 07:40 PM, Gavin Hurlbut wrote:
> On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
> <michael [at] thewatsonfamily> 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 :)

Both viewpoints to this are to a certain extent correct. The developer
should not HAVE to tell the user that things have changed. But the user
properly notes that 'lots of users' (meaning himself *and probably me
too*) don't RTFM until things are *noticeably* broken.

The answer is to use a mechanism similar to the mythtv-setup schema
upgrade notice: when the user fires up/tries to fire up the frontend
with the WRONG command line entries on the backend or frontend, it
should tell him what to fix, explicitly. And that there will be NO
logging until that is done. And a 'Do you want to continue?' etc.

In the meantime, the backend *should not break*. It should continue to
work as previously expected. Whether you want to use a semaphore or
database setting to control how many times the backend will start, or
just leave it as a 'nag' before the change must be made is another question.
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.

My $.02 worth (no HST is exigible upon this supply of intellectual
property pursuant to Schedule VI, Part V, section 10 of the Excise Tax
Act, Canada).

Geoff

--

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

kenni at kelu

Mar 8, 2012, 9:52 AM

Post #9 of 13 (390 views)
Permalink

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

2012/3/8 R. G. Newbury <newbury [at] mandamus>

> On 03/07/2012 07:40 PM, Gavin Hurlbut wrote:
> > On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
> > <michael [at] thewatsonfamily> 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

mythtv at sky

Mar 8, 2012, 11:03 AM

Post #10 of 13 (385 views)
Permalink

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

On 08/03/12 17:52, Kenni Lund wrote:
>
>
> 2012/3/8 R. G. Newbury <newbury [at] mandamus
> <mailto:newbury [at] mandamus>>
>
> On 03/07/2012 07:40 PM, Gavin Hurlbut wrote:
> > On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
> > <michael [at] thewatsonfamily
> <mailto:michael [at] thewatsonfamily>> 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
http://www.mythtv.org/mailman/listinfo/mythtv-dev

raymond at wagnerrp

Mar 8, 2012, 11:46 AM

Post #11 of 13 (388 views)
Permalink

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

On 3/8/2012 14:03, Paul Harrison wrote:
> 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.

No one has criticized FFmpeg for frequently changing the command line
parameters. When you want to add capabilities to such an expansive
application, you need to make changes. When you're a bunch of largely
independent programmers, working on a project without strictly
regimented controls, that's simply going to be the result.

The issue several devs complain about, and the very reason MythTV uses
its own internal copy of FFmpeg, is that different users are going to
run different versions of different distros, and they're all going to
end up with slight variances of ABIs and command line options. This was
a never ending problem for applications like nuvexport and other
external utilities that used the system's 'ffmpeg' binary for video
processing. Now that MythTV builds its own 'mythffmpeg' binary,
representing the internal version MythTV ships with, someone wanting to
write an external utility has a static target to program against, rather
than having to support each potential combination of MythTV and FFmpeg
version.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

stuart at tase

Mar 8, 2012, 1:58 PM

Post #12 of 13 (385 views)
Permalink

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

On Thursday 08 Mar 2012 14:46:00 Raymond Wagner wrote:
> On 3/8/2012 14:03, Paul Harrison wrote:
> > 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.
>
> No one has criticized FFmpeg for frequently changing the command line
> parameters.

I hate to disagree, but a few years ago there wasn't a month that went past
without someone cursing ffmpeg and damning their developers to hell for
changing their command line arguments yet again�. The fact that this hasn't
been the case lately is either because they stopped changing them� or because
various ancillary MythTV applications no longer depend on the ffmpeg binary as
they used to do.

� It happened so often that it wasn't funny, and what's worse is that they
were usually just renaming arguments, not changing the functionality in any
way)

� This is probably the case since it broke so many applications so frequently
that eventually they had to realise it was a bad idea.

Now all of the above is just about setting the record straight on ffmpeg, it
shouldn't be taken as a comment on our particular situation.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

newbury at mandamus

Mar 8, 2012, 5:38 PM

Post #13 of 13 (378 views)
Permalink

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

Sent from my iPhone

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

> On 08/03/12 17:52, Kenni Lund wrote:
>>
>>
>> 2012/3/8 R. G. Newbury <newbury [at] mandamus
>> <mailto:newbury [at] mandamus>>
>>
>> On 03/07/2012 07:40 PM, Gavin Hurlbut wrote:
>>> On Wed, Mar 7, 2012 at 3:37 PM, Michael Watson
>>> <michael [at] thewatsonfamily
>> <mailto:michael [at] thewatsonfamily>> 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
> 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
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads