Yes that's why I'm emphasizing more about potential contributors instead of SQE codebase.
I skimmed the codebase, and couldn't find notable features compared to Storm SQL. TODOs for Storm SQL also seems to be a TODO of SQE. Since I recently pushed some features so I might be biased. I'd be appreciated if someone would like to compare and give thought / opinion about that. So for me code donation is only for letting SQE to pass IP clearance so that we (or they) can cherry-pick to contribute to Storm SQL faster and safer. As I said earlier, Storm SQL itself needs more contributors to add features, and apply various optimizations "in long term". You can see that SQL module is one of hot contributing area for Apache Spark, which means that it needs lots of efforts to maintain and improve. I'm not expert on this area and also not having strong experiences so would want to go with experts, or more contributors to share the load and learn together. Authors of SQE could be. - Jungtaek Lim (HeartSaVioR) 2016년 8월 25일 (목) 오후 10:30, Bobby Evans <ev...@yahoo-inc.com.invalid>님이 작성: > 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 > > > >
