avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zoltan Ivanfi ...@cloudera.com>
Subject Re: [DISCUSS] Community engagement
Date Mon, 21 Nov 2016 18:20:39 GMT

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 the
language bindings you mentioned; if some of them have not been worked on
recently, does this mean that they are lacking in support for some features
of the specification? If I use libraries from the same release of Avro in
software components of different languages, are they not guaranteed to be
compatible with each other?



On Sat, Nov 19, 2016 at 10:03 PM Ryan Blue <rblue@netflix.com.invalid>

> 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 blocking one another
> and make it possible to get more releases out. I think we could have had
> several JavaScript releases this year if JS could have been released
> independently, but the rest of the community isn't moving fast enough for
> that. And that's fine; we need to fix bugs in C before we put out a C
> release, but we don't want C to prevent other language contributors from
> moving forward.
> > 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.
> Splitting does two positive things: it allows releases to happen
> independently and it makes maintenance and contribution easier.
> Independent releases are a net positive, in my opinion. It is important to
> get contributions into releases so that contributors benefit from their
> work. Otherwise, what is the incentive to contribute back? Releasing
> implementations independently allows us to get contributions back to the
> community faster and decreases the likelihood that someone loses interest
> because they don't get to use what they fixed.
> I think that a better release cadence for active languages outweighs the
> cost of orphaned languages. I agree that it's likely for, say, PHP to not
> be released again. But what is the value of releasing code that hasn't
> changed? Splitting would no longer push us to periodically fix languages
> when they break, but this irregular maintenance isn't substantially
> different than having no releases. I think there's a strong case that it is
> better for downstream consumers to see that the version number hasn't
> changed rather than having one identical release after another that gives a
> false sense that the implementation is actively maintained.
> The second positive effect of splitting from above is to make maintenance
> and contribution easier. A good example is adding more environments to CI
> tests. We aren't going to add 3 versions of Ruby to the Docker image, but
> it's simple to set up in a CI environment for typical Ruby projects.
> Language-specific repositories allow us to take better advantage of
> existing tools, while structuring each repository for people familiar with
> that language, making it easier for the people most likely to contribute to
> do so. I know it isn't horribly difficult today, but I think it's a step in
> the right direction to make this easier.
> rb
> On Wed, Nov 16, 2016 at 8:41 PM, Sean Busbey <busbey@cloudera.com> wrote:
> > On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting <cutting@gmail.com> wrote:
> > > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue <rblue@netflix.com.invalid>
> > 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
> > > members asking them if they had time to please review a release.  Some
> > > PMC members get busy with other things and fall behind on Avro emails.
> > > A few reminders never failed to rouse enough reviews & votes.
> > >
> >
> > In HBase we've largely switched away from release votes that have a
> > fixed deadline due to the need to corral PMC votes.
> >
> > Instead, we now state the minimum voting period (almost always 72hrs
> > per ASF policy) and set a courtesy notice of when the RM would like to
> > close the vote. Then we just keep pinging private@ or individuals
> > until we get enough votes for a result, or find something to start
> > getting -1s.
> >
> > We could try something like that for a bit to see if "flog the bushes
> > for PMC participation" is enough to keep us on a steady stream of
> > releases.
> >
> > It would also probably help to make explicit to the community that
> > showing up to test and vote on RCs is "acting like a PMC" in the eyes
> > of some number of current PMC members (it is for me, for example).
> >
> > --
> > busbey
> >
> --
> Ryan Blue
> Software Engineer
> Netflix

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message