we differentiate between gems and modules. the guide above is written for modules

and we have https://github.com/voxpupuli/modulesync_config for modules but also https://github.com/voxpupuli/puppet-lint_modulesync_configs for puppet-lint plugins

since we rarely get gems migrated to us we don't have a guide for that

ok, thanks

I recommend at least three PRs: update readme/gemspec for the new owner/namespaces, drop EoL rubies from gemspec, run modulesync

can i get a review pls: https://github.com/voxpupuli/puppet-ghostbuster/pull/68

and for: https://github.com/voxpupuli/puppet-lint_modulesync_configs/pull/49? albeit i am not sure if something is not right here; this strikes me as odd during testing: - gem 'voxpupuli-rubocop', '~> 2.0' + gem 'voxpupuli-rubocop', '~> 1.1' and ghostbuster basically throws the whole spec_helper overboard... i am not sure i understand modulesync correctly 😕

https://github.com/voxpupuli/puppet-lint_modulesync_configs/blob/14bc93258193af797ac50983b49417c6fe0620f5/moduleroot/Gemfile.erb#L20 looks like that should be updated to 2.0

oh, you're also adding it to the wrong repo

https://github.com/voxpupuli/modulesync_config is the right one

as it is a rubygem/basically a lint-plugin it should be the lint module sync; shouldnt it? at least thats how i understood bastelfreak in our above conversation?

ewoud: voxpupuli-rubocop isn't for modules

it pulls in rubocop for ruby 2.7. voxpupuli-test brings in ruby 2.6 for modules

ah, maybe I should wake up first

ahh now i understand the discrepancy between modulesync rubocop version and the managed modules: dependabot automatic PRs are the culprit; gonna fix that real quick

https://github.com/voxpupuli/puppet-lint_modulesync_configs/pull/50 lets start with this, someone up for a review?

I think we should delete https://github.com/voxpupuli/puppet-lint_modulesync_configs/blob/master/moduleroot/.github/dependabot.yml.erb

if we manage the file via modulesync, then yes

yes

output: "ERROR: Permission to voxpupuli/puppet-lint-optional_default-check.git denied to zilchms.\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n" ööööhhhhhm, for a few repositories i can use msync update, and then there is cases like this. Last time i checked i was a member of the organisation and the repository is part of the org... i think i will take a break and get something to eat, modulesync causes me headaches : p

ewoud: Spritzgebaeck objections on granting the collaborators group write access to all puppet-lint plugins?

hmm tricky question - I'm always of the opinion that you should be conservative with granting people access

agreed

and lint plugin development is quite different from Puppet modules, as well as the potential impact

we can also do a new group and add zilchms

so I'd be in favor of keeping it two separate groups

two groups sounds good

perhaps collaborators should be renamed to collaborators/modules and then create collaborators/lint

or dashes if you want to keep it top level

or you can make it collaborators/gems if you want to say that anyone who works on gems (lint or otherwise) has sufficient base knowledge