Puppet-lint renaming

[davidsandilands]

The puppet-lint gem published in https://rubygems.org/gems/puppet-lint currently has shared ownership with the original author. To ensure good contribution and maintenance standards we would propose republishing this gem in a new namespace.

Following initial discussions #158 we found issues with namespace clashes following an initial renaming to https://rubygems.org/gems/puppetlabs-puppet-lint which was investigated in #170

I am therefore opening this issue to discuss this need fully and address any community concerns before proceeding.

So with that I'd like to lay out what were suggesting now and make sure we aren't missing anything further.

To avoid a clash anywhere, gem, namespace etc and to drive consistency of repos we are planning to rename the gem, the binary and the repo to follow puppetlabs- , we thought dropping the "puppet" part to avoid a long name and keep consistency with the forge and associations of puppetlabs with puppet inc and puppet with the community.

Our current proposal would be to rename accross binary, repo and gem as followis

Repo rename: puppetlabs-lint
Binary name: puppetlabs-lint
Gem rename: puppetlabs-lint

Thoughts? Concerns? Feedback?

See related discussion

[baurmatt]

Just to clarify: Can't the shared ownership with the original owner just be removed? (Same for rspec-puppet)

[ekohl]

I don't understand. I managed ownership of multiple gems for Puppet for years and the removal of other owners absolutely doable - we only didn't do it for social reasons.

As far I understand, the original author doesn't want to be removed and Puppet can't just take it. So I'd put this under social reasons.

Now it this is valid or not, you can debate it. A lot of gems are already maintained by third parties. PDK pulls in lint plugins maintained by Vox Pupuli, which has a lot more maintainers outside of Puppet's control.

[davidsandilands]

That's correct and we generally we wouldn't want to force a transfer even if we could, we would always be looking to respect the authors contribution and rights.

The key point in these cases is while we are an open source company and ultimately don't have a final say and control over every thing we use and do in this case there is no contribution standard or oversight as there is with a 3rd party like Vox. Which is why were not comfortable leaving it like it is,

[baurmatt]

Why can't you implement contribution standards and oversight without touching the gem itself? 🤔 I don't feel that a well recognized and long term Puppet contributor like rodjek does any harm as co-owner of those gems. There are even other popular Puppet gems which have non-Puppet employees listed as owners 🤷

I just don't think it's worth the hassle the whole community has to go through when those gems are being renamed.

[davidsandilands]

I'm afraid that is just not possible. We would not have made this choice if it was as simple as that.

[kenyon]

@davidsandilands why? And why so unforthcoming about this?

[genebean]

Regarding renaming the binary, I don't think that should happen either. As far as I recall, nothing else has a binary with puppetlabs- as a prefix. Everything I can think of either has puppet as the prefix or face or simply drops the namespace from the binary's name. Some examples gems are puppet-strings, puppet-syntax, and puppet-resource_api. Some examples that show up as binaries and faces are the client tools (open source & PE): aka puppet-query / puppet query and the like.

[davidsandilands]

The issue is that we found namespace clashes as per #170

[tuxmea]

The issue #170, does not mention that a renaming of the binary is required.
I also prefer to stay with puppet-lint.

[ekohl]

As for the binary: I think this is what various tools use. I haven't looked at how the various language servers are implemented, but that part of the ecosystem is crucial IMHO. I rely on my editor to flag issues while I'm working and nowadays rarely invoke puppet-lint manually.

As for CI: there we rely on rake lint.

[GSPatton]

Our reasoning behind suggesting a rename of the puppet-lint binary was to avoid clashes with the "old" binary which current users of puppet-lint will have installed on their systems. Would it cause less inconvenience to leave the binary name as puppet-lint and leave it up to users update their puppet-lint installations/configurations?

Of course, if we went in this direction we would make the error that this would induce clear via blog posts etc and provide support. But unfortunately we would not be able to add a warning message to the new gem alerting users to this.

[genebean]

This is also going to break all the puppet-lint plugins, or at least mean they are now all really inaccurately named.

[davidsandilands]

Our intention is to follow up raising PRs into the dependencies we could see at https://rubygems.org/gems/puppet-lint/reverse_dependencies to minimise impact in the community

[davidsandilands]

So I want to summarize the points taken on each of the discussions and our future actions.

We are aware this change is frustrating for everyone and these sort of rename changes have risks but this wasn't a project we could transfer or where there was an active partnership we could make to justify the joint ownership.

We are using the puppetlabs- approach since that maintains some level of consistency with the forge.

We believe renaming the binary is the right thing to do to avoid potential clashes and the confusion of having an old and new gem but with the same binary name. Although we are aware historically binaries were more likely to use puppet with this generally masked by use of the pdk and rake this should hopefully be a minimal disruption and inconsistency

We are aware we could have started these discussions earlier and have updated our ticket grooming process to reflect that. We will also be raising PRs into dependencies to try and reduce work for the community making the change.

I appreciate not everyone will be entirely happy with the naming outcome and potential disruption but we hope applying a consistent approach will reduce disruption in future. I really appreciate everyones input on this to help us see all available options.

[ekohl]

We believe renaming the binary is the right thing to do to avoid potential clashes and the confusion of having an old and new gem but with the same binary name. Although we are aware historically binaries were more likely to use puppet with this generally masked by use of the pdk and rake this should hopefully be a minimal disruption and inconsistency

Please also consider editor integration. Just one example I rely on is vim-ale:

https://github.com/dense-analysis/ale/blob/53b01d6a546384a28f1ccbed41baae58d7341da4/ale_linters/puppet/puppetlint.vim#L4

I imagine VSCode and other editors have similar places that rely on the binary.

[alexjfisher]

and here https://github.com/declarativesystems/onceover-codequality/blob/39c83798063d0a62d54393210d07be5e31363e67/lib/onceover/codequality/lint.rb#L36

[bastelfreak]

@davidsandilands should we reopen this? You mentioned the team will test gem releases to github and use that as source for pdk. If that works it could be an alternative to the renaming?

[davidsandilands]

@bastelfreak I think fortuntely commenting is enough to reopen :-) and I agree @gavindidrichsen @jordanbreen28 and co have been doing a hack day today to test the idea discussed on the vox meeting of releasing a gem in github and packing that in PDK so that we can maintain a secure pipeline for PDK packaging while at the same time still publishing to rubygems with the understanding of the ownership there.

We will come back with findings of hack day and confirm direction

[bastelfreak]

An idea that @ekohl had: puppet also publishes the facter gem to https://downloads.puppet.com/, maybe that's an additional place where puppet-lint should be published to.

[jordanbreen28]

@bastelfreak @ekohl
Thank you all for your contributions and patience on this matter, think we are all in agreement that it has been a rocky road.
We are going to continue publishing the gem at https://rubygems.org/gems/puppet-lint (this applies to rspec-puppet as well).
We will publish a separate GitHub package for each gem under the GitHub ruby gems registry. This way we can have a source for the gem which we have true ownership of and cause minimal to no disruption for the community.
We are working to rectify this and anticipate this will be done in the coming days.
Thanks again for all your help on this one and helping us bring this to a conclusion.

[bastelfreak]

Thanks for the feedback. Are the plans to publish to downloads.puppet.com, like you do it for facter?

[jordanbreen28]

@bastelfreak not at this moment and time, but it is something we are considering.