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 <bus...@cloudera.com> wrote: > On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting <cutt...@gmail.com> wrote: > > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue <rb...@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
