Posting manually since Google Groups doesn't seem to like my ProtonMail E-Mail:
I think we are looking at a couple different discussions here: - Module Quality - Code Quality I think the former is always going to be difficult to track in any meaningful way, largely because expectations for what a module should or shouldn't do, or even the *how* it does something, is going to vary from person to person; org to org. On Module quality, I would say that the Forge should just take a page from the playbook of things like RubyGems, NPMJS, Pypi, etc and just track some combination of: - Homepage - Downloads - Likes/Stars/Forks on GitHub/Gitlab/BitBucket/etc - Open Issues - List of Files that are installed - List of manual downloads - Release history - Additional useful links On Code Quality, I think the following checks should be done: - Arrow Alignment - Indentation - Trailing comma (either have or don't have it - standardization is good) - All the checks included in https://github.com/voxpupuli/voxpupuli-puppet-lint-plugins/blob/master/voxpupuli-puppet-lint-plugins.gemspec For tests use badges for the following: - Unit tests with rspec-puppet - Acceptance/Integration tests with Beaker/Litmus/test-kitchen - A README - A generated REFERENCE.md from puppet-strings - Changelog that can be embedded into the Forge page Things that I find too subjective to use a markers for quality: - Use only vendor/OS provided packages: While I can see why some would want this, I personally have not worked at a place that could utilize OS provided packages for a lot of non-OS level software. Things like Nginx, Ruby, Go, Apache, PHP, etc tend to be too old even in Ubuntu to use for running applications and in most cases the OS packages/repos have turned into just what is needed to support running applications that contain or install their own requirements - either via containerization or vendor/project provided repositories. - Don't include binaries: This one is, for me, a hard no. With Modules that include Bolt tasks, you limit what kinds of tasks can be included or what languages those tasks can be written in which could be limiting as there are a lot in the Puppet community not interested in learning Ruby, but want their tasks to do work that can't necessarily be done by bash or powershell scripts. So allowing those users to built tasks in Go, Rust, etc is a no brainer, IMO. Thoughts? --- David Hollinger III Software Engineer WPEngine Sent with ProtonMail <https://protonmail.com/> Secure Email. On Friday, October 29, 2021 at 7:34:28 AM UTC-5 Trevor Vaughan wrote: > I've certainly got a few opinions. > > I think that the following are mandatory: > > - rspec-puppet tests (that pass) > - beaker, litmus, or test-kitchen tests (that pass) > - Critical path test coverage that matches your supported operating > systems (as much as is reasonable) > - Documented parameters (generated docs with puppet-strings should > pass) > - A reasonable README.md > - A generated REFERENCE.md > - A useful Changelog (however you do it) > - No embedded binaries > - Use vendor provided packages as a default > - A reasonable update period/response time to bugs > - No telemetry/phone home capabilities > - Fail closed/safe > > I think that the following are nice to have: > > - Arrow alignment > - Indentation > - Muti-node tests (for externally-facing services) > > I think that the following are largely pointless: > > - Line length checks > - Trailing comma checks > - Code coverage checks > - Taking time to add tests for trivial non-critial-path items just > makes it more difficult to refactor the module. Acceptance tests should > be > used for functionality. > > Trevor > > > > On Thu, Oct 28, 2021 at 4:33 PM Ben Ford <[email protected]> wrote: > >> Trick question, I know. Having strong opinions is part of why we do the >> work we do. So I'm hoping that many of you will help us out on this project. >> >> Some time ago, the Forge turned off the quality scores detail display >> because many of the warnings were confusing and frightening to less >> experienced Puppet users. And we didn't really have a good specification of >> what made quality code anyway. That's what I hope to improve on today, and >> we'd like to turn it back on with a better picture of each module's quality. >> >> Vox Pupuli has a meta-gem that defines a list of the puppet-lint checks >> <https://github.com/voxpupuli/voxpupuli-puppet-lint-plugins/blob/master/voxpupuli-puppet-lint-plugins.gemspec> >> >> that they use for their definition of a quality Puppet module. I'd like the >> Forge and Vox Pupuli to be in alignment here, and this seems like the best >> place to start. >> >> Do you have a favorite list of puppet-lint checks you use? Do you think >> they'd be useful as an ecosystem standard? Can you support that opinion >> with a cogent argument for it? Suggest it as a pull request and let's have >> that conversation. Together as a community we can all come up with a solid >> starting point as a standard definition of module quality. >> >> >> https://github.com/voxpupuli/voxpupuli-puppet-lint-plugins/blob/master/voxpupuli-puppet-lint-plugins.gemspec >> >> Thank you all for your help! >> >> -- >> Ben Ford >> @binford2k >> Ecosystem Product Manager >> > _._,_._,_ >> ------------------------------ >> Groups.io Links: >> >> You receive all messages sent to this group. >> >> View/Reply Online (#395) <https://groups.io/g/voxpupuli/message/395> | Reply >> To Group | Reply To Sender | Mute This Topic >> <https://groups.io/mt/86662086/1024671> | New Topic >> <https://groups.io/g/voxpupuli/post> >> Your Subscription <https://groups.io/g/voxpupuli/editsub/1024671> | Contact >> Group Owner | Unsubscribe >> <https://groups.io/g/voxpupuli/leave/4249677/1024671/629153198/xyzzy> [ >> [email protected]] >> _._,_._,_ >> >> > > -- > Trevor Vaughan > Vice President, Onyx Point > (410) 541-6699 x788 <(410)%20541-6699> > > -- This account not approved for unencrypted proprietary information -- > -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users/c26f1599-7288-49e5-85a9-43231746f576n%40googlegroups.com.
