Re: [DISCUSS] Community engagement

Thanks for your reply, Niels. Sorry to let this go so long without responding to your points. There was a holiday in the US and I was off for a bit. For CI integration, we all agree that it needs to happen. I think splitting the implementations should happen before CI integration because it will

Re: [DISCUSS] Community engagement

Hi, Regarding the CI integration (like Travis) I think this is something we should do anyway. So +1 on that one. I would like to see it set up that - any (github) merge request is built automatically. - any commit to master is built automatically AND (if successful) pushed to a maven repo as

Re: [DISCUSS] Community engagement

Simon brought up compatibility as well. This is an existing problem and right now we have some interop tests where some languages generate data and then read all of the data from other languages. I don't think this problem changes much if we move to separate releases. We can still run these

Re: [DISCUSS] Community engagement

This is in response to Tom's concerns: > When I did the 1.8.0 release I had to fix a few failing tests for a couple of languages, but it was mainly just doing library updates. I think there will be less trouble with builds if we have separate releases, but my main motivation is to avoid

Re: [DISCUSS] Community engagement

On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting wrote: > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue wrote: >> we don't have enough votes for a release > > I don't think that's true. You might not have gotten enough votes > within a few days. I too

Re: [DISCUSS] Community engagement

On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue wrote: > we don't have enough votes for a release I don't think that's true. You might not have gotten enough votes within a few days. I too have had that problem for several releases. But when that happened I would send

Re: [DISCUSS] Community engagement

Hi, I may have been ambiguous in my suggestion about the mailing lists. I did not intend to suggest separating mailing lists for the different language bindings. What I would like to separate from each other instead are real discussions and automated notifications (JIRAs, pull request, etc.).

Re: [DISCUSS] Community engagement

Thanks for responding, everyone! First, on the subject of the Attic: I don't think Avro is headed to the Attic soon, but I think that the current level of engagement is too low to refresh the active part of the community -- we don't have enough votes for a release and it takes a long time for

Re: [DISCUSS] Community engagement

I disagree that Avro is heading towards the Attic. Its rate of contribution has been slow but steady for years. That's the nature of this project. It had a larger number of contributions in its first few years, when new languages and substantial features were being added, but since then, we see

Re: [DISCUSS] Community engagement

Hi, I agree that there is a delay in code reviews and that is one reason for the decline in participation. Regarding the testing I agree we are a bit shorthanded. We need to setup pre-commit tests and run some more testing regularly. I agree with your problem of docker and I have seen the same

Re: [DISCUSS] Community engagement

Hi, I agree with the proposed changes. Regarding the mailing lists, I would like to suggest to separate not only the different languages from each other, but also the discussions from the pull requests, test results and JIRA notifications. When those are mixed together, discussions easily get

Re: [DISCUSS] Community engagement

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

Re: [DISCUSS] Community engagement

Hi Ryan, I am new in this community, so please take my comments with that in mind :-) The idea of splitting implementations seems very logical to me, but I think that, as Avro is a serialization framework, there would have to be integration tests that take into account that the byte-level

[DISCUSS] Community engagement

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