Becoming #PuppetApproved

[jfryman]

The folks at PuppetLabs just released a set of guidelines to become #PuppetApproved. This issue will track progress toward that goal.

Full spec can be found here: https://forge.puppetlabs.com/approved/criteria

Style

• must not produce warnings in puppet-lint when run with this configuration:

PuppetLint.configuration.fail_on_warnings
PuppetLint.configuration.send('relative')
PuppetLint.configuration.send('disable_80chars')
PuppetLint.configuration.send('disable_class_inherits_from_params_class')
PuppetLint.configuration.send('disable_class_parameter_defaults')
PuppetLint.configuration.send('disable_documentation')
PuppetLint.configuration.send('disable_single_quote_string_with_variables')
PuppetLint.configuration.ignore_paths = ["spec//*.pp", "pkg//*.pp"]

Documentation

• must have a README
• README should conform to documentation standards ((maint) Better docs #451)
• must document example usage in README
• should completely document classes, defines, parameters, and resources used in the example in the README

Maintenance & Lifecycle

• should be regularly maintained and have received updates in the last 6 months
• should not have more than 1 month gap between Forge and VCS
• should be contributed to by more than one person or organization

License

• must be licensed
• should be licensed under Apache, MIT, or BSD

Metadata

• must accurately express every required metadata field.
• must express compatibility metadata for Puppet/PE and OS versions module is compatible with. (metadata: add Puppet version compatibility #598)
• must accurately express issues_url and project_page metadata.
• should provide accurate information for every metadata field

SemVer

• must be versioned according to SemVer v1 rules
• must have candidate release >=1.x

Testing

• Should have rspec-puppet tests for manifests
• Should have acceptance tests, preferably written with the beaker framework
• Should have at least 1 unit test for each type, provider, fact, and function should have at least 1 unit test each (N/A - we have no types, providers, facts or functions)

Puppet Versions & Features

• Must not rely on experimental Puppet features (like the future parser or in-module hiera data)
• Must be compatible with the Puppet 3 and Puppet Enterprise 3 series.
• Should not directly call out to an ENC like the hiera() function for example.

[3flex]

For the "Style" section I'm assuming those settings don't have to be in Rakefile. Our .puppet-lint.rc already has:

--fail-on-warnings
--no-80chars-check
--no-class_inherits_from_params_class-check

so it's already more strict than those guidelines. The only missing one from that section is the second last item.

[jfryman]

@3flex Excellent! Let's check those off!

[3flex]

Well I spoke too soon, puppetlabs_spec_helper is broken so we actually weren't checking style violations. Waiting on puppetlabs/puppetlabs_spec_helper#78 for a fix but for now I have pinned to 0.8.0. Because there are some violations the build's now broken.

Also now it's actually running again I see a violation of the documentation check, so that actually should be disabled in our config per the guidelines. I've unchecked "added to CI tests" and "disable-documentation" from the checklist to reflect the current situation.

[danieldreier]

I'm not 100% sure, but I don't believe that modules depending upon module_data will be puppet approved.

Monkey patching core puppet effectively invalidates the acceptance testing suite. RI describes it as "... consider this a early feedback-saught release" in the readme, and there's no test coverage, so I'm not at all confident it's production ready.

I do really like the functionality module_data provides; I'm just skeptical that untested monkey patches will fly in module approval.

[jfryman]

@danieldreier yes, this is understood. I've already had some back-channel talks with the PuppetLabs team about puppet-module-data, and some of the ramifications of it. Haven't come to a clear decision, but this is a topic we're discussing.

[3flex]

@jfryman I've refreshed the list and updated with current status.

There are two remaining "musts":

• One in "documentation" section
• Candidate version must be >= 1.x

Let me know if you want assistance with anything. I will refresh #451 as well and comment there when I think you can reconsider merging.

I suggest opening a new ticket with a checklist for anything that should be done before 1.x.

[wyardley]

Docs is still a mess.
@bastelfreak: do we want to leave this open until we improve the docs? Are we concerned about being #puppetapproved?

[anarcat]

we are puppet approved now, so i'm just going to close this. there are separate issues (#1245, #451) for improving docs.