►
From YouTube: Meshery CI Meeting (Jan 14th, 2021)
Description
Meshery CI Meetings are back in 2021!
Rodolfo (@ramrodo) talks about the Meshery Cloud build and release strategy.
A
It's
in
let's,
let's
get
rolling,
welcome
everybody.
This
is
the
mastery
ci
call
so
ci
continuous
integration.
A
number
of
you
have
been
on
calls
previously
and
some
of
you
actually,
I'm
not
sure.
If
any
of
you
had
yeah,
I
know
mccool
maybe
had
been
on
this
particular
series
of
calls
that
we
had
had
in
the
past.
A
You
can
see
in
the
meeting
minutes
that
we
had
met
well
gosh
a
while
ago,
a
number
of
months
ago
we
had
been
consistently
had
topics
and
can
work
in
this
area
and
that
that
had
that
work
stream
had
sort
of
concluded
at
the
time.
But
it's
kicking
back
up
where
the
mesherie
as
a
project
has
a
lot
of
components.
A
Each
of
those
components
get
built.
Each
of
them
have
their
own
version
numbers.
Each
of
them
need
to
do
you
know
integration
testing
be
released,
be
compiled,
be
you
know
all
of
these
continuous
integration
conference,
and
so
there's
a
lot
to
do
and
there's
enough
folks
here
who
are
interested
so
we're
picking
back
up
the
meeting.
So
hopefully,
this
time
works
for
those
that
are
interested,
we're
gonna,
we're
gonna,
give
it
a
shot
one
of
the
night.
A
One
of
the
reasons
that
we're
able
to
pick
this
back
up
is
because
rodolfo
has
joined
the
community
in
force,
so
to
speak
since
last
we'd
met
so
rodolfo
had
been
around
the
community
for
some
time
and
and
then
has
more.
You
know
in
the
last
number
of
months
had
been
more
recently
actively
contributing
contributing.
We
can't,
I
can't
can't
scare
the
guy
away
so
so
we're
gonna,
we're
gonna,
embrace
and
and
he's
been
doing,
fantastic
work.
A
So
it's
not
a
platitude,
and
it's
not
me
blowing
smoke
up
rodolfo's
skirt,
so
to
speak.
If
I
can
use
some
of
those,
but
that's
to
say
that
I'm
glad
that
he's
here,
I'm
glad
he's
I'm
stepping
up
to
to
lead
this
group.
I
don't
and
I
anticipate
I'll
people
will
hear
my
voice,
but
perhaps
not
as
much
as
they
will
hear
his
and
and
for
the
rest
of
you
that
that
get
involved.
A
So
good,
so
so
with
that,
I
I
think
most
of
you
or
all
of
you,
including
raphael,
have
been
on
on
calls
before
and
so
you're
all
fairly
familiar
with
sort
of
the
the
routine
so
to
speak.
So
if
you
will,
if
you're
here
toss
your
name
into
the
meeting
minutes,
it's
nice
to
you
know
record
the
folks
that
have
joined
in
and
then,
if
you've
got
topics,
please
toss
them
in
down
below
and
we'll
we'll
start
going.
A
B
A
B
B
B
If
you
see
this
pull
request,
you
will
see
that
there
is
a
a
new
commit
message
from
cyprus,
telling
us
how
many
tests
are
passed
and
how
many
tests
fail
and
right
now
we
only
have
three
users
and
once
cyprus
allows
about
the
open
source
plan.
We
have
five
users,
but
right
now
we
only
have
three
users,
but
if
you
are
having
trouble
with
cyprus
test,
please
let
us
know
in
order
to
do
the
book
that
tastes,
those
tests
and
only
to
see
what
how
it
works.
B
B
B
C
B
A
B
A
A
C
A
Yep,
there's
not
not
really,
I
mean
we
just
recently
signed
up
this
week,
and
so
they
don't
really
know
us,
I'm
special
than
anything
else.
We've
rudolfo
has
ensured
that
we
have
sent
in
an
application
to
be
classified
as
under
the
open
source
plan.
I'm
not
sure
if
that
gets
additional.
Oh
okay,
yeah
rudolph.
You
just
said
this.
So
so
right
now
we're
constrained
to
three,
but
assuming
that
we
are
approved
under
the
open
source
plan,
we'll
have
a
total
of
five.
That's
great.
C
B
B
A
Yeah
sure
yeah,
it's
maybe
a
good
way
of
introducing
a
few
things
to
folks.
So
so
I
know
some
of
you
are
familiar
with
as
well
you're
familiar
with
the
build
process
that
goes
on
today
or
sort
of
all
of
the
concerns
that
that
come
into
account
today.
But
given
that
we're
kicking
this
up
fresh
again
and
some
of
us,
some
of
you
aren't
familiar,
it
probably
serves
us
all
very
well
to
do
kind
of
a
quick
tour
of
of
what
our
build
and
release
strategy
is
sort
of.
A
A
It's
something
that
rodolfo
had
suggested
earlier
and
gotten
us
started
with,
and
it's
helping
boost
our
confidence
as
we
go
to
make
a
release
that,
like
things,
are
actually
working
and
it's
not
just
unit
tests,
those
are
great,
but
but
the
end-to-end
integration
tests
these
functional
tests-
oh
that
is
so
much
better.
It
like
mimicking
being
a
user,
really
helps
so
so
cyprus
is
the
tool
that
that's
been
chosen
to
be
used,
we're
integrating
it
a
bit
further
like
rudolph
was
showing.
A
I
know
that
if
you're
like
me,
you've
not
really
used.
Maybe
you've
done
integration
testing
with
different
tools,
but
maybe
not
cyprus,
and
so
the
presentation
and
the
blog
post
that
rudolfo
did
are
really
helpful
in
that
regard.
There's
some
best
practices
in
there,
because
eventually
anyone
who's
contributing
in
in
the
community
they
will.
They
are
likely
to
be
asked
to
create
a
an
integration
test,
and
so
there'll
be
a
lot
of
prior
art
and
there
is,
there
are
integration
tests
that
are
included
today
as
examples
but
yeah.
A
So
there's
a
record.
I
think
rodolfo
presented
that
at
at
a
previous
meeting.
If
there
isn't
a
link
to
it,
I
think
there's
probably
a
link
to
it
in
the
blog
post.
Maybe,
but
just
ask
if
you
want
to
watch
the
recording
so
so
then,
back
on
on
our
overall
build
and
release
strategy,
I
have
probably
confused
two
things.
A
A
Rather,
I
meant
I
meant,
if
you
don't
mind,
sharing
but
I'll.
Let
me
do
it
real,
quick
here,
so
so
do
do
click
into
here!
This
is
fairly
well
written.
It
needs
a
couple
of
updates
when
we
first
started
mesherie,
it's
a
little
over
well
a
little
over
a
year
ago
I
mean
you,
can
you
can
see?
Actually
when
we
first
started
measuring
when
we
first
started
making
releases,
you
can
see
that
inside
of
mysteries?
Well,
you
can
go
to
github.
You
can
go
to
meshrey's
documentation.
A
You
can
go
to
the
releases
section
and
you'll
sort
of
scroll
back
in
time
to
when
things
were
initiated.
I
think
you'll
see
commits
in
the
github
repo
a
number
of
months
earlier
than
this.
We
just
didn't
get
around
to
making
a
release,
and
so
anyway,
so
we've
been
the
project's
been
around
for
a
while.
The
first
continuous
integration
system
that
was
used,
I
think
there
was
initially
some
some
circle
ci
and
we
looked
at
travis
ci
a
little
bit.
A
It
seemed
to
be
like
you'd,
get
a
little
bit
more
as
an
open
source
project
and
and
then
github
actions
were
announced.
I
don't
you
know
sometime
in
this
area
last
year
or
that
year
rather
yeah.
I
guess
it's
two
years
ago
now,
and
so
we
switched
into
github
actions
and
been
using
workflows
and-
and
we've
been,
you
know,
collectively
as
a
community
lots
of
has
been
learned
about
how
what
those
actions
are
and
how
to
use
them.
A
A
A
If
you
deploy
mesh
tree
using,
if
you
deploy
measuring
today,
that
those
are
kind
of
the
components
that
you'll
see
the
the
reality
is
there's
any
number
of
other
smaller
logical
components
that
can
be
released
independently
and
so
meshrictl
is
a
smaller
component.
It's
the
command
line,
client
that
the
code
base
from
s3ctl
is
inside
of
the
measure
repository
that
measure.
Ui
is
another
client
and
the
code
base
for
it.
It's
it's.
A
You
know
react.js
and
it's
next.js
and
react
that
codebase
is
also
in
the
measure
repo,
but
these
are
individual
components
and
they
some
of
these
carry
different
release.
Numbers
like
the
adapters.
They
carry
their
own
release,
numbers
and
and
some
don't
and
because
there's
like
40-something
repositories
and
there's
a
lot
going
on
and
mescheri's
mystery
as
a
project
has
a
large
vision.
You
know
these.
A
These
independent
components
get
released
and
versioned
at
different
rates,
and
so
there's
a
dock
here
that
talks
about
upgrading,
measuring
and
just
a
quick,
a
quick
visual
to
show
you
that
the
command
line
client
has
its
own
binary.
It's
written
in,
go
and
compiles
to
a
single
static
binary,
so
it
gets
it
because
it's
in
the
same
reap
measuring
repo
as
meshri
server.
A
A
A
It's
intended
that
istio,
as
a
service
mesh,
for
example,
will
make
its
releases
every
so
often
and
that
istio
that
measury
adapter
for
istio
it
needs
to
try
to
keep
pace,
and
so
that
pace
is
going
to
be
different
from
mastery
server
and
measure
ui,
and
all
these
components
like
we're
not
trying
to
master
orchestrate
that
they're
all
built
and
released
all
the
exact
same
time.
Rather
that's
what
microservices
are
about
like
that's
you.
A
Rather,
we
have
different
community
members
showing
up
at
different
times
to
do
different
things,
and
so
we
want
to
empower
them
and
and
and
be
able
to
make
and
build
and
release
things
independently.
So
that's
that's
kind
of
the
back
story
as
to
why
there's
there's
a
number
of
components,
different
versions
of
those
things
there's
the
consideration
for
as
a
user
goes
to
upgrade,
what
do
they
need
to
watch
out
for
and
how
are
those?
How
are
those
things
versioned?
A
That's
not
what
we're
trying
to
talk
about
today,
but
I
wanted
to
point
that
out,
because
it's
important
with
respect
to
the
fact
that
as
a
build
is
as
a
workflow
executes,
there
can
be
any
number
of
artifacts
to
come
out
of
that
build
and
those
artifacts
generally
are
like
you
know,
one
to
one.
There's
generally,
if
you've
got
a
mastery
component
like
mastery
server,
there's
an
artifact
for
that.
A
If
you've
got
a
measuring
ctl
as
a
command
line,
client
there's
an
artifact
for
that,
and
so
in
general
you
know
the
vast
majority
of
the
artifacts
that
are
built
they're
either
the
output
of
them
is
it's
much
of
the
output
of
the
builds
is
either
a
docker
image,
so
mesh
free
server
is
compiled
and
created
inside
of
a
docker
image.
It's
pushed
to
docker
hub,
so
the
artifact
repo
there
is
docker
hub.
A
A
A
C
A
So
there's
a
particular
tool:
that's
used
to
build
measuring
ctl,
it's
called
go
releaser
and
that
go
release
or
that
tool
is
invoked
as
part
of
the
workflow.
So
just
to
familiarize
everyone,
the
workflows,
the
github
actions
and
the
workflows
everyone
here
and
you
should
be
able
to.
You-
should
see
an
actions
here
and
be
able
to
get
a
view
over.
A
These
are
the
individual
workflows
that
might
they
each
have
their
own
trigger.
They
each
get
triggered
based
on
different
events,
but
I
bring
this
up
because
in
the
workflows
that
build
out
the
go
code
like
like
this
one,
one
of
the
steps
that
it
has
it
builds
it
builds
the
server.
You
may
run
some
some
tests
for
the
server
it
may
build
the
back
end.
A
A
Is
in
the
top
the
root
directory
here
under
co-releaser,
so
this
this
utility
it
has
its
own
configuration
and
we're
saying
we
want
you
to
try
to
build
against
these
architectures,
or
rather
these
architectures
for
these
operating
systems,
and
so
this
affects
only
the
command
line.
Client
as
part
of
that
what
this
tool
does
it
generates
a
checksum
and
that
is
deposited
along
with
the
rest
of
the
artifacts.
A
Docker
images
are
also
created,
those
docker
images
so
that
the
docker
images
are
built
and
depending
upon
which
workflow
is
invoked.
They
may
be
pushed
out
to
docker
hub,
and,
let's
see
so
so
this
this
build
for
for
optimizing
images,
it
was
done,
it
was
a
build,
was
done,
it
was
docker,
images
were
created,
check
sums
are,
you
know,
are
made
and
you'd
go
to.
I
think
docker
hub
to
look
at
those
check,
sums
so
cool.
So
like
it's
more.
C
C
C
A
Yep,
that
makes
sense
so
then,
to
take
people
cut
through
the
rest
of
the
build
and
release
strategy
like
they'll
just
touch
on
some
high
level,
things
which
is
there's
there's
any
number
of
artifacts
to
come
out,
use,
github
actions
and
workflows,
the
five
or
so
workloads
that
we
were
just
sort
of
looking
at.
They
get
kicked
off
based
on
different
events,
different
triggers
and
you
get
you
all
of
and
there's.
This
is
actually
an
area
of
need.
A
So
right
now,
if
you
go
out
of
just
let's
just
pick
the
documentation
build,
so
so
the
workflow
that
kicks
off
when
there's
an
update
to
docs.
Well,
what
triggers
this
workflow?
Well,
it's
it's
actually
right
here!
It's
these!
It's
these
lines!
This
is
the
name
of
the
workflow
itself,
but
it
triggers
on
or
the
event
that
causes
it
to
start
is
when
there's
a
git
push
and
that
that
push
includes
changes
to
files
underneath
docs.
A
So,
just
by
way
of
introduction
to
like
the
fact
that
they're
they're
triggers
okay
I'll
try
to
do
this
even
faster,
which
is
there's
a
lot
of
workflows,
we
do
automated
builds,
they
get
triggered.
You
build
container
images,
we
push
them
out,
we
we,
you
have
to
label
your
container
images.
So
we
do
we
tag
them.
There's
really
just
there's
a
few
tags
that
we
end
up
using
you.
Can
we
use
tags
to
to
assign
a
version
number
like
hey?
What
release
was
that?
A
A
As
part
of
that
turns
out,
you
can
create
a
lot
of
docker
tags
and
in
using
those
we
essentially
use
docker
tags
to
create
release
channels
so
measuring
itself
and
and
each
of
the
components
each
of
the
adapters
and
the
clients
have
two
release
channels
and
that's
because
because
in
part
what
mert
was
just
saying
he
was
going
to
use
the
word
nightly
like
hey.
How
often
do
builds
happen?
Well,
how
often
do
they
happen?
They
happen
as
and
when
an
event
triggers
them.
So
they
don't.
A
A
Now
we
want
to,
we
want
to
continually
be
running,
builds
and
making
sure
that
things
are
working
and
functioning
and
continually
be
running
tests
and
verifying,
and
we
want
to
get
that
code
into
people's
hands
early
and
quickly,
and
so
there
have
been
these
two
release
channels
created
to
facilitate
that
there's
the
stable
channel,
which
I
bet
you
all
can
guess.
The
purpose
of
that
stable
channel
is
like
you
know
that
things
are
well
baked.
The
the
bugs
have
been
mostly
worked
through.
A
So
I
was
saying
before,
like
basically
all
of
the
artifacts,
that
the
project
produces
almost
all
of
them
come
out
as
a
docker
image
other
than
mesh
free
ctl
and
it's
a
binary,
and
so
we
can
use
docker
tags
to
identify
and
clarify
between
two
channels.
There's
a
stable,
stable,
channel
edge
channel,
so
the
every
time
and
and
the
code
is
pushed
to
the
stable
channel
or
artifacts
are
pushed
to
that
stable
channel.
A
When
a
release
is
made
when
a
tagged
release
is
made
when
I,
when
a
human
goes
in
and
says,
oh,
you
know
what
it's
actually
time,
we're
good
it's
time
to
make
a
release
to
the
stable
channel,
we'll
and
I'll.
Take
you
through
what
that
process
looks
like
in
a
minute,
but
so
that's
a
manual
thing
like
hey
someone
has
said
we're
comfortable.
Let's
release
it.
A
The
edge
channel
and
how
new
releases
go
into
the
edge
channel
that
works
differently,
it's
a
little
more
willy-nilly,
it's
not
willy-nilly
and
so
much
as
it's
just
a
lot
faster,
so
in
the
edge
channel
any
time
that
a
pull
request
is
merged
to
the
master
branch.
This
is
true
for
all
the
repos
like
anytime,
that
a
pr
is
merged
to
the
master
branch
for
that
repo
and
edge
release
is
made,
which
is
to
say
that
in
a
pull
request,
we're
executing
workflows,
we're
doing,
builds,
we're
doing
feature
integration.
A
Tests
artifacts
are
produced
like
the
code
is
compiled
and
images
are
created.
Well,
if,
if
someone
said
yep,
that's
a
good
good
contribution,
let's
merge
it
well,
those
artifacts
will
then
be.
You
know
like
pushed
to
docker
hub
and
they'll,
be
tagged
with
edge
latest,
so
so
the
last
the
last
merge
to
master
that's
the
latest
edge
release
edge
is
like
is
right
on
the
edge
of,
and
so
that's
very
helpful
to
getting
things
into
people's
hands
quickly.
A
A
So
if
so,
if
I'm
here,
just
I'm
on
my
my
system,
if
I'm
I
can
interface
with
mastery
ctl-
and
I
can
I
can
do
a
few
things-
I
can
say-
hey
measure
ctl,
like
you
know
what
what
version
of
things
are
running
well
immediately,
very
quickly,
it's
going
to
respond
with
itself
its
own
versions,
it's
going
to
say
well,
I
know
like
that's
built
into
my
binary.
When
I
was
created,
I
I
got
assigned
my
version
number.
I
know
what
that
is
I'll.
A
A
So
if
there's
a
message
server
available,
I'm
going
to
try
to
go
interior,
ask
it
hey
what
version
are
you
because,
because,
even
though
these
things
are
packaged
and
released
at
the
same
time,
they
get
installed
separately
and
and
as
such,
their
upgrade
path
isn't
necessarily
married
like
mesri,
client
and
server
they
will.
You
could
be
running
different
versions
and
they
generally
will
work.
A
There
are
various
points
in
time
where
they
might
not
work
so
part
of
what
we
do
here
is
if
someone
is
being
diligent
enough
to
to
look
at
this,
not
only
will
mesh
ctl
reach
out
to
mesri
server
and
ask
it
what
version
it's
running.
It
will
also
reach
out
to
github
and
say:
hey:
what's
the
latest
stable
release?
What's
the
latest
release
stable
release
turns
out
that
this
is
the
latest
release,
so
so
we're
good.
A
If
that
wasn't,
if
they
weren't
running
that
it'll
say
it
will
prompt
them
and
say:
hey,
do
you
want
you
know?
Maybe
you
should
upgrade?
Maybe
you
should
so
the
so
that's
good,
but
the
thing
that
we
were
just
talking
about
was
the
fact
that
they're
like
these
these
channels,
by
default,
when
you
install
mastery
you're,
subscribed
to
this
stable
channel
and
by
subscribed
I
mean
that
we
really
want
to.
You
know,
facilitate
and
encourage
users
to
get
the
latest
releases
into
their
hands
as
quick
as
possible.
A
A
A
Anyway,
you
yeah
anyway,
just
you
can
you
can
assign
different
tags,
and
so
when
a
new
image
is
pushed
and
stable
latest
is
moved
to
a
new
image.
Well,
you
can,
if
you
just,
if
you
you
can
run
a
system
update
and
you'll
you'll
go
out
and
you'll
get
the
latest
images
pulled
and
every
time
you
start
mastery,
it
doesn't
update
it.
Does
a
docker
pull
so
that
you're
subscribed
to
that
channel
you're,
always
getting
latest
from
that
channel.
A
Cool
good,
so
we
empower
users
with
the
ability
to
like
switch
from
edge
to
stable
or
stable
to
edge,
and
some
of
this
is
undergoing
some
change
right
now.
There's
a
couple
of
contributors
working
on
that,
but,
okay,
that
so
they're
released
channels.
There's
release
processes,
there's
a
lot
of
considerations
about
things
that
are
done
a
number
of
a
lot
of
things
to
do
so
with
that
I'll
I'll
pause
and
say.
A
Hopefully
that
did
what
the
what
questions
that
people
have
like
to
do.
There's
some
specific
things
to
talk
about
that.
I
think
that
might
be
of
interest
to
folks
and
people
might
want
to
pick
up
and
do
I
know
rodolfo's
got
kind
of
a
long,
a
broad
and
wide
sort
of
agenda
around
integration,
testing
and
all
of
what
that.
A
A
A
Nice,
okay,
good
now
so
alonso
was
kind
enough
to
chime
in
saying,
hey,
look,
you
know
hey,
I
did
I
didn't
blow
his
mind
or
like
he.
He
he
got
it,
which
is
great.
That
actually
brings
just
thinking
of
alonso.
I
start
to
think
about
some
of
the
good
work
that
he's
done
around
trent
transcription
of
our
measuring
docs
into
spanish,
which
has
me
thinking
about
how
docs
relate
to
builds
well.
Okay,
there's
there's
kind
of
an
interesting
thing
that
happens
in
the
the
build
process,
and
it's
not
documented
right
here.
A
So
I'm
gonna,
I'm
gonna
go
back
to
the
to
our
notes.
I'm
gonna
go
ahead
and
it
is
documented
in
this
other
doc,
just
because
more
effort
was
given
to
this
recently.
So
I'm
gonna
pull
this
open
there.
Every
time
that
a
release
is
made
there
is
one
of
the
workflows
is
that
a
small
utility
will
run.
One
of
the
github
actions
is
called
release,
drafter
and-
and
it
is.
A
It
helps
take
all
it's.
Basically,
it
automatically
creates
a
change
log
and
says
like
hey
since
last
time
that
you
made
a
release:
here's
all
the
the
pr's
that
have
been
merged,
here's
all
the
issues
that
have
been
closed
and
so
the
github
action
that
we
use.
It's
called
it's
called
release
drafter
and
to
see
what
it
does
in
action.
All
of
you.
Any
of
us
well
can
go
to
the
releases
area.
A
A
If
it's,
if
it
sees
something
as
carrying
the
the
issue
label
docs
technically,
it's
area,
slash
docs,
but
docs
it'll,
then
categorize
it
and
put
it
under
docs,
and
so
so
great.
So,
actually,
if
you
look
at
the
draft
what
it
has
drafted,
it's
been
about
a
month
since
we
made
a
release,
we've
had
all
kinds
of
kind
contributors,
doing
doing
things
and
there's
they've
done
lots
of
docs
they've
done
lots
of
dependable
stuff.
A
That
pains
me
so
bad
and
then
got
some
features
and
we've
got
some
basically
uncategorized
things,
a
bunch
of
general
things
that
have
been
done
and
so
like
it's
it's
actually
time
to
make
a
release.
It's
been
about
a
month.
We
kind
of
need
to
get
there,
but
what
the
reason
that
I
totally
digressed
into
this
was
to
say
alonso
reminded
me
that
in
the
past
it
had
been
the
case
that
we've
had
a
certain.
We
have
these
auto-generated
release,
notes
and
release
drafters,
helping
us.
A
Let's
that's
good,
and
you
know
people
can
come
here
and
look
through
this
that
helps.
But
it's
not.
It
wasn't
the
end
game.
It
wasn't
quite
where
we
wanted
to
all
get
to.
We
wanted
to
also,
as
people
go
out
to
measure
and
they're
like
hey,
what's
going
on,
what
is
this
tool?
Should
I
use
it?
You
know
are
people
working
on
it.
You
know.
What's
what's
the
latest
etch,
what
release
am?
A
I
is
that
we
were
missing
the
automation
of
the
step
that
that
would
go
from
literal
mark
down
here
to
mark
down
over
here
and
I'm
a
contributor
that
I
joined
the
community
sit
on.
He
had
helped
in
this
area,
so
he's
he's
helped
automate
this.
So
so
you
can
see
his
auto
I'll
show
you
the
workflow,
but
the
automation
is
to
just
take
the
output
of
those
draft
notes
and
paste
them
and
paste
them
into
check.
You
know
the
the
documentation
here
and
so
yep.
A
Yeah
I
mean
there's
like
a
there's,
a
there's,
a
there's.
You
know
a
year's
worth
of
stuff
to
talk
about,
but
but
but
I
know,
we've
got
some
things
that
we.
I
know
I've
got
some
things
that
I'd
like
to
see
accomplished,
but
rodolfo
is
rudolph.
Do
you
want
to
just
so?
If
someone
doesn't
say
something
I
keep
talking.
If
people
are
interested
in
an
area,
please
signal.
If
you
think
we
should
be
doing
something
differently,
please
signal
else,
rodolfo's
likely
to
come,
knocking
on
your
door,
saying
hey.
A
B
Speak
to
this,
this
note
yeah.
That
suggestion
is
to
not
request
peer
review
or
non-merge
pull
requests.
If
the
test
have
not
passed.
This
is
because,
if
we
merge,
some
changes
that
are
failing
the
test
later
on
is
difficult
to
identify
the
bug
in
order
to
fix
that.
So
the
main
mission,
or
the
main
goal
of
this
is
to
have
master
always
passing
the
test.
If
we
have
master
always
in
green,
it
will
help
to
deploy
and
to
contribute
faster.
A
So
good
because
I
could-
because
I
know
for
my
part,
I
could
talk
about
this
for
another
couple
hours
explaining
how
all
this
stuff
works.
We
won't
do
that
instead,
I'll
do
this
I'll,
say
raphael.
It's
been
a
little
while,
since
I've
seen
you
very
nice
to
see
you
again,
I
was
very
encouraged
by
some
of
the
questions
you
had
asked
a
while
ago.
D
I
would
like
to
work
on
the
on
the
plugins
as
well
as
the
adapter
I
can
offer
in
terms
of
my
experience
in
building
around
mystery
adapters.
So
I
so
that's
a
co
expert.
I
really
would
like
to
be
involved,
and
this
year
I'm
happy
I'm
going
through
in
terms
of
the
continuous
integration
actually
as
well
as
seeing
what
cyprus
can
do,
as
well
as
I
in
terms
of
the
work
workflow
on
github,
so
that
is
it,
but
it
caught
expert
in
terms
of
the
testing.
A
A
A
Utkarsh
who's
on
the
call
right
now
is
a
great
individual
to
have
a
chat
with
about
the
adapters
they
they
are.
They
have
just
undergone
a
re-architecture
and
there's
there's
much
more
to
do
with
them.
It's
it's
great,
because
the
re-architecture
puts
puts
them
in
a
much
better
place
where
they
can
each
go.
Each
of
the
adapters
can
go
off
and
do
some
deep
integrations
with
individual
service
meshes.
So
so
it's
about
to
get
super
interesting.
A
So
a
lot
of
you
are
absolutely
welcome
on
all
of
the
calls
and
don't
join
any
of
them.
That
interest
you,
the
one
that
where
measuring
adapters
gets
get
talked
about.
Even
more
is
on
wednesday's
measuring
dev
call,
there's
generally
some
talk
about
adapters
there
and
then-
and
we
will
talk
about
them
here,
because
obviously
they
need
continuous
integration
and
releasing
and
all
that
the
community
call
gets
gets
to
mention
about
them
as
well.
So
that's
great
raphael.
That's
good!
I'm
glad
that
we're!
E
So
there
is
this
tool
known
as
the
code
call:
it's
like
code
coverage
sort
of
thing.
So
what
it
does
is
like
it
can
generate
another.
We
can
have
another
workflow,
the
github
workflow
with
it,
and
according
to
all
the
statistics
based
on
the
tests,
it
basically
generates
a
result,
and
it
has
a
very
nice
dashboard
which
will
like
give
us
like
okay.
So,
let's,
let's
say
that
there
is
this
website
project
and
it
has
an
src
folder.
So
inside
src
folder.
E
Let's
say
that
there
is
this
one,
entire
page
you
could
say
that
has
been
tested
only
like
the
66
percent
of
the
entire
components
that
have
been
tested.
So
it
gives
a
sort
of
a
dashboard
to
us
which
tells
us
that
how
much
code
is
tested,
how
much
is
remaining
and
the
best
part
is
also
highlights
the
functions
that
haven't
been
hit
by
the
tests.
B
E
E
And
one
of
the
amazing
things,
of
course,
that
I've
seen
in
some
of
the
open
source
projects
is
that
you
could
even
set
a
threshold
like
one
of
the.
I
think,
one
of
the
things
that
you
said
that
not
request
a
pr
review
or
not
to
merge
any
prf
test
have
not
been
passed
yet.
So
there
is
this
threshold
of
so
like
every
full
request
that
the
people
are
making
these
days
usually
does
not
have
any
sort
of
test
along
with
it.
So
what
can
be
done
in
this
code?
E
E
So
if
a
person
lands
up
a
pr
and
their
pr
does
not
satisfy
this
criteria,
it
will
defer
the
person
to
merge
the
pr
as
well
as
it
will
not
allow
any
sort
of
you
could
say
re-tagging
and
like
people
again,
tagging
anyone
and
even
merging
the
pr.
So
what
it
does
is
it
basically
works
on
that
threshold
and
it
does
not
allow
the
pr
to
be
merged
before
we
improve
onto
that
beyond
and
above
that
thresh.
C
So
I
mean
that
we
have
a
technical
meeting
today,
which
is
related
with
continuous
integration
and
security.
So
so,
if
I
look
at
the
code
of
conduct,
which
is
which
follow
which
is
maintained
by
foundation,
I
see
that
personal
relationship
issues
like
personal
attacks,
trolling,
public
or
private
harassment,
but
should
can
we
add
some
technical
details
like
coding,
standards
or
security
standards.
I
mean
that.
A
Yep
yeah
be
yep,
the
larger
the
project
gets
the
more
important.
All
of
these
things
become
the
the
actually.
The
reason
that
there
aren't
a
bunch
of
unit
tests
and
code
coverage
is
is
a
very
clear
reflection
of
the
maturity
of
the
project.
Like
hey,
nobody
cares
about
whether
or
not
there's
unit
tests.
A
If
it
doesn't
do
something
really
functionally
excellent
or
that's
very
helpful
to
me,
then
it
could
be
as
secure
as
they
could
have
the
best
you
know
like
we've
got
a
really
great
community
actually,
but
the
project's
gonna
do
something
well
so
anyway,
my
point
is:
is
yeah
those
make
a
lot
of
intuitive
sense
that
well
the
unit
test.
The
code
coverage,
the
security
stuff,
the
code
of
conduct
et
cetera.
We
just
for
my
part.
A
So
we
do
follow
the
cncf
code
of
conduct
in
terms
of
like
coding,
conventions
yeah.
Those
are
some
good
things
to
it's.
Really,
it's
really
difficult
thing
in
general
to
be
very
warm
and
welcoming
and
encouraging,
and
also
at
the
same
time
like
slap
someone
with.
Oh,
you
didn't
pass
the
unit
test.
So
no
we're
not
going
to
take
it
a
lot
of
times.
People
don't
come
back,
they
just
they
don't
like
it's
like
well
or
they
didn't
sign
the
the
the
dco
they
forgot
to
sign
their
commits.
A
It's
like
well
and
they
don't
come
back
and
then
or
hey
you've
got
to
start.
We
do.
You
know
test
driven
development.
First,
write
out
your
your
unit
test
like
oh
geez,
I
don't
they
don't
like
to
be
to
be
really
candid:
there's
lots
and
lots
and
lots
of
folks
in
the
community
who
don't
who
have
a
hard
enough
time,
forking
a
repo
like
pushing
back
to
it,
so
yeah
we're
in
a
state
of
flux
in
terms
of
like
starting
young
and
small
and
growing
to
a
maturity
level
so
we'll
get
there.
A
C
A
Oh
sure,
yeah
yeah
and
having
those
written
down
and
stuff
it's
it's.
So
it's
a
good
thing
like
hey:
do
we
yep?
Don't
don't
let
any
of
those
comments
that
I
said?
Stop
you.
I
think
that
was
more
of
an
explanation
as
to
why
we're
only
so
far
along
there
in
terms
of
yeah.
So
the
one
thing
to
like
dig
your
heels
into
potentially
is
is
maybe
trying
to
advance
the
project
to
from
cii
passing
to
cii
silver.
A
And
so
as
you
continue
to
as
you
as
it
is,
as
this
is
an
area
of
interest
to
you,
one
one
area
to
like
pour
your
energy
into
potentially
is
is
to
take
us
from
passing
to
silver,
then
the
next
step
and
what
you
know.
What
does
that
mean?
Like?
I
think
right
here.
We
currently
have
a
question
mark
and
we
would
have
to
move
this
to
oh,
okay,
yeah,
that's
no
problem!
Yeah!
This
needs
to
be
done
anyway.
We
needed
to
find
some
governance
but
yeah.
A
B
A
Nice
very
good,
all
right
same
same
time.
Next
week
it
sounds
like
chewbacca
will
get
it
they'll
be
in
make
some
progress
on
code
cove,
michael
goodfeller.
Sometimes
he
he
goes
by
miku.
That's
how
you
give
us
how
you
say,
michael
in
in
swedish.
I
think
his
is
he's
interested
in
codec.
I
think
he'd
mentioned
codecov,
specifically,
I
think
a
little
while
ago
and
a
real
bright
guy.
I
don't
know
if
you
guys
know
he's
actually
writing
a
blog
post
right
now.