Re: Deepak's message about community maintainers... that sounds wonderful to me. I'm not sure they'd even need commit access, perhaps it would be feasible to operate on a model where all PRs against a given provider are handled by a maintainer, and once they sign off a PL employee does the merge. That would allow the burden of triage and review to be handled by a community maintainer, while still allowing someone @puppetlabs.com to have the final approval/commit.
On 01/15/2014 07:01 PM, James Turnbull wrote: > I think this is a broadly good idea but I've got one concern about the > on ramp to using Puppet. Whatever is done, pull out some/pull out all, > the user experience of getting started with Puppet should remain > seamless or at least as good as it is now. For example, if there's > suddenly another step to get started with Puppet, i.e.: > > 1. Install Puppet. > 2. Add resources. > 3. See Puppet in action. > > Then I think the getting started user experience suffers. Especially > with so many tutorials out there that just assume various resources will > be available. If the user gets some esoteric error (Dog forbid Puppet > having an esoteric error :)) when they try to run a local .pp file or do > a puppet resource then that's a big turn-off. > > Puppet's learning curve can be steep for many users. Let's not make it > any harder. > > Cheers > > James > This also speaks directly to something that Pawel said... if PMT were a feature-complete tool, understanding things other than just the Forge (i.e. GitHub, arbitrary git URIs, internal Forge mirrors, etc.) and or'ed/fork requirements (i.e. "puppetlabs-stdlib >= 3.2.0 *or* github.com/jantman/puppetlabs-stdlib >= 3.2.1") ... and it was the de-facto method of managing modules, then I'd say (hand-waving implementation) there should be a list of modules that are "standard" (i.e. the previously-core parts), and if they're missing at puppetmaster start (or perhaps even at install-time), or puppet starts with an empty moduledir, the user is prompted (or a similar message is logged) to run "puppet module bootstrap" which would install a default list of modules. I'll admit I'm not sure how that would work with a simple one-off .pp file, but then again, I think the Forge is becoming ubiquitous enough that standalone .pp files with no external modules (aside from testing) should, hopefully, be less and less common. 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. -Jason -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/52D9DD53.8010009%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
