►
From YouTube: CNCF CI WG - 2018-06-26
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
Okay,
well,
it's
10:05
so
good
morning,
I'm
good
I'm
glad
you
can
hear
me.
This
is
the
CNC
f
CI
working
group
meeting,
which
is
held
on
once
a
month
on
the
fourth
Tuesday
at
8
a.m.
Pacific
time.
Currently
we
do
have
some
colleagues
who
are
on
the
other
side
of
the
globe
and
one
of
the
action
items
out
of
today's
call
will
be
a
doodle
poll
to
find
the
preferred
start
time
for
our
once
a
month
calls
I've
shared
the
meeting
notes
in
the
zoom
chat.
A
A
A
A
A
B
B
C
B
Eight,
this
was
a
pretty
big
deal
as
far
as
the
project,
making
it
easier
to
add
external
project,
so
own
app
I'm
doing
an
integration
with
their
CI
system,
helped
us
expand
and
make
the
system
more
portable,
outside
of
the
original
CI
platform,
get
lab
and
other
components
slide
9.
So
we
have
AWS
Google
cloud
OpenStack
as
your
IBM
packet,
soon
to
be
VMware
and
hopefully
Oracle.
B
Here's
the
current
dashboard
with
kubernetes,
deploying
across
the
different
clouds
at
the
top
you're
the
slide
11.
We
build
all
of
the
projects
from
source
where,
where
we're
using
the
internal
CI
system,
so
that's
kubernetes
on
the
master
head
release
as
well
as
whatever
they
latest
stable,
is
and
then
the
same
thing
for
the
different
projects
that
are
going
to.
C
B
B
B
We're
using
the
registry
container
is
doing
other
things
and
get
lab
as
well
at
the
moment,
terraform
cloud
in
it,
some
of
the
things
are
easing
and
we're
using
cube
tests
for
kubernetes
bringing
that
up
because
of
potential
moving
away
from
that,
and
then
helm
try
to
use
upstream
helm
charge
as
much
as
possible
and
if
needed
then
well
fork
those
and
try
to
contribute
any
changes.
Like
the
ona
side,
we
worked
with
them
when
they
were
focused
on
getting
the
new
release
of
ona,
ready
and
deploying
on
on
to
kubernetes.
B
B
B
So
the
major
development
we've
had
right
now
is
on
the
clouds
sides
of
thinks.
Folks
for
helping
on
the
VMR
integration
we
do
have
the
one
cool
150
was
merged.
We
saw
a
few
things
that
we
needed
to
update.
Andrew
you've
turned
around
and
contributed
the
new
pull
requests
on
53
appreciate
it,
so
we're
hoping
to
have
VMware
pretty
soon
through
testing
and
up
in
life
and
then
Oracle
integration
coming.
B
B
B
C
B
The
feedback
to
roll
back
into
the
crosscut
CI
project
itself,
so
we
welcome
any
feedback.
So
we
can
see
where
we're
going
to
go
and
with
v2,
oh
and
if
y'all
have
that,
then
please
join
us
and
these
groups
and
the
mailing
list
on
slack
loves
to
get
feedback
and
so
that
we
can
see
where
to
go
next
and
that's
it.
For
Prescott
CI.
D
D
Hopefully
you
know
game
works
you
up
there
soon,
but
I've
had
some
questions
whoa,
you
know
what
does
it
mean
when
it
goes
red
and
certainly
we've
seen
it
go
red
for
reasons
beyond
the
control
of
the
platform,
and
you
know,
as
I
mentioned,
to
somebody
like
unless
our
platformers
down
most
likely,
if
it's
red,
it's
not
something
in
our
control
and
but
the
way
it
looks,
however,
can
be
its
leading.
So
maybe
something
with
the
dashboard
that
things
are
red
if
we
hover
over
it
or
there's
some
inserted
element.
D
That
indicates
that
you
know
if
it's
a
platform,
specific
error
or
not
and
I,
don't
know
how
you
might
necessarily
detect
that,
but,
like
I
said
I
seen
it
go
red
and
has
nothing
to
do
with
the
platform,
but
somebody
looking
at
it
might
think
that
VMware
is
broken
and
I
think
that
obviously
they're
people
eager
to
participate
in
this
work
eager
to
participate
in
this.
At
the
same
time,
I
think
we
want
to
make
sure
that
if
something
looks
broken,
it's
clear
why.
B
B
C
B
Easy
for
maybe
a
human
to
quickly
see
much
harder
to
automate
as
far
as
finding
from
programmatic
and
showing
and
say
a
pop
up
or
some
type
of
mouse
over
whether
you
go
to
another
screen
whatever
that
is,
and
we
are
slowly
adding
those
pieces
as
we're
going
along,
but
something
that
we're
we've
thought
about.
How
can
we
do
this
more
as
a
overall
general,
but
thanks
yeah.
D
I
mean
one
way
that
I
could
conceivably
think
to
do.
Something
would
be
like
a
stoplight
insert,
yellow
and
if
you
can
connect
to
the
cluster
instead
of
red,
maybe
market,
yellow
to
or
to
indicate
that
the
cluster
is
healthy.
Yeah.
A
few
weeks
ago,
I
saw
it
looked
like
some
bad
data.
Some
bad
data
got
inserted
into
an
environment
file
at
the
build
system.
The
build
completed,
but
now
bad
environment
file
was
corrupting
all
of
the
platform
deploys,
but
the
clusters
were
still
up
and
I
think
you
know
at
that
point.
B
Totally
understand
I,
think
I
know
which
one
we're
referring
to,
and
it's
it's
actually
something
where
we
could
probably
stop
moving
forward.
So
it's
before
you
get
to
that.
This
would
have
to
do
with
some
early
plans
that
we
had
potentially
showing
here
was
the
last
successful,
build
or
deploy
or
whatever
it
is
anyways
let's
carry
on.
E
So
this
will
be
a
quick
update
from
okay
Effie
sides
regarding
what
we
are
doing
with
own
up
integration
and
then
relation
to
open
CI.
So
all
TV
is
one
of
the
new
foundation
networking
umbrella
projects
which
basically
does
system
integration
and
testing
by
bringing
different
open
source
technologies
together,
like
OpenStack,
kubernetes,
open,
daylight
or
not,
and
so
on,
and
it
is
pretty
like
similar
to
cross
Klotz
open
if
across
community
CI
also
does
cross
community
CI,
but
as
opposed
to
what
cross
closure
is
doing.
E
Okay,
if
it
does
everything
on
bare
metal,
mostly
because
OPP
general
deals
with
psycho
specific
use
cases
and
benchmarking
and
performance
characteristics,
they
are
important
and
they
need
to
be
verified
on
production,
like
environment
and
since
day
one.
We
have
been
doing
this
type
of
cross
community
integration
and
over
time
we
decide
to
move
forward
faster
by
bringing
different
technologies
from
master
branch.
Strengths
like
how
cross-class
she
is
doing,
and
thanks
to
open
daylight,
community
and
Daniel
fellow
who
is
with
us
today.
E
We
got
lots
of
input
from
open,
daylight
community
and
we
basically
tried
copying
or
we
start
copying
their
practices
they
employ.
In
their
continuous
delivery
pipelines
and
based
on
those
practices,
we
started
bringing
open
daylight
from
trunk
in
told
me
a
moment
and
start
integrating
opens
and
I
opened
arrived
at
OpenStack,
and
this
opened
up
new
opportunities
and
one
of
the
projects.
We
want
to
start
working
with
this
phone
up,
because
own
up
is
pretty
important
in
networking
world
and
it
basically
provides
me
with
an
orchestration
for
network
function.
E
The
basic
thing:
how
can
we
bring
in
artifacts
from
on
up
into
cross
plus
VI
or
cross
from
OSGi
in
a
similar
way?
We
are
doing
with
open
daylight
artifacts,
and
this
brings
us
to
an
obvious
need
that
it
would
be
important
for
us,
OPP,
CN,
CF
or
other
communities
who
might
need
to
reach
out
to
on
our
community
and
get
the
needs
we
have
in
Toronto
and
instead
of
reaching
out
to
on
our
communities
our
selves
alone.
E
It
might
make
sense
for
us
to
collect
I,
try
to
collect
requirements
on
our
site
within
CN,
CF,
cross
class,
GI
or
OPP
xgi,
or
perhaps
even
open,
lab
and
find
commonalities
between
these
different
design
uses
and
then
each
our
own
of
community
one
voice.
So
they
don't
have
to
deal
with
multiple
common
and
they
don't
get
confused
and
we
don't
waste
their
time
and
our
time.
So
we
can
get
things
done
much
faster,
and
that
is
actually
the
second
bullet
point
like.
E
How
can
we
find
out
scenarios
around
coming
up
with
common
economists
on
our
community,
and
that
is
something
I
want
to
highlight
to
CN,
CF
and
first-class
GI
team?
That
how
can
we
start
collecting
these
requirements,
and
this
brings
us
to
open
CI,
which
is
a
new
initiative
kind
of
community
forming
we
start
forming
recently-
and
we
are
talking
about
similar
concerns
or
practices
as
part
of
open
CI
to
establish
cost
community
I.
E
What
we
have
haven't
been
able
to
achieve
and
what
we
have
achieved.
So
we
can
set
some
kind
of
blueprint
there.
It
comes
to
how
to
tackle
this
common
integration
challenges
across
different
open
source
communities
and
the
second
part
of
this
okay,
it's
all
good
that
we
can
start
an
inter
pad
or
Google
Doc
document
to
collect
these
requirements,
but
we
also
need
to
make
things
real.
So
we
have
a
progress
in
prior
to
thinking
or
talking
about
problems
and
again
as
part
of
open
CI.
E
We
start
the
prototype,
which
we
have
the
link
to
that
document
on
the
slide,
with
in
open
daylight,
between
open
daylight
on
up
and
all
PFE,
to
try
out
some
ideas
of
like
using
event-driven
ci
to
get
the
CI
systems
talking
to
each
other.
So
they
can
basically
pass
the
information
regarding
whatever
they
have
been
doing
in
there.
Ci
CD
systems
such
as
building
artifacts
testing
them
growing.
E
Certain
versions
of
artifacts
are
good
enough
for
other
communities
to
consume
and
then
that
information
can
be
used
for
other
CIC,
these
systems
to
fetch
those
artifacts
and
do
further
test
integration
and
testing.
If
we
need
to
put
this
in
CNC,
F
cos
Class
VI
context
which
basically,
which
might
make
your
life
easier
if
own
upstarts
publishing
events
when
they
create
new
artifacts,
so
you
don't
have
to
go
and
parse
their
rocks
and
so
on,
and
this
is
something
I
already
asked
to
Tyler.
C
Okay,
so
what
mostly,
is
what
everything
what
fatty
explained
in
there?
We
started
with
the
idea
that
we
want
to
broadcast
events
from
one
CI
system
to
another,
and
then
we
want
to
be
able
for
systems
to
just
consume
those
events,
so
the
ideas
that
we
need
to
have
just
a
common
schema
of
the
messages
that
you
want
to
consume.
C
C
We
had
an
active
mq
cute
there
and
we
just
were
just
posting
these
events
and
then
the
other
C
I
was
interested
in
consuming
those
and
then
base
than
that
we're
launching
new
jobs.
And
after
this
initial
idea,
what
we
are
doing
is
that
we
are
working
on
a
pollution
of
our
own.
That
will
allow
us
to
to
be
more
active
or
invalidation
of
the
messages
and
half
be
able
to
provide
an
Akuma
messaging
system
forever
for
the
ones
that
we
we
need
to
use
that
want
to
use
it.
C
So
let
me
taste
again
that
we
started
to
work
on
this
project
that
is
going
to
do.
The
same
is
just
going
to
set
us
a
set
of
of
parameters
that
you
are
producing
with
your
CI,
and
you
are
going
to
pass
the
target
where
you
want
to
polish
it,
and
then
it
will
just
polish
it
in
a
common
schema
allowing
others
to
consume
it.
C
So
when
three
different
types,
we
have
an
artefact
polish,
it
event
that
this
one,
where
the
system
is
creating
a
new,
a
new
artifact
like
producing
a
turbo,
a
package
whatever
so
any
other
CI,
is
at
an
interest
a
time
consuming.
That
can
just
get
it
all.
So
we
have
one
that
is
called
confidence
level
modified
I
mean
when
you
are
passing
like
some
test.
You
are
passing
unit
testing
integration,
testing,
whatever
you
can
publish
your
results
there,
so
you
can
check
if
you
can
just
count
under
this.
C
This
artifact
is
okay
or
not,
and
then
we
have
another
that
is
called
composition,
define
at
event.
That
is
just
a
set
of
nested
artifacts.
So
when
you
polish
some
release,
you
have
our
asset
of
artifacts.
What
you,
what
you
are
doing
now
is
just
nesting
everything
of
that,
so
we
can
with
these
three
types
of
events
and
then
inside
these
three
types
of
events,
we
are
having
a
like
common
common
fear
like
Bergeron
like
the
RL,
and
then
you
can
have
a
set
of
individual
individual
fields.
C
C
So
that's
what
we
came
for
with
so
we'll
have
like
meta
meta
fields
that
will
be
common
to
all
kind,
all
types
of
events,
and
then
we
can
have
data
that
we
will
be
particular
fields
for
each
type
of
the
then
so
meta.
We
just
are
saying
what
type
I
will
hang
here
any
ID
to
just
be
aware
of
the
event
that
you
consume
it.
C
Okay
are
some
version
as
well,
some
date
time
to
just
for
tracking
the
events
are
you're
consuming
and
then
you
look
a
half
like
data
that
are
the
specific
fields
for
each
type.
For
example,
one
you're
polishing
artifacts,
you
can
have
anything
that
is
collocations
and
then
you
can
pull
it
there.
All
the
other
words
that
you
have
created
when
you
buiishit
your
artifacts.
C
You
can
just
embed
it
here
and
then
the
external
site,
at
this
interested
on
consuming
that
we
just
have
the
devil's
to
consume
it
and
so
that
we're
on
this
now
we
were
interested
on
just
having
your
feedback
there
and
see.
What
do
you
think
about
the
types
of
events
that
will
be
financed?
Do
you
need
more
events,
any
field
that
needs
to
be
included
there,
so
I
mean
the
publisher
is
done
very
flexible,
so
once
we
define
the
schema,
we
can
use
the
publisher
and
we
can
just
do
the
integration
between
the
difference.
C
A
C
C
A
Thank
you
thanks
Taylor
for
posting,
the
open,
CI
mailing
list
as
well
great
next
on
our
agenda.
We've
got
packet
updates
and
then
VMware
updates
and
Oracle
cloud
updates.
So
we
have
about
22
minutes.
We
may
need
to
time
box
for
the
remaining,
if
possible,
maybe
eight
minutes
per
topic.
It's
possible.
D
F
Okay
next
slide
so
provisioning
on
bare
metal
at
packet
and
CF
currently
uses
packet
to
do
bare
metal
provisioning.
The
current
setup
specifies
a
particular
data
center
in
which
to
run
the
tests,
the
machines
are
spun
up,
the
tests
are
run,
machines
are
torn
down,
we
are
in
the
midst
of,
and
I
had
hoped
to
have
a
documentation
for
this,
but
I'll
I'll
send
it
separately
once
it's
once.
The
release
notes
are
out
the
availability
of
publishing,
step
provisioning
step
so
that
the
CNC
F
can
provision
in
any
qualifying
facility
rather
than
a
specific
facility.
F
This
was
designed
in
part
with
the
cross,
clad
CI
in
mind,
so
that
if
any
of
our
facilities
in
some
sort
of
priority
order
has
the
available
capacity
for
as
many
machines
as
are
needed,
that
we
can
avoid
temporary
capacity
issues
by
relocating
to
a
different
data
center,
as
I
say,
we're
working
on
external
documentation
and
integration
with
provisioning
tools.
I'm
trying
to
make
this
as
simple
as
possible
to
integrate,
but
still
still
finishing
this
up.
F
So
one
of
the
things
I'm
looking
for
is
opportunities
to
deploy
part
of
that
fleet
to
have
use
for
cross
non
CI
4
on
64
and
packet,
similar
to
the
bare
metal
infrastructure
was
so
most
of
the
bare
metal
setup
will
be
identical.
It's
just
that
we're
looking
at
the
software
support,
largely
the
lead
on
this
on
the
CNC
F
site
has
been
hippie
hacker
typical
issues
that
we
need
to
overcome.
F
Registry
support.
There's
a
multi
architecture
manifest
that
is
used
to
support
multiple
machine
types
in
a
single
manifest,
so
that
you
can
do
something
like
pull
Ubuntu
and
get
the
right
Ubuntu
for
your
system.
Not
every
single
registry
supports
this,
but
we're
working
closely
with
people
who
are
doing
registry
builds
to
make
sure
that
they
support
all
that
once
the
registry
is
taken,
care
of
packages
need
to
also
have
multi
architecture
support.
F
This
is
partly
porting
things
and
partly
tooling.
Actually,
it's
mostly
tooling,
usually,
usually
the
ports
are
very
small,
but
tooling
up
people
see
ICD
systems
so
that
they
generate
arm
64
artifacts
that
are
appropriately
tagged
and
registered
in
the
registries
and
then,
what's
always
a
question,
I
think,
there's
a
question
came
up
in
the
in
the
notes.
F
How
does
one
test
all
this
so
I
work
on
the
works
on
our
project,
which
is
funded
by
arm,
which
provides
both
see
ICD
infrastructure
and
test
infrastructure
and
development
infrastructure
for
people
doing
ports
or
or
builds
on
64-bit
arm?
We
currently
have
a
bare
metal
infrastructure
for
that
these
same
machines.
F
We
are
actively
investigating
what
it
would
take
to
stand
up
a
little
OpenStack
cluster
so
that
if
people
didn't
need
a
whole
machine
for
a
long
time,
but
just
needed
a
VM
that
we
could
provide
some
kind
of
VM
infrastructure,
primarily
in
the
test
test
piece
of
the
world
and
actively
working
on
that
as
well
and
I'll
drop.
In.
F
Essentially,
you
open
an
issue
on
github
and
describe
your
needs
and
we're
prepared
to
work
with
you
to
get
resources
for
64-bit
arm
up
ports
builds
and
and
if
you
need
some,
if
you
need
a
long
term
access
for
CI,
CD
benchmarking
testing
whatnot
that
we
can
provide
that
as
well.
You
know
within
reason
that
the
pool
of
hardware
is
finite,
hopefully
growing,
but
I
don't
want
to
announce
any
growth
until
it
shows
up
in
my
inventory
screens
and
that's
it
for
now.
D
Said
that's
really
interesting,
so
world
quick
updates,
we
submitted
to
PR
to
add
platform
support
to
the
cross
club
dashboard
that
was
merged.
Last
night
there
was
a
bug
that
was
encountered
that
I
submitted
to
PR
for
this
morning,
I
tested
it
looks
like
good,
but
Taylor
will
have
to
verify,
and
the
last
thing
I
didn't
necessarily
didn't
do
it
to
mention
it.
But
you
know
ed
would
mentioned
something
similar.
D
We
are
also
working
on
making
the
environment
we
stood
up
for
cross
cloud
available
to
others,
eventually
were
involved
in
cig
testing,
to
use
the
environment
to
provide
end-to-end
tests
for
the
kubernetes
as
part
of
our
own,
proud
instance,
or
integrating
with
their
existing
protestants.
But
the
goal
is
eventually
to
be
able
to
leverage
this
environment
to
provide
what
I,
what
I've
called
on
Prem
in
the
cloud.
D
D
D
We
just
went
through
this
experience
for
adding
a
platform
to
cross
file
and
there
are
a
few
gotchas
here
and
there
I
mean
without
Lucena
and
Taylor
at
Denver's
help
and
my
colleague
we
would
have
never
happened
and
I
want
to
be
able
to
both
capture
that,
but
also
to
try
to
make
it
easier
for
people
in
the
future
and
I
know
OpenStack.
You
added
yours,
you
know
when
we
use
yours
as
a
reference,
and
so
if,
if
anyone
from
there
is
interest
and
anyone
from
volk
is
interested,
please
contact
me
it's
I'll
put.
D
G
Okay
cool,
so
my
name
is
Dustin
Oh
bro
I'm,
an
engineer
over
here
at
Oracle
under
the
Oracle
cloud
group
and
word
I,
just
sort
of
wanted
to
introduce
myself
and
my
colleague
Ben
we're
going
to,
hopefully
be
one
of
the
the
next
providers
to
integrate
with
cross
cloud
and
hopefully
get
kubernetes
provisioning
using
the
services
that
you
guys
have
yeah
that
that's
really
all
I
had
you're
gonna,
see
me,
probably
in
slack
quite
a
bit
and
it
sounds
like
first
steps
are
to
to
reference
some
of
the
most
recent
providers
that
have
have
come
in
and
and
go
from
there.
H
You
yeah
I'd
like
to
introduce
myself
I'm
Ben,
like
that's
Dustin,
said
we'll
be
having
a
lot
of
questions
are
at
most
either
through
email
on
the
the
kid
project
or
through
slack
so
I'm
happy.
You
guys
are
welcoming
us
you'll,
be
hearing
a
lot
from
us
soon.
H
G
A
I
I
So
here,
I
guess:
I
went
through
and
just
did
just
the
continuous
delivery
side,
because
it
was
a
bit
easier,
there's
low-hanging,
fruit
there
and
within
CI
there's
a
bunch
of
different
ways
to
do
it
and
I
think
you
know
we
can
go
through
and
maybe
grab
from
a
continuous
integration
book.
Some
definitions
there,
but
there's
some
overlap
here,
but
artifacts.
That
was
a
problem:
how
to
define
that
and
what?
What
is
it
that
we
call
an
artifact,
whether
it
be
a
container
or
whatever,
on
environments
configuration?
I
What
exactly
is
configuration
and
then
what
is
the
pipeline
and
coming
in
and
defining
the
actual
stages
of
a
pipeline
I
think
will
go
a
long
way
to
informing
and
influencing
our
messaging
system
or
protocol.
So
the
link
is
here:
we
can
go
through
it
or
I
recommend
anyone
to
go
through
it
and
add
in
their
comments.
These
are
all
listed
directly
from
the
book,
so
it
can
debate
it,
and
maybe
you
can
say
when
contact
the
author
I
know
I
think
that's
humble
is
a
is
some
some
people
here
might
knowing.
I
So
we
probably
get
in
to
come
in
and
comment
on
some
things.
But
if
I
think,
if
we
get
through
these
definitions,
then
we
can
get
through
this
protocol
and
then
we
can
have
all
of
our
different
CI
systems
and
CV
systems
actually
working
together
because
we
can
get
the
protocol
one.
So
that's
really
all
I
wanted
to
to
go
over
here.
J
Folks
who
are
participating,
arguing
that
you
know
they
want
to
come
up
with
some
kind
of
commonality,
so
that,
as
things
transfer
as
as
you
integrate,
you
know
across
the
community,
you
may
do
a
whole
lot
of
things
differently
internally.
But
this
is
the
expectation
of
interfaces
across
communities
and
people
are
going
to
adhere
to
them
to
make
that
you
know
cross
integration,
easier,
I,.
D
J
There's
been
kind
of
an
experiment
more
or
less,
but
we
we
think
we
got
some
good
traction
with
the
past
few
events
that
have
happened,
and
so
July
2nd
I
believe
the
meeting
is
in
the
notes
for
this
meeting
to
basically
kind
of
get
some
of
this
stuff
out
and
open,
more
and
and
start
people
talking
about
it.
So
hopefully
you'll
hear
here
more
by
that
time
or
afterwards.
A
D
Want
to
put
a
bug
in
that's
everybody's
here
for
the
for
the
next
meeting.
Potentially
I
know
that
the
suggesting
is
they
were
discussing,
moving
the
singular
trout
incidents
to
the
CNC
F
at
some
point,
I'm
kind
of
curious.
You
know
what
the
I'd
be
interested
in
sort
of
an
overview
between
the
relationship
between
CNC
SEI
in
suggesting,
and
what
relocating
that
provenance
means
for
whose
responsibilities
moving
forward.
And
how
am
I
impact
the
cross
bob
dashboard?
You
know
maybe
one
learns
from
the
other
or
vice
versa,
just
if
there
are
any
plans
for
that.
D
B
This
is
Taylor
and
I'll
speak
to
that
real,
quick
and
then
happy
to
discuss
more
after
and
we've
the
cross
Claude
CI
project.
We've
we've
been
collaborating
with
sig
testing,
with
the
conformance
working
group
and
quite
a
few
different
ones.
There
seems
to
be
different
audiences
as
the
main
focus
and
the
different
groups
so
trying
to
bridge
those
guts.
A
lot
of
what
the
dashboard
was
trying
to
do
was
show
highlight
some
of
the
the
collaboration
across
the
groups
and
what
the
testing
could
be
and
that's
part
of
what
v2
would
be
about
seeing.
C
B
D
C
C
A
It
explodes
that
sounds
good.
These
meetings
are
once
a
month.
Fourth,
Tuesday
of
the
month.
They
typically
start
at
8:00
a.m.
specific
time.
We
had
a
doodle
vote
out
to
adjust
the
start
time
so
that
it's
a
little
nicer
for
our
friends
in
New
Zealand
I
will
do
another
one
for
July
24th
and
send
that
out
to
the
CI
mailing
list.
So
some
ways
to
continue
the
conversation
I'm
after
and
in
between
the
CI
working
group
meetings
is
to
subscribe
to
the
CN
CF
CI
public
mailing
list.