New policies for Extras Modules

[Greg DeKoenigsberg]

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/

[Serge van Ginderachter]

​This sounds good.​

On 11 May 2015 at 21:18, Greg DeKoenigsberg <gr...@ansible.com> wrote:

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.

​Depends I guess on the options on how to parse things and to trigger github.

Having some ID in the module itself would have the advantage to easily delegate that,

when necessary, core maintainers can also easily change it.

​

 

* 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.

! ​Keep in mind that the "maintainer" might be a Github organisation​

 

​and not a lone developer,
​

* 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.

​If the ID is maintained within the module, the original owner can easily change it.
​

 

* 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.

​​If the ID is maintained within the module, a core maintainer can easily change it.​

 

​  Serge​

[René Moser]

Hi

May I answer some parts of this question:

Am Dienstag, 12. Mai 2015 00:04:10 UTC+2 schrieb Jonathan Mainguy:

1. Who gets credit on github for the merge, Bob or the original author of the PR. (Credit on Github being the stats at https://github.com/ansible/ansible-modules-extras/graphs/contributors and https://github.com/ansible/ansible-modules-extras/commits/devel/database/mysql/mysql_replication.py for example)

Git does make a difference between an author and a committer, So this information will remain in the commit.
 

2. What happens to the original PR against ansible, does it get closed unmerged? Who is closing it, bcoca? is bcoca expected to comb through all the open requests, find ones where Bob submitted an identical PR and got it merged?

The commiter should take care by adding a "closes GH-<number>". When ansible inc merges the PR of the module author, the origin will also be closed as well.

[Adam Hamsik]

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.

[Greg DeKoenigsberg]

On Wed, May 13, 2015 at 12:45 PM, Adam Hamsik <haa...@gmail.com> wrote:

>> * 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.

Having just gone through several dozen PRs, I now strongly believe
that this information needs to be in the module metadata itself.
Separate longer analysis coming soon.