Hi all, CI testing seems an excellent idea. So does splitting the languages for releasing.
If the languages are split then I think it would be a good idea to have separate mailing lists so that e.g.C++ devs don't get all the Java pull requests. That should make review and commit turnaround times shorter. The only problem I can see is the danger that two languages interpret the spec slightly differently and then drift away from being able to talk to each other. So I suggest that we set up a basic set of data files that has to be tested by all languages (reading tests and round-trip tests) and insist that any time someone fixes a spec-violating bug in any language, they add a test for this to the all-languages tests. Simon On 13 Nov 2016 20:22, "Ryan Blue" <[email protected]> wrote: > 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 >
