Hi everyone, We tried to release Avro 1.8.2 this week, but the release vote failed because only two PMC members voted on the candidate and we didn't have enough binding votes to pass. There was a minor problem (in my opinion) with the candidate that could have been the reason why there weren't more votes. If there's anyone out there that didn't vote because of this, please say so. Otherwise, this appears to be related to declining engagement in the community and that's a major problem I want to discuss.
Right now, we aren't getting contributions reviewed, committed, and released in time for new contributors to become part of the community and refresh the set of active committers and PMC members. If that continues, this community is heading for the Attic. I think we can build back an active committer base and I'd love to discuss how to do that on this thread. To get us started, I have a couple of ideas. I think we need to make it easier to participate. I've brought up these ideas before when we moved to git: I think we need to separate the implementations into their own repositories and set up CI tests for each one. Right now, a contributor has to wait for a review to get feedback and a committer has to build a contribution and run tests. If we set up CI, then the contributor gets automated feedback and committers can spend their time on substantive review, rather than making sure the patch builds and tests pass. Making it easier for contributors and committers will help increase participation. Similarly, the build and release process is too difficult. It took me hours to get the docker image built so I could make a release candidate, because of a failure rate of about 1/500 downloading and installing packages. I had to try ~20 times before one happily completed. While the docker image helps a lot, the real problem we need to solve is how difficult it is to build all of Avro. The docker image helps, but no one really uses it until it's time to check a release. Instead, we all build and test how we are used to for a particular language implementation: maven for Java, Rake for ruby, etc. That's why the build.sh scripts get broken and we don't notice, and why the only problem with the latest RC was that it didn't pass C# tests outside of docker. The current build also makes implementation releases dependent on one another. Last release, C and ruby problems caused a multi-week delay, and this release we want to get the C# test environment fixed before the next candidate. All of this makes it take longer for contributions to make it out, which undermines the motivation for people to contribute. Separating the implementations will allow us to structure each repository how the contributors and committers for that language expect it to be. We can also set up per-implementation CI easily through Travis CI. And the biggest benefit is separating the releases, so that Python, for example, can release a bug fix without waiting months for unrelated changes in Java. >From my perspective, these two things are a good place to start. To everyone still reading, what do you think? rb -- Ryan Blue
