If I understand correctly... Chop is a testing framework? Are we talking about bringing it completely into Usergrid? If so, isn't that out of scope (ie. lacking coherence with the main purpose of the project) - and thus doesn't it make Usergrid a bit of an umbrella project? Clearly, any test scripts that are specifically for UG make sense and should obviously be included... but the framework itself?
On Apr 11, 2014, at 11:56 AM, Alex Karasulu <[email protected]> wrote: > Awesome responses all around, thank you all. More inline ... > > On Fri, Apr 11, 2014 at 5:53 PM, Dave <[email protected]> wrote: > >> +1 on bringing this into Usergrid. >> >> I suggest we place it at the top level of the directory structure, as a >> peer of stack. >> >> > Sounds like the best place yeah. > > >> Regarding your question #3, I have been looking for the official ASF >> foundation-wide policy, but as yet have only found a bulk contribution >> policy for Apache UIMA: >> >> https://uima.apache.org/contribution-policy.html >> >> I think that sounds like the right policy. That means we need a signed SGA >> for the contribution and ICLAs for any contributors before we can bring >> this in. >> >> > OK I can get the fellas that worked on it to provide their ICLA's and > handle the SGA with you. Everyone was very open to the idea and excited > about it. Some of the committers were questioning whether or not they'll be > able to continue working on Chop at Usergrid. I imparted that the community > was more important to UG than the code and that they should not worry about > it: the PPMC would handle this matter reasonably according to Apache policy. > > Dave please point me over to what must be provided and I'll take care of > that ASAP. I'm at your disposal. > > Best, > Alex > > >> On Fri, Apr 11, 2014 at 12:28 AM, Rod Simpson <[email protected]> wrote: >> >>> +1 This sounds awesome! Definitely a great addition to Usergrid. >>> >>> Rod >>> >>> >>> -- >>> Rod Simpson >>> @rockerston >>> rodsimpson.com >>> >>> On April 10, 2014 at 8:44:35 PM, Todd Nine ([email protected]) wrote: >>> >>> IMHO I think >>> >>> 1) Yes we should. >>> >>> 2) If we're taking the approach that we release SDKs separately from >>> the stack, then I think this can just be another tool that we release >>> independently as well. This makes all the source available in one >>> location, and easier for our users to grok and contribute. >>> >>> >>> >>> On Thu, Apr 10, 2014 at 9:48 PM, Alex Karasulu <[email protected]> >>> wrote: >>>> Hello Devs, >>>> >>>> <OT> >>>> >>>> I hope everyone is well and had a great time at Apache Con 2014 this >>> week. >>>> >>>> </OT> >>>> >>>> I've been diverted from working on UG proper in an effort to be able to >>>> thoroughly and easily stress test it in a production-like environment. >>> This >>>> includes testing methods, classes, and components in isolation as well >>> the >>>> entire system. I've been working on the code here: [0] with more info >> at >>>> [1] and [2]. Initially I was hoping to use an existing toolkit to do >> this >>>> (since frankly I did not wanted to deal with writing testing code) >>> however >>>> nothing really satisfied all our requirements: >>>> >>>> o test methods, classes and components in isolation as well as the >> entire >>>> system, >>>> >>>> o be a able to leverage existing unit tests as stress tests with just >> an >>>> annotation, >>>> >>>> o seamlessly integrate with our build and CI system >>>> >>>> o historically track the performance with metrics over the life of the >>>> project >>>> >>>> o auto-[de]provision clusters needed (C* and ES) for the annotated >> tests >>>> to hit >>>> >>>> Initially, I tried achieving this with JMeter and other such stress >> test >>>> tools but it just didn't fly. So I thought I could whip up a small >>> library >>>> to get started and return back to the core persistence code. I did not >>>> realize the time it would take. Honestly, I thought it would be throw >>> away >>>> code eventually and did not want to clutter our repository, while >>>> generating needless traffic. Plus I needed some help and asked friends >> at >>>> Safehaus who also had a similar need for their assistance and >> thankfully >>>> they also helped out. >>>> >>>> So we've progressed considerably however IMHO I think this code belongs >>> at >>>> Apache alongside the UG code base which it was originally designed to >>>> stress test. So now I have some questions: >>>> >>>> (1) Should we import this into our source code repository? >>>> >>>> (2) If yes to (1) then, where should it go? In a 'chop' folder as a >> peer >>> of >>>> the portal, sdk, and stack folders? >>>> >>>> (3) Do we need to get an ICLA on file for the guys who helped out while >>> it >>>> was hosted for the brief convenient time it was kept at the Safehaus? >>>> >>>> ----- >>>> >>>> [0] - http://stash.safehaus.org/projects/CHOP/repos/main/browse >>>> >>>> [1] - http://jira.safehaus.org/browse/CHOP >>>> >>>> [2] - http://confluence.safehaus.org/display/CHOP/Home >>>> >>>> >>>> -- >>>> Best Regards, >>>> -- Alex >>> >> > > > > -- > Best Regards, > -- Alex
