> I certainly agree with James' standpoint. However, as the set of people
> at $work who commit to our internal puppet modules expands, I'm
> constantly battling the vast amount of outdated information/tutorials on
> the 'net. Keeping backwards compatibility with tutorials and blog posts
> that never get updated (yes, I'm guilty of this myself) was already
> broken by deprecating dynamic variable lookups, puppetd, and a handful
> of other changes.
> 
> I'll raise a counterpoint that, instead of trying to maintain backwards
> compatibility with third-party docs, we should try to (a) make
> docs.puppetlabs.com such an authoritative and complete source that
> future tutorials will begin "first follow the Getting Puppet Setup doc
> at <url> and then....", and (b) try to do the right thing at install
> time and startup to detect this situation and offer the user a simple
> one-command method of installing a default/base module set.

I don't much care if Puppet from a tutorial (or theoretically books)
written several years ago doesn't work anymore. That's more an example
of one entry point to the issue. More importantly, and the key issue, is
if a user can't puzzle out how to use Puppet upon first touch.
Especially if it doesn't "just work" out of the box.

Regards

James

-- 
* The Docker Book (http://dockerbook.com)
* The LogStash Book (http://logstashbook.com)
* Pro Puppet (http://tinyurl.com/ppuppet2 )
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/52D9E7C9.80409%40lovedthanlost.net.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to