First, thanks to all who have participated in recent discussions around our development practices on ansible-devel, which have been productive and helpful.
Now it's time to make some decisions. With the release of Ansible 2.0 coming soon, we'd like to make some policy changes around the maintenance of the ansible-modules-extras repository. First: module owners will assume all responsibility for managing their own modules. Each module owner will manage their own forks of the ansible-modules-extras repo; any pull requests from those repos to update their own modules will be auomatically merged, without further review. Example: Bob owns the yaktalk module (ansible/ansible-modules-extras/notifications/yaktalk.py). Someone finds a documentation bug in the yaktalk module and submits a PR against the ansible repo. Bob would then check the PR, comment/iterate as necessary, and when Bob is happy, he would merge it into his own repo (bob/ansible-modules/extras/notifications/yaktalk.py) and then submit the PR from his own repo. Because we know that Bob is the owner of yaktalk, we would merge the pull request. Second: new modules from owners of existing modules will have their modules automatically approved and merged, since we assume that owners of existing modules know the conventions for module development. Third: new modules from new submitters will go through a period of review, to ensure that the submitters are following the appropriate conventions for module development. Finally: a new Ansible Extras package will be split out from the main Ansible package. The goal of these changes is to ensure that the people who are the closest to the modules themselves are responsible for their ongoing maintenance, and to allow a bit more leeway so that the Ansible team isn't a bottleneck. This leaves some open questions that we'll need to sort out: * How will we know who the module owner is? One option: we ask owners to put their names and github IDs into the module itself. Another option: we keep an external database linking owners to their modules. * How will module owners be notified of PRs/issues against their modules? Matt Martz has a tool that will allow people to subscribe to notifications to their modules; we can use that or something similar. * How do module owners hand off their modules to someone else, or "orphan" a module entirely? In the short term, an email to the ansible-devel mailing list is probably sufficient. * What happens if a module owner fails to maintain their modules in a timely manner? Ultimately, we may reserve the right to deprecate a module that is persistently broken and who has an unresponsive maintainer. * When will this policy go into effect? Immediately upon working out all open issues. Comments/feedback encouraged. --g -- Greg DeKoenigsberg Ansible Community Guy Find out why SD Times named Ansible their #1 Company to Watch in 2015: http://sdtimes.com/companies-watch-2015/ -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAM1FbhECJ5dCv-0%3D_%2BTJumKTZYVrcoYbH8j3QkjWNYGQ5bxVrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
