Sorry for falling behind on this thread. I've been working away on items for PUP-536 (PUP-1118 specifically) and am now incredibly behind on email.
On Fri, Jan 17, 2014 at 5:48 PM, Jason Antman <[email protected]> wrote: > 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. > > I'd be fine with non-PL committers. Partly this is selfish because we struggle to keep up with all of the changes that are wanted, and it would free us up to work on some more radical changes that we've had ideas about for a while (several have shown up in threads here). I think if someone is a committer they should be trusted enough to make appropriate changes and get the necessary review. If it becomes a problem we can always revoke access (although that would be a pretty extreme action, I think). > 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. > > Yes, docs.puppetlabs.com is already very good. We just need to keep working on it and make it the most commonly found source so that as changes happen, the documentation that people find reflects the current state of affairs. This doesn't stop people from putting together guides and blog posts about ideas they try out and good practices that they find, but it might reduce confusion from finding out of date information. > -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 [email protected]. > 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. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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/CANhgQXsv5ow9i%2BU7oUbCXn22mrHOog_KprCQXf5RpPU-CeBirQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
