Hello Josh, Please count me in.
Regards, Meera. On Tue, Nov 18, 2014 at 9:30 AM, Joshua Blatt <bla...@yahoo-inc.com.invalid> wrote: > Hi guys, > Sorry I've been slow setting this up, but before this slips away from us, is > anyone up for a meeting this week? Say Thursday sometime between 11am and > 4pm? > We could do this in person and I'm happy to host a meeting at the Yahoo > office in Sunnyvale, but if transit time makes it too difficult, I think a > phone call would work well too. Brian, Narayan, Cynthia, anyone else? > Thanks, > Josh > > > On Tuesday, November 4, 2014 3:09 PM, Cynthia Gu > <czhen...@linkedin.com.INVALID> wrote: > > > Brian, > > Just some thoughts on collaboration. Most of the contributors are local is > definite something advantage we can take. Since it’s a framework, we > probably need some initial meetings/phone calls to come up with a robust > easy-to-use framework. After that, we can start to implement test cases > individually. > > Cynthia > > On 11/4/14, 10:54 AM, "Narayan Balasubramanian (நாராயண் )" > <bv.nara...@gmail.com> wrote: > >>Brian, >> >>Agree with Josh. You have captured the requirements well. >> >>AFAICT, most of the contributors are local - LinkedIn, Apple and Yahoo. >>Phone call, irc is all good. We can even meet to nail this. >> >>Thanks, >>Narayan >> >> >>On Tue, Nov 4, 2014 at 10:01 AM, Brian Geffon <bri...@apache.org> wrote: >> >>> Hi All, thanks for your patience I know many people are eager to start >>> pooling resources to make this happen. (Thanks Susan for helping with >>>notes >>> during the summit) >>> >>> To briefly summarize what was discussed at the summit, we have an >>>existing >>> framework called TSQA which is based on bash, while this is a nice start >>> it's not really what we need. Josh Blatt hacked together a prototype in >>> NodeJS, but I think the consensus was that the tooling and existing code >>> for Python would result it in being a better language choice, it seemed >>>to >>> be a more-or-less unanimous agreement (were there any objections to >>>using >>> Python?). >>> >>> With the language defined, we outlined the following high level >>> requirements: >>> - It must be very easy to write simple tests (ie. basic http get -> >>>proxy >>> -> simple http origin). >>> - It must be expressive enough to handle complex test cases (ie >>>testing >>> an ESI plugin or advanced networking cases such as sending a FIN >>>randomly). >>> - Such a framework MUST allow for integration testing plugins. >>> - We must be able to bootstrap trafficserver with relevant configs and >>> plugins. >>> - We must have a port manager that is shared between each component of >>> the integration test. >>> - We would punt on multiple OS support to start in favor of developing >>> something more generally useful to start. However, at some point in the >>> future it would be nice to have. Thus design decisions shouldn't be >>>linux >>> specific with the end goal of supporting multiple OSes. >>> - This framework will run in our existing CI environment, thus >>>existing >>> testing frameworks for generating reports suitable for Jenkins is a >>>must. >>> >>> Other issues raised during this session were: >>> - Using such a framework for perf testing, most people agreed this >>>should >>> be considered separately from this testing framework. >>> - We should investigate what other proxies are using before >>>development >>> begins to determine if we can reuse/share components if the goals of our >>> framework aligns with an existing framework. >>> - The following wiki page exists related to QA: >>> https://cwiki.apache.org/confluence/display/TS/Quality+Assurance >>> >>> Please feel free to respond if I left anything out or if I in anyway >>> misstated the discussions at the summit. >>> >>> Now moving along to the fun part. Several people have expressed >>>interest in >>> this project, which is awesome, but let's all coordinate. Let's work >>> together and make something great that can really benefit the entire >>> community. Does anyone have suggestions for how we can coordinate and/or >>> deal with task distribution? Obviously Jira should be used for tasks, >>>but >>> should we do regular IRC check-ins and summarize those discussions on >>>the >>> mailing list? Ideas? >>> >>> Brian >>> > > > >
