The benefit is production-ready code that could potentially be incorporated into storm-sql and accelerate that effort. A side benefit is an uptick in contributors with SQL expertise. If we want to incorporate any of the SQE code, we need the code donation.
If we accept the code donation, there’s a good chance that SQE developers will join the SQL effort and bring their experience/expertise (not to mention the code). If we reject the code donation, there won’t be much incentive for the SQE developers to contribute to the SQL effort — In that case we lose out on both code and community opportunities. This scenario is almost exactly the same as the JStorm code donation, but on a smaller scale. I’m hoping some of the SQE developers will join this discussion and provide some additional insight into how things might play out if we move forward with this. -Taylor > On Aug 26, 2016, at 12:05 PM, Harsha Chintalapani <st...@harsha.io> wrote: > > From the looks of it the benefit accepting this code donation is to attract > more developers on storm-sql . What is stopping SQE developers to come and > contribute to JIRAs that are open on storm-sql?. I don't see just > accepting code donation and setting aside is not much of a > incentive/motivation for someone to contribute. > > -Harsha > > On Thu, Aug 25, 2016 at 12:14 PM P. Taylor Goetz <ptgo...@gmail.com> wrote: > >> 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 >> >> 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 <ev...@yahoo-inc.com.INVALID> >> 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 <kabh...@gmail.com> >> 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 <abhishc...@gmail.com>님이 작성: >> >> 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 <ptgo...@gmail.com> >> wrote: >> >> >> On Aug 24, 2016, at 5:37 PM, Jungtaek Lim <kabh...@gmail.com> 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 <ptgo...@gmail.com>님이 작성: >> >> 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
