Hi guys,
I've booked a room at 2:30pm pacific at Yahoo's campus here -
http://yhoo.it/1xMUa5d. When you arrive please park in guest parking or
really anywhere you can, head over to building B, and give me a call at (310)
694-6908. It'd be great if you can get there around 15 minutes early so we
can do the guest sign in without cutting into meeting time.
If you can't attend in person, I'll open up a conference line at 1 888 371.8922
with passcode 40378474# at 2:30pm pacific. If you're calling from outside the
US, please dial +1 617 224.4792 instead.
Looking forward to it, and thanks,
Josh
On Tuesday, November 18, 2014 10:59 AM, Brian Geffon
<briangef...@gmail.com> wrote:
Hey Josh,
James, Thomas, and I have been bouncing some ideas around that we'd like to
share too. We can all come by at 2:30 on Thursday if that works for you
guys.
Brian
On Tue, Nov 18, 2014 at 10:24 AM, Narayan Balasubramanian (நாராயண் ) <
bv.nara...@gmail.com> wrote:
> I can meet Thursday this week.
>
> Thanks,
> Narayan
>
>
> 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
> > >>
> >
> >
> >
> >
> >
>
