On Sun, Jul 12, 2015 at 8:54 PM, Chris Riccomini <criccom...@apache.org> wrote: > Hey all, > > I want to start by saying that I'm absolutely thrilled to be a part of this > community. The amount of level-headed, thoughtful, educated discussion > that's gone on over the past ~10 days is overwhelming. Wonderful. > > It seems like discussion is waning a bit, and we've reached some > conclusions. There are several key emails in this threat, which I want to > call out: > > 1. Jakob's summary of the three potential ways forward. > > http://mail-archives.apache.org/mod_mbox/samza-dev/201507.mbox/%3CCADiKvVu-hxdBfyQ4qm3LDC55cUQbPdmbe4zGzTOOatYF1Pz43A%40mail.gmail.com%3E > 2. Julian's call out that we should be focusing on community over code. > > http://mail-archives.apache.org/mod_mbox/samza-dev/201507.mbox/%3CCAPSgeESZ_7bVFbwN%2Bzqi5MH%3D4CWu9MZUSanKg0-1woMqt55Fvg%40mail.gmail.com%3E > 3. Martin's summary about the benefits of merging communities. > > http://mail-archives.apache.org/mod_mbox/samza-dev/201507.mbox/%3CBFB866B6-D9D8-4578-93C0-FFAEB1DF00FC%40kleppmann.com%3E > 4. Jakob's comments about the distinction between community and code paths. > > http://mail-archives.apache.org/mod_mbox/samza-dev/201507.mbox/%3CCADiKvVtWPjHLLDsmxvz9KggVA5DfBi-nUvfqB6QdA-du%2B_a9Ng%40mail.gmail.com%3E > > I agree with the comments on all of these emails. I think Martin's summary > of his position aligns very closely with my own. To that end, I think we > should get concrete about what the proposal is, and call a vote on it. > Given that Jay, Martin, and I seem to be aligning fairly closely, I think > we should start with: > > 1. [community] Make Samza a subproject of Kafka.
Can you expound on what you mean by "subproject"? There is such a thing around here and they are considered an anti-pattern at the ASF but since the Lucene/Solr merge has been mentioned (which was truly a merge, not a subproject) I'm curious what exactly the proposal is? I imagine the board would want this clearly articulated too, so your energy likely wouldn't be wasted on a lowly user. > 2. [community] Make all Samza PMC/committers committers of the subproject. This hints at truly a subproject, which I'd suggest is a bad idea. Even if it's technology is closely coupled to Kafka, Samza has proven it can stand on it's own as a community and technical focus. > 4. [code] Have the Samza community and the Kafka community start a > from-scratch reboot together in the new Kafka subproject. We can > borrow/copy & paste significant chunks of code from Samza's code base. Huh? are you suggesting a big "2.0" rewrite? as a user this kinda talk is frightening. > 5. [code] The subproject would intentionally eliminate support for both > other streaming systems and all deployment systems. as in eliminate support for Yarn deployments? > 6. [code] Attempt to provide a bridge from our SystemConsumer to KIP-26 > (copy cat) > 7. [code] Attempt to provide a bridge from the new subproject's processor > interface to our legacy StreamTask interface. > 8. [code/community] Sunset Samza as a TLP when we have a working Kafka > subproject that has a fault-tolerant container with state management. > > It's likely that (6) and (7) won't be fully drop-in. Still, the closer we > can get, the better it's going to be for our existing community. > > One thing that I didn't touch on with (2) is whether any Samza PMC members > should be rolled into Kafka PMC membership as well (though, Jay and Jakob > are already PMC members on both). I think that Samza's community deserves a > voice on the PMC, so I'd propose that we roll at least a few PMC members > into the Kafka PMC, but I don't have a strong framework for which people to > pick. > > Before (8), I think that Samza's TLP can continue to commit bug fixes and > patches as it sees fit, provided that we openly communicate that we won't > necessarily migrate new features to the new subproject, and that the TLP > will be shut down after the migration to the Kafka subproject occurs. > > Jakob, I could use your guidance here about about how to achieve this from > an Apache process perspective (sorry). I'm not Jakob, but can tell you for the technical bits you could call a vote to gauge consensus on the technical approach and just start pursuing it. Depending on your answer to my questions on whether this is truly a subproject being proposed vs. a truly merged project, it may a board resolution - but I reckon you'll want to consult board@ for advice well before it gets to that point. > * Should I just call a vote on this proposal? I'll repeat my previous mail and recommend you break up the 'future-of-samza-code' from 'future-of-samza-community' proposals. > * Should it happen on dev or private? dev@, *definitely* > * Do committers have binding votes, or just PMC? PMC members technically have a binding vote, but if that ends up mattering when the votes are tallied, you should hope everyone will think long and hard about it. > Having trouble finding much detail on the Apache wikis. :( http://www.apache.org/foundation/voting.html :) --tim
