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 mor
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
imp
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
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 los
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 is
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
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 comm
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.).
Zol
I'm not at all convinced that splitting the project into per-language
pieces will help. It will be a lot of work and I think we'll just get lots
of orphaned languages that never get released.
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
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 personal messages to a few PMC
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 have had that problem for several releases.
> But
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 languages
>From Doug:
> A few reminders never failed to rouse enough reviews & votes.
And from Sean:
> In HBase we've largely switched away from release votes that have a fixed
deadline due to the need to corral PMC votes.
I've always had to nudge people in the past, too. I like the idea of
open-ended rele
Hi,
A question just came to my mind: How would inter-language compatibility
work after the split? How will we now which versions of the different
language bindings support the same features and allow bidirectional
exchange of data?
Or is it an already existing problem? I don't know too much about
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 tests,
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 SNAPS
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 b
17 matches
Mail list logo