On Thu, 24 Jun 2004 13:17:29 -0400
Garance A Drosehn <[EMAIL PROTECTED]> wrote:

> At 4:14 AM -0400 6/24/04, [EMAIL PROTECTED] wrote:
> >hello all,
> >
> >I have recently been mulling over an article which proposes
> >an abridged set of steps for updating the system.
> >
> >-----------
> >http://www.bsdnews.org/03/bsd_update.php
> >
> >alias rebuild   'cd /usr/src && make update && make world &&
> >                  make kernel && mergemaster'
> >-----------
> >
> >in a nutshell, the author proposes the following steps:
> >
> >1) rebuild
> >2) answer the mergemaster prompts
> >3) reboot
> >4) all done

hello all,

first of all, thank you for the thoughtful feedback.

i'm actually not trying to be lazy or cut corners here, i was just trying
to understand the risks involved with the process advocated by this author.
all in all, you've pretty much confirmed what i had suspected. 

> We have a list of steps which we believe to be reliable.  We have
> absolutely no reason to add in steps "just to annoy you".  We are
> just as eager to have a quick system rebuild as anyone else would
> be.  You can often get away with skipping some of those steps, but
> if you DO skip them, then YOU are responsible when something does
> go wrong.  And sooner or later, it will go wrong.  You can bet on
> it.  You should expect it.  By that I mean, *when* something does
> go wrong, then you should immediately suspect that the problem is
> due to your procedure.  You should not "forget" that you have
> refused to follow the recommended procedure, and you should not
> come yelling at anyone else because "they broke your system".
> In the case of this author, he is tracking the 4.x-stable branch.

the website provides tips on running fbsd and, given the reaction here,
this particular article is likely not the best advice over the long-term.

i am planning to drop the author a line linking to this thread.  perhaps
he'd consider revising the text or adding a brief warning, so that no
hapless newbs end up getting burnt.

once again, thank you all.
> At this point in time, that branch sees very very little activity,
> and because of that his strategy has probably worked quite well
> for him.  However, it will not work as well on the -current branch.
> And very soon we will be moving to 5.3-stable as "the stable
> branch", and after we do then his strategy is much more likely to
> run into serious problems.  And when it does, it will be you with
> the broken system, and it may be that you will be the only one
> who will be able to fix whatever was broken.
> Think if it this way.  We have a list of steps that we document.
> If you want to use some alternate list, then what makes you think
> we will test *our* changes with *your* alternate strategy?  We
> will not.  Sooner or later, something will break.  On the one
> hand we will feel bad for you, but on the other hand we can not
> help you if you refuse to follow the steps that we have found to
> be the most reliable.
> Yes, it is tempting to take shortcuts.  But sooner or later you
> will be burned by taking them.
> -- 
> Garance Alistair Drosehn     =      [EMAIL PROTECTED]
> Senior Systems Programmer               or   [EMAIL PROTECTED]
> Rensselaer Polytechnic Institute;             Troy, NY;  USA
[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to