>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 <[email protected]> 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 <[email protected]> wrote: > >> On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting <[email protected]> wrote: >> > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue <[email protected]> >> 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
