[mythtv] [mythtv-commits] mythtv/master commit: fd1800a11 by Gavin Hurlbut (Beirdo)
kenni at kelu.dk
Thu Mar 8 17:52:08 UTC 2012
2012/3/8 R. G. Newbury <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> 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev