>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 <[email protected]> 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 <[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 > > > >
