Thinking about how to merge more, quicker (Was Re: [ansible-devel] Further adventures in variable resolution.)

Rob,

Our major roadblock is human bandwidth, if we see a simple PR we tend
to merge it fast. In some cases we just need to do testing and we
don't have a setup for every module and it can take time to get one up
and running. Many of these in the backlog don't get merged because we
have not cycled to them yet.

In other cases we are unsure about the scope or unfamiliar with it,
try to ping someone with more expertise on the matter, whom will have
their own time constraints. Previous discussion in ansible-devel might
help us along in understanding the PR and seeing that others have
vetted the logic if not the code.

Currently we are merging PRs much faster than they are made, but we
have a long backlog to go through, most of your long lived PRs are in
that backlog from when there was 1 (somtimes 1 1/2) person merging.
We now have 3 full time people in the core team and another few that
we have delegated for certain areas of expertise.

We are chipping away at it but we are also trying to get a version out
(1.9), a major re-haul of the code (v2), investigate bug reports, fix
bugs for which there are no PRs, add features that the community keeps
asking for, helping out in the mailing list and IRC, etc. We are also
looking for more subject matter experts to delegate to and hiring more
core team members.

Travis is currently being added to our github setup (as the community
has suggested) to make some of the same checks we currently do
ourselves, give feedback sooner to the user, save us a step (we'll see
how this turns out soon). Having people in the community test and vet
PRs is also helpful, it gives us more confidence that if we merge it
we won't be spending time tracking down problems and fixing bugs
related to the new code.

I understand the frustration very well, a few months back I was just
another contributor, sometimes getting a patch accepted in 1h and
others waiting for months (I think I still have a couple left over
from then). I ask for patience, I think it is noticeable things are
getting better and the backlog is shrinking, not as fast as we would
all wish, but progress is being made.

As we have stated before, we welcome any suggestions to make this a
faster/better/easier process, sadly I don't see anything that will
give us an overnight boost, just small incremental improvements many
of which we are already adopting or examining (which also takes time).

Thanks for the feedback.

I really appreciate the time you spend trawling the backlog and I think i speak for most of this list when I see I understand the pressures of fitting this stuff in when you’ve got a release (or two!) to push out before a certain date.

I hope, and am confident, that the extra guys in the core team will help to shrink down that PR backlog.

One suggestion I do have is perhaps an extra tag in Github for ‘priority-for-release’ or similar. This would be to help with the scenario you described - “fixing bugs for which there is no PR”. Often, PRs I submit are because I have encountered the bug / feature requirement when running my own playbooks. However, I do sometimes browse through the issue list looking for things i may have knowledge in and think I may be able to contribute to. Browse though means looking at page 1 and 2. Maybe if there was an additional tag that the core team could set on issues that they would really like resolved for the next release this would galvanise the community to work on those particular bugs. I suppose you could count P1 and P2 as doing this already but, of course, i’m sure the core team has particular priorities for a release e.g. cloud or windows etc.

I also look forward to the Travis implementation - please keep us updated on how this goes!

Thank you again for an awesome tool!

Actually we just started using such a tag 'next' as things we are
viewing for next release, we also have a 'v2' tag which is for things
that should wait for v2 to make devel or that will be much easier to
resolve in v2.

er .. not tags, milestones, in this case