I didn’t mean to imply that the code donation would come with automatic committership. I would expect the SQE developers to engage with the Storm community and show merit before being invited to become committers. If for some reason that didn’t happen, we would always have the option of not doing anything with the code donation.
With regard to it recently being open sourced, yes that is the case. JW Player open sourced it in order to make the code donation, which explains the number of commits/contributors. I’m not sure if it’s due to a github auto-watch setting, but the project has a lot of watchers from JW Player (which might be an indicator of potential contributor pool): https://github.com/jwplayer/SQE/watchers <https://github.com/jwplayer/SQE/watchers> When they approached me about the code contribution, I mentioned the existing SQL work that’s been/being done. They are aware of that effort, and see this as a collaboration opportunity to improve SQL support in Storm (i.e. not a competitor to the existing SQL work). Personally I would prefer a single SQL API/implementation for Storm. If that involves cherry-picking/merging two projects into one, I’m okay with that. -Taylor > On Aug 25, 2016, at 9:30 AM, Bobby Evans <[email protected]> wrote: > > I agree that committership should not come form a code donation, but on the > other hand a code donation needs to have a community with it to be viable. > > That is the one thing that makes slightly nervous here. > https://github.com/jwplayer/SQE/pulse > > https://github.com/jwplayer/SQE/graphs/contributors > > show that the code was very recently open sourced and only one person has > made two commits. Which totally makes since from the perspective of a > corporation that just released the code. But by the same right I would like > to hear from others to see how many people are currently interested in > helping to maintain this new code base, and also what is each person's long > term plan/vision for this code. > HeartSavior has indicated his intention is to try and combine the back-end > with SQL which seems like a good idea, but at the same time others have > expressed concern that we have multiple different APIs and execution > environments for Storm. Adding another without any plan on where we want to > go long term gives me pause. > - Bobby > > On Thursday, August 25, 2016 5:07 AM, Jungtaek Lim <[email protected]> > wrote: > > > I'd postpone to talk about committership a bit later after they show active > contributions. Personally I don't like associating code donation and > committership but it's just me. > Storm SQL (or SQL feature for all projects) has lots of places for > contributions so they can be eventually invited like other commiters/PMCs, > similar to John Fang. > > Regarding future of storm-sql after SQE, it would be better to discuss > again when the process of code donation is in place, so that we can discuss > with comparison between storm-sql and SQE at that time. > > Thanks, > Jungtaek Lim (HeartSaVIoR) > > 2016년 8월 25일 (목) 오후 3:44, Abhishek Agarwal <[email protected]>님이 작성: > >> what happens to current storm-sql once SQE is merged into apache >> repository? >> >> On Thu, Aug 25, 2016 at 10:26 AM, P. Taylor Goetz <[email protected]> >> wrote: >> >>> >>>> On Aug 24, 2016, at 5:37 PM, Jungtaek Lim <[email protected]> wrote: >>>> >>>> While I feel Storm SQL covers (and will cover in near future) all of >> the >>>> features what SQE has, I'd like to consider this as not only code >>> donation >>>> but also having more contributors on Storm SQL. >>> >>> +1 >>> >>> This is a great opportunity to grow the community interested in streaming >>> SQL. >>> >>>> >>>> As the one working on storm-sql now, I think Storm SQL should have >>>> more contributors who are experienced or expert on this area, or at >> least >>>> have a mind to contribute heavily. >>> >>> +1 again. >>> >>> In my conversations with JW Player, they indicated that their developers >>> are very interested in joining the Storm community. >>> >>>> There're still many features to implement (join and windowing, >>> parallelism, >>>> and so on) which needs some efforts so we can boost up if more >>> contributors >>>> would play with Storm SQL. >>>> And "optimization" is at the heart of SQL and we haven't had time, and >>>> knowledge, and experience to address that. >>> >>> SQE seems kind of ahead to a certain degree in this respect. >>> >>>> >>>> IMHO, Storm SQL seems to be going on the right track so I don't think >> we >>>> need to replace the codebase or merge. We can still apply the advanced >>>> areas of SQE to Storm SQL via normal pull requests (code donation >>> resolves >>>> the IP clearance so should be easy to do). >>>> I'd be more appreciated if this is a signal for them to contribute >> Storm >>>> SQL directly. >>> >>> If we accept this code donation, I would hope that we would also consider >>> the original authors for committership at some point. >>> >>>> >>>> Thanks, >>>> Jungtaek Lim (HeartSaVioR) >>> >>> -Taylor >>> >>>> >>>> 2016년 8월 25일 (목) 오전 12:17, P. Taylor Goetz <[email protected]>님이 작성: >>>> >>>>> JW Player has offered to donate SQE (Streaming Query Engine) to the >>> Storm >>>>> project. >>>>> >>>>> SQE is a query engine built on top of Trident that uses a SQL-like >>> syntax >>>>> (currently JSON-based) to query streams. There is obvious overlap >>> between >>>>> this and storm-sql, and this might be an opportunity to improve >> Storm’s >>> SQL >>>>> support. >>>>> >>>>> The code and documentation can be found here [1]. >>>>> >>>>> -Taylor >>>>> >>>>> [1] https://github.com/jwplayer/SQE >>>>> >>> >> >> >> >> -- >> Regards, >> Abhishek Agarwal >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
