This message was deleted.
# office-hours
s
This message was deleted.
b
ways to tag a release as a migration
what would this mean?
like the difference between a major and minor semver release?
l
so, puppetlabs/community moves a module to voxpupuli
b
ooooo
b
so so not only list in the old module "this was migrated to.." also list in the new module" this was migrated from..."?
l
yes
b
yes please
b
sort of like how github does forks
wrt to the backwards link
l
exactly, I'd love to differentiate between a forked migration and voluntary migration
b
and if it was a migration at all
b
that's something that keeps bubbling up and I think we're going to have to involve some of you in design conversations
like what the most effective and also least surprising experience
l
for a voluntary migration, I'd just redirect same way that github does for a moved repo
for a forked migration I'd say a "⚠️ <Other User> has marked that there may be a newer forked version of this module for community support"
b
a redirect is tricky when the new owner has a different understanding of semver and a new release in the new namespace breaks your setup
💯 1
this 1
b
I like that. An authoritative "that is the new version" and an informational only "I made this forked improvement"
l
I agree, but if it's a migration where both sides are in communication, I feel like the risks are lower
b
would also be nice if
puppet module list
would list modules as deprecated/migrated
this 1
🎉 1
l
and the people who can add that mark should be like Vox PMC and PuppetLabs Community Managers with some process for the CM to mark a migration between non-Vox entities
b
that seems easy enough to do. Right now we could add a deprecation marker.
b
also the right time to advocate for our rake tasks I guess: https://github.com/voxpupuli/ra10ke
maybe the whole
puppet module
thing should be deprecated
b
I think that
puppet module
needs to exist because the ability to list modules is a core feature. I'm ok moving advanced features out, kind of how some already moved to the PDK
l
there's a lot of documentation/howto built around
puppet module install
too
b
but in reality that's not used in most environments. It's quite slow and most people use code-manager or r10k or librarian-puppet
and the
puppet module build
face was already moved to a dedicated gem
I understand that
puppet module list
is helpful and I also use that often to check if all the dependencies from the different metadata.json files match up, but maybe that's some logic that should be moved to r10k/ra10ke and the face is just a wrapper around it
b
or at least a gem
b
yeah like the puppet-modulebuilder
(ra10ke is already an awesome gem)
l
if we're going that route, should r10k be vendored into puppetserver directly and ra10ke or something like it be merged in to provide a puppet facet for managing r10k?
b
maybe vendored into puppet, not puppetserver
l
sorry, I mean the aio packaging
b
not a bad idea. Well outside of my decision making though 😁
l
rather then the gem packaging
b
yeah
l
it isn't like 90+% of users aren't using r10k
b
this is quite the thread lolwut
semi related, have I ever shown you this POC? https://prod.puppet-sneakernet.k8s.puppet.net
b
brings up the question again why r10k is kinda deprecated/not activly supported
this 1
oh neat. that's new to me
l
it seems like an obvious thing to just include as batteries (r10k)
and maybe? once?
b
the sneakernet "fork me" link is broken, btw. https://github.com/puppetlabs/puppet-sneakernet
b
https://prod.puppet-sneakernet.k8s.puppet.net looks like our new beaker_puppet_helpers, just as a web UI
b
I'm talking with edwin about potentially integrating it so that becomes a Forge API. No promises on that though.
wrt to r10k, I do believe we're getting more attention on it soon. It's not clear what that attention will be though.
b
expect for arching the repo, I'm happy with every attention
also given the PE support tickets I created I assume someone will work on r10k