Hi all. Wanted to give a quick update on our initiatives around
improving the PR pipeline for ansible-modules-extras.
To review: we recently decided on two major policy changes. (1) All
PRs to existing modules are merged with +1 from the module owner
(which implies that module owners can make changes without further
approval; please, module owners, be careful with this power.) (2) All
new modules require two +1s from existing module maintainers to be
included.
To support this policy change, we went through and added the Github
IDs of all module owners as metadata within each module file. I spent
the last week learning the Github API well enough to scrape this data
well enough to give myself some rudimentary tools to help speed up
merges (I'll be checking some of this stuff in soon).
Over the past day, I've done a comprehensive review of all open PRs
against existing modules. Where auto-merge was not possible, I asked
submitters to rebase; where auto-merge was possible, I asked reviewers
to give +1 if review indicates the PR is good. We've already closed a
number of outstanding PRs this way, so to both committers and
reviewers, a big thank you. Your work is much appreciated.
Which brings us to the stickier subject: new modules. The backlog is,
uh, large; we have almost 100 PRs for new modules awaiting evaluation
for inclusion into Extras -- which is 2/3rd of our current open PRs
against Extras.
It's time to solicit reviews for new modules aggressively. To do this,
we'll need a couple of things first:
1. A list of reviewers. By policy, a new module needs +1 from two
different reviewers (note that any Ansible employee gets two votes,
prerogative of upstream). Current reviewers are "module owners", so
I'll put together a list of those people in a file called
REVIEWERS.md. I am aware that this is a bit of a blunt object
approach, but it's a starting point. We can always remove/add
reviewers as we see fit, based on sensible new criteria.
2. Criteria for inclusion. We want to take care to be opinionated
about the right things, so we'll put together some review guidelines
that any reviewer can follow. We don't want to judge on content; we
want to judge on the ability to make an Ansible module that works as
expected (idempotent, testable, adheres to style guidelines, etc.)
Getting the first thing done should be quick; getting the second done
might take a while, so that will be our next focus. I will work with
the team to nail down these guidelines as quickly as we can, so that
we can start delegating more responsibility to our community asap.
Thanks to everyone for your support and patience as we continue our
work to hack down our backlog and grow our contributor base.
--g
