(CAT-1248) ***REVERTED*** Update Published Name and Owner

[david22swan]

Gem is to be re-published under the name puppetlabs-puppet-lint in order to fully move it under the ownership of Puppet.
Author is not being touched.

Checklist

• 🟢 Spec tests.
• 🟢 Acceptance tests.
• Manually verified.

[ekohl]

This does mean everyone needs to update their gem requirements. Dependabot won't catch it either. Aren't you worried that a lot of people will stop updating their lint config?

Or will you publish an update to the old puppet-lint gem that depends on the new package and otherwise makes it a dummy package?

[bastelfreak]

I have the same concerns as ewoud. I think this will create a lot of confusion and work for maintainers with little benefit.

[davidsandilands]

@bastelfreak @ekohl I fully understand the concerns on this PR and its not a decision we took lightly. There has been a number of questions around ownership and code contribution standards for tools in Puppet and having a shared admin ownership of a key gem wasn't viewed as something we could continue to do. We greatly appreciate the contributions and work Rodjek (Tim) did to create the tools and have spoken to him before doing this but we really need the sort of structure and governance VOX has when we work collaboratively on tools and code.

We are going to raise a ticket in the next sprint to look to raise PR's against the modules we discussed with @bastelfreak that would be affected in the community at https://rubygems.org/gems/voxpupuli-puppet-lint-plugins
and https://rubygems.org/gems/puppet-lint/reverse_dependencies as well as reach out via blog, community and social posts to create awareness and do as much as we can to reduce impact.

[bastelfreak]

is that email address still correct?

[davidsandilands]

@pmcmaw is this the one you used?

[pmcmaw]

Yes I can confirm this email address is still correct as this is the one I had used to cha to Tim in June.

[bastelfreak]

Did someone test what happens when this gem is installed together with puppet-lint? They both provide the same cli tool, puppet-lint. Does that work?

[davidsandilands]

Did someone test what happens when this gem is installed together with puppet-lint? They both provide the same cli tool, puppet-lint. Does that work?

This is an excellent point we will confirm this.

[bastelfreak]

but we really need the sort of structure and governance VOX has when we work collaboratively on tools and code.

What about migrating the projects to Vox Pupuli?

[bastelfreak]

Is it planned to change the repo name as well to match the gem name?

[ekohl]

I'd also suggest that the gem name and namespace should match. And while you're at it, consider using underscores for the gem name.

[david22swan]

As to renaming the repo I don't think it's currently planned but it is something we've thought about.
For the use of underscores, it's a little late unfortunately as we have already begun publishing the new name.

[ekohl]

I'd say it's rather hostile to the community to push it through without reaching out and then when is legitimate feedback just keep pushing through.

[davidsandilands]

We're always going to have some friction in these debates but I really want to avoid language like hostile. The DevX team has put in a lot of work and consideration around development tools to focus on things working well for all users.

Naming debates are a nightmare at the best of times and its maybe something we should take up in the vox catchup meeting to discuss if there's any shared approaches we should use in future for naming guidelines around repos and gems?

[ekohl]

I do consider it as hostile because I don't feel like I'm being respected. It makes me less likely to get involved in contributing to Puppet.

In the last meeting I did suggest to open an issue where we could clearly discuss things. Now I see the trigger has been pulled. Either I missed that issue with a clear description of the plan, or it was never made.

A big question I now have is: who is going to update all the various plugins? What's the plan for that? Is there a risk where one plugin depends on puppet-lint but the other plugin depends on puppetlabs-puppet-lint?

I see PRs have been filed that end up pulling both old and new gems: puppetlabs/puppetlabs-stdlib#1403 (review). Since they live in the same namespace, how does that interaction work?

Overall I'm deeply disappointed in how this went. This is exactly why I maintain gha-puppet, voxpupuli-{test,acceptance,release}, modulesync and Beaker as opposed to PDK and Litmus: I don't want to rely on Puppet tooling when I can avoid it because its project management breaks things for me so often that it's less work to independently maintain a stack than to track what Puppet is doing. I'll leave it up to you to decide if that's hostile or not.

[davidsandilands]

The main reason I am pointing out the hostile part is it implies intent which is unfair, I understand you feel unheard on this issue but the team are working very hard on getting the tools in a good supportable state and to engage the community to develop further and I want us all to keep the language to reflect that good intent which we all have in Puppet community.

There have certainly been problems in the past but I do not feel the current DevX teams effort is reflects that. We have taken onboard the feedback on this issue and now run an active check on all our tickets in grooming to confirm should we raise a discussion with the community to avoid this kind of late engagement again.

Ultimately this issue was driven by a legacy ownership issue and while we do fully trust Tim(Rodjek) and appreciate his work, the current situation does not meet good ownership or contribution standards and was a priority for us to fix as we found it. This is something we are reviewing across our tools and modules to make sure ownership and contribution access appropriate.

To confirm we will be raising PRs for the dependencies looking at https://rubygems.org/gems/voxpupuli-puppet-lint-plugins and https://rubygems.org/gems/puppet-lint/reverse_dependencies and generally looking to support where we can and raise awareness to make this as painless as possible. We are fully open to suggestions on how we can support this better.

The key thing I want to reiterate is I am sorry you feel unheard or disrespected as one of my personal big aims since taking on this role as Product manager was to ensure we were not developing just for Puppet Enterprise / paying customers but we are engaged with the community for everyones greater success. As we are restarting some of the release processes there will undoubtedly be mistakes and lessons for us to learn but I hope you understand what we are trying to do and that we greatly value your contributions in the Puppet community.

[ekohl]

For what it's worth, #169 was exactly what I was talking about when I raised the namespace issue. Admittedly, I could have been more explicit about it but this was predictable.

While I don't see bad intent, it is poor management. Very disruptive changes are being pushed through while stakeholders are being ignored. This destroys trust, and after 10 years in the Puppet community I've been burned enough times by Puppet doing this that I've become skeptical.

These actions fracture the ecosystem. They erode trust. I can't get away from puppet-lint and rspec-puppet, but I've been looking at replacing puppetlabs_spec_helper, which means even less overlap between PDK tooling and what Vox Pupuli uses.

[davidsandilands]

but we really need the sort of structure and governance VOX has when we work collaboratively on tools and code.

What about migrating the projects to Vox Pupuli?

I wouldn't see us wanting to do this but again this is something not really defined about Puppet and VOXs approach as to when we want a module/tool to be Puppet namespaced v Vox namespaced and something we maybe should discuss in detail?