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…

  • Ensure you have been added as a member of the voxpupuli org on github.
  • Create an issue with the checklist below.
  • Prepare your repo for transfer
    • Ensure github issues are enabled.
    • 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
    • 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 use the global organization version in voxpupuli/.github. Please enhance the global version if the version in the docroot contains useful parts.
  • Release the first version under Vox Pupuli.
  • Create 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).
  • Write a very short blog post about the migration(example). Write to our mailinglist about the migration/new blogpost.

Checklist

Reference: https://voxpupuli.org/docs/migrate_module/

* [ ] Remove PDK `.sync.yaml` if it exists.
* [ ] Ensure correct `LICENSE`.
* [x] Enable GitHub Issues.
* [ ] Vox Pupuli Admin: Verify all webhooks are disabled.
* [ ] Vox Pupuli Admin: Enable `Automatically delete head branches` in repository settings.
* [ ] Vox Pupuli Admin: Add the `collaborators` team to the Team list with `Write` permissions.
* [ ] Vox Pupuli Admin: Update access permissions to allow forge.puppet.com secret access for releases.
* [ ] Add to voxpupuli/modulesync_config.
* [ ] Execute voxpupuli/modulesync_config for the module.
* [ ] Release a new version under Vox Pupuli.
* [ ] Create a forge issue requesting deprecation of the old module.
* [ ] Write a blog post about the migration.
* [ ] Send notification to the mailing list about the new module.

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.