Just to follow up on this point of the conversation: I’m not going place myself in the way of this happening - I don’t have the necessary technical knowledge of the testing framework to make any sort of determination on it, I was just looking for clarification that we had considered any potentially negative aspects of the merger. Thanks!
Scott On Apr 11, 2014, at 5:15 PM, Todd Nine <[email protected]> wrote: > I agree with your point that chop can be used by many projects and for > that reason it might be too general for the UG code base.. At the > moment, we're the only project using Chop as a dependency of our > integration testing framework. From a practical standpoint, I'm not > sure what other location would be appropriate for this module. It's > not yet large enough to be a top level project, and having it within > our codebase/release cycle allows us to iterate rapidly to create the > tests and modifications we need. Perhaps a happy medium is to > integrate it now, and if it becomes heavily used outside the context > of UG testing, we deprecate it in our source tree and move it into > it's own project? > > Thoughts? > > > On Fri, Apr 11, 2014 at 1:48 PM, Scott Ganyo <[email protected]> wrote: >> 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 >>
