On Monday, May 11, 2015 at 9:18:15 PM UTC+2, Greg DeKoenigsberg wrote:
>
> 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. 
>

Can we put them into meta/main.yml with original repo-name. As this would 
allow ansible-galaxy detect  original module name without depending on 
directory name in which module is.

>
> * 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/b7d7161c-8a27-4a18-90e1-77a09614860e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to