Migrating a module to Vox Pupuli Edit

Published on Jul 1, 2016.

You will have someone by your side in this process. The general flow is to…

  • Ask one of the Administrators to add you to the incoming-migrations team.
  • Prepare your repo for transfer
    • If this module was created with PDK delete .sync.yaml.
    • Ensure that the module has a correct LICENSE file in the docroot that matches the mentioned license in the metadata.json.
  • At this point you can transfer your own repository.
  • Ask an admin to
    • Ensure github issues are enabled.
    • Verify that all webhooks are disabled.
    • Enable Automatically delete head branches in the repository settings.
    • Add the collaborators team to the module’s Collaborators & Teams ‘Teams’ list with Write permissions (e.g. https://github.com/voxpupuli/puppet-gitlab/settings/collaboration (that link works only for admins).
    • Update the access permissions (that link works only for admins) for forge.puppet.com secrets so releases can be published.
  • Add the module to our modulesync setup.
  • Execute modulesync for this module.
  • Our modulesync will delete a CONTRIBUTING.md in the root directory and place one at .github/CONTRIBUTING.md. Please enhance our existing template if the version in the docroot contains useful parts.
  • Release the first version under Vox Pupuli.
  • Creata a GitHub issue for the FORGE project and ask to deprecate the old module (and approve the new one if the old one was approved as well).
  • Do you think the module qualifies to be approved? Wait until it is released, then raise a GitHub Issue in the Puppetlabs organisation.
  • Write a very short blog post about the migration(example). Write to our mailinglist about the migration/new blogpost.

If you have many modules you wish to migrate, this will be cumbersome. In this case we will generally create a separate group and give you administrator access to speed things up.

If you are interested in Vox Pupuli accepting a module that you do not own, the process has a few extra steps before beginning the checklist above. We do ask that you show that reasonable efforts have been made to engage the owner and they are unresponsive. If the owner has responded and is not interested in migrating their module to VP, it will be evaluated on a case by case basis. To start the process, document your request and efforts in a brief email to the mailing list. If the module is accepted, VP will work with you to determine the proper fork/migration steps needed in addition to the checklist above.