avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Blue <rb...@netflix.com.INVALID>
Subject Re: [DISCUSS] Community engagement
Date Sat, 19 Nov 2016 21:10:37 GMT
>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 release votes if this is the norm. What do you think about
sending another vote for RC1? I think it was fine to release (the minor
problem was with testing, and only happened outside of the docker setup).

I still think that we can do better on engagement. CI is a big part of
that, but also getting releases out -- by decoupling them from one another
-- would help us keep people involved.

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

> 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
>



-- 
Ryan Blue
Software Engineer
Netflix

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