►
From YouTube: CNCF Serverless WG 2021-02-25
Description
CNCF Serverless WG 2021-02-25
B
C
B
D
Now
it's
fine,
but
the
storm
was
intense.
I
don't
even
know
how
to
how
to
describe
it.
I
was
lucky
in
the
fact
that
I
did
have
power
the
whole
time.
I
lost
water,
though,
on
day
three,
so
I
was
out
of
water
for
eight
days
and
had
one
one
broken
pipe,
but
thankfully
it
was
in
the
garage
and
so
it
flooded
the
garage
a
little
bit,
but
it
was
on
the
floor,
so
it
didn't
mess
anything
up
now.
A
C
B
B
C
A
C
C
C
C
All
right
so
just
reminder
we
do
have
an
sdk
call
after
this
meeting
I'll
double
check,
but
I'm
pretty
sure
we
actually
have
nothing
on
the
agenda.
Let's
just
do
a
quick
scan
there
yeah
nothing.
So
if
you
have
a
topic,
if
you
have
a
topic,
please
go
ahead
and
add
to
the
agenda
interop
discussion
last
week.
The
only
thing
I
think
worth
mentioning,
because
I
think
most
people
were
too
busy
to
do
a
whole
lot
of
work
on
their
stuff.
C
We
are
planning
on
doing
a
interop
testing,
starting
at
the
end
of
march,
with
the
hope
of
maybe
being
done
by
kubecon
and
maybe
do
some
sort
of
demo.
There
we'll
see
how
it
plays
out,
but
the
big
thing
to
know
about
that
is.
We
are
planning
on
doing
interop
testing
starting
into
march.
That
should
give
people
plenty
of
time
to
to
ramp
up
their
coding
efforts.
F
Since
last
time
we
completed
the
grpc
stuff,
we
completed
the
expression,
language
jq
and
we're
planning
our
version.
Oh
six,
release
before
kubecon
eu.
So
just
you
know
working
around
that
to
make
sure
everything
is
the
way
we
want.
That's
so
cool
all
right.
I
want
to
remind
you
about
the
cubecomb
bash.
F
G
C
All
right
moving
on
then,
so
I
got
a
note
from
the
kubecon
kukan
eu
organizers,
saying
that
they're
going
to
have
a
cloud
native
bug
bash,
which
is
well.
You
can
read
it
here.
It's
talking
about
basically
working
on
debugging
code
and
banging
on
stuff,
and
things
like
that
now,
obviously
that
won't
really
apply
for
our
spec
work.
B
C
C
Okay,
all
right.
So
I
have
a
question
and
this
is
more
of
a
get,
get
github
type
question,
because
I
wasn't
quite
sure
how
to
work
here
and
I
I
don't
feel
like
I'm
an
expert
on
on
git
to
know
for
sure
what
the
answer
is
here,
but
we
got
a
pr
for
1.0
for
1.01,
basically,
just
a
typo
type
thing,
nothing
big!
So
that's
not
the
issue.
However,
they
open
the
pr
against
the
v101
branch.
So
obviously
I
could
merge
that
pr
and
that
would
work
just
fine.
C
Now
I
think
you
can
technically
have
branches
and
tags
have
the
same
name,
but
I
think
when
you,
when
you
don't
go
out
of
your
way
to
be
quickly
clear
about
which
one
you're
actually
talking
about,
I
think
it
defaults
to
the
branch,
and
you
can
only
have
one
I'm
sorry
in
github
when
you
have
the
default
thingy,
it's
a
default
branch.
It's
not
a
default
tag.
C
So
when
someone
first
goes
to
the
repo
they're
going
to
look
at
a
particular
branch
and
we're
going
to
point
them
to
the
101
branch,
which
means
they're
going
to
see
this
pr,
this
merged
pr.
As
part
of
that
now,
obviously
it's
not
a
huge
deal,
because
it's
just
syntactical
type
things,
but
it
seems
a
little
bit
wrong
from
a
process
perspective
that
we
don't
sort
of
stack
up
these
pr's
and
then
eventually
create
a
102
right.
C
C
I
was
thinking
what
they
might
do
is
something
what
I'm
suggesting
down
here,
which
is
a
create
something
like
a
v
one,
o
stream
branch,
where
that's
where
all
the
pr's
are
sent
to,
and
then
we
just
create
tags
off
of
that
or
tags
or
branches
off
of
that,
so
we'll
create
a
101
branch
or
or
something,
but
that
way
all
pr's
can
go
to
a
stream
and
we
do
and
then
we
just
create
the
next
patch
release
from
that
stream.
How
do
other
people
do
this
kind
of
stuff?
Does
anybody
have
any
suggestions?
I
C
I
God
so
I'm
just,
I
just
wanted
to
mention
the
the
xml
1.0
fifth
edition,
errata,
meaning.
I
think
it's
okay,
if
you
don't
make
any
substantial
changes
and
if
you
just
just
make
type,
if
you
fix
dipoles
that
were
we're
looking
at
the
101
branch,
since
it
is
one,
is
it
a
tag?
Wars
branch
is
it's
a
branch
right.
It.
I
I
I
think
that's
that's
what
we
so
so
you
do
errata
for
spec,
if
you're,
finding
embarrassing
stuff
that
doesn't
change
respect
per
se,
but
that
is
just
dumb
stuff
like
typos
or
grammatic
errors
or
or
something
like
this,
but
the
the
spec
with
errata
is
still
the
same
spec.
That's
my
that's.
My
stance
on
that.
C
I
C
Yeah
yeah,
I
definitely
agree
with
updating
master
and
I
guess
I
just
wasn't.
I
just
felt
uncomfortable
making
a
change
to
the
101
branch
because,
like
I
said,
I
think
typically
in
my
mind,
it's
set
in
stone.
But
then,
if
we
do
that,
when
would
we
ever
create
a
102
because
typically
patch
releases
are
always
just
supposed
to
be
typos
type
stuff
right.
So
when
we
ever
created
102.
I
That's
the
question
and-
and
I
think
with,
if
you,
if,
if
there's
literally
just
a
typo,
I
have
a
problem
with
it,
because
ultimately,
what
there
are
still
more
people
who
don't
know
about
cloud
events
than
they
who
know
about
cloud
events,
and
we
want
them,
they
will
show
up
and
we
want
on
the
default
that
we're
showing
them.
We
want
them
to
see
the
right
document.
C
C
Right,
this
is
more
yeah,
as
this
is
more
of
a
process
and
puristic
perspective.
Right
is
101
technically
set
in
stone
or
not
and
we're.
I
think
clemens
is
saying
no,
it's
not,
but
we
are
limiting
it
to
just
patch
fixes
and
I'm
okay
with
that.
As
long
as
the
group
is
okay
with
that,
but
it
is,
it
is
a
you
know,
being
a
little
bit
wiggly
about
things.
C
C
Well,
yeah,
so
jennifer
said
it's
not
being
wiggly
as
long
as
you're
making
part
of
the
spec
yeah.
Well,
it's
it's
wiggly
in
the
sense
that
I
think
most
people
assume
that
once
you
stamp
something
as
complete,
you
know,
as
with
an
official
release,
title
or
tag
it's
set
in
stone
at
that
point
and
that
that's
the
part,
that's
wiggly
to
me
is
we're
not
keeping
it
set
in
stone
right,
we're
morphing
it
slightly
over
time.
C
K
I
I
think
that
this
is
like
a
standard
kind
of
thing
is
what
I'm
I'm
kind
of
getting
to
like
all
kinds
of
specs
will
have
the
like
deal
with
this
and
and
in
general,
my
experience
has
been
like
it
like
typos
fixing,
the
typos.
That's
just
considered
like
part
of
the
process
and
not
considered
versioning
up
the
the
spec.
It's
not
a
change
in
the
spec.
It's
not
it's
not
actually
being
wiggly,
but
as
long
as
that's
like
the
agreed
process
is
the
key
part.
Yeah
yeah.
C
Okay,
yeah,
it's
funny
her
life
be
so
much
easier
if
github
had
the
ability
to
point
to
a
tag
instead
of
a
branch.
That's
the
default
thing
when
you
go,
you
come
into
the
repo
so
such
as
life.
Okay,
so
there's
an
ai
for
me
to
do
that.
All
right,
any
other
comments,
or
whatever
on
that
topic
before
we
move
on.
C
E
C
C
Yeah
there's
still
some
outstanding
stuff
yeah,
so,
okay,
I
think
we
need
to
hold
off
a
little
more.
So
just
a
nagging
reminder
for
everybody:
please
go
ahead
and
review
his
pr.
When
you
get
a
chance,
I
think
it'd
be
nice
if
we
can
get
at
least
the
rough
draft
of
that
end
fairly
soon
just
to
get
out
of
the
pr
stage,
and
that
will,
I
think,
raise
its
visibility
for
people.
B
I
C
I
I
Maybe
I
had
a
bad
day
or
something
but
and
we've
we
have
discussed
something
about
this
and
I'm
not
sure
whether
it
might
just
have
been
that
I
had
no
time
to
look
at
it
and
you
said
because
nobody
else
here
knows
anything
about
it-
that
I
should
go
and
do
a
review.
That's
probably
more
like
it,
but
I
can
we
can
merge
that
yeah,
okay,
well.
C
C
A
I
We
were
right,
yes,
so
that's
why
I
was
that's
why
I
was
a
confused
confuser.
Yes,
we
were
waiting
on
me
and
that
I
have
to
go
and
go
back
to
because
I
don't
know
so.
I
am
opposed
to
removing
it,
but
slinky
had
removed.
Some
hats
raised
some
points
and
I
had
said
something
about
this
and
then
there
was
some
homework
that
was
assigned
to
me.
I
believe,
based
on
this,
but
I
have
to
go
back
into
the
recording,
because
I
can't
remember
what
that
was
yeah.
C
I
I
Yeah
and
and
so
and
yeah
the
credential
properties
part.
That
is
that's
pretty
essential,
also
for
the
other
one
we
need
we
need
to
take
it.
We
need
to
take
more
of
a
stance
for
these
for
all
those
for
the
triple
of
new
specs.
We
need
to
take
more
of
a
stance
in
terms
of
what
the
auth
story
will
be,
because
those
are
proper
apis
and
not
just
the
the
message
and
we're
already
like
we're
having
discussions
with
carl's
team
and
our
team
about.
I
You
know
how
the
relationship
works
between
those
two
big
big
platforms
and
most
times
being
spent
on
roles
and
permissions,
and
people
and
authorization.
So
you
can
already
tell
that
that's
a
complicated
story,
so
I
think
I
think
we
need
to
go
and
materialize
that
somehow
in
the
specs,
because
otherwise
we
can't
get
interrupt
working.
A
C
Okay,
then
just
a
quick
reminder:
unless
eric
you
want
to
talk
about
this,
we
do
have
eric's
issue
out
here
that
we
said
we're
going
to
talk
about
offline.
I'm
not
sure
anybody
had
a
chance
to
do
anything
with
it,
but
please
go
look
at
that
and
comment
if
you
are
so
inclined
and
with
that
I
will
go
ahead
and
do
the
last
of
the
roll
call.
So
manuel,
are
you
still
there?
Yes,
excellent
priyanka.