►
From YouTube: Platform Sync: 2020-12-09
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
A
A
All
right,
we
could
get
started
with
some
status
updates.
I'll,
kick
it
off
by
saying
that
I've
started
working
on
setting
up
tecton
instance
in
gke
via
terraform,
that's
going!
Okay,
there
there's
a
little
bit
of
wrestling.
You
know
in
the
learning
curve
for
terraform,
specifically,
what
I'm
trying
to
achieve
is
set
it
up
in
a
way
where
we
could
have
this.
A
So
a
little
bit
of
effort
going
on
in
there.
There
are
a
couple
of
other
things
I
started
looking
into
regarding
the
samples
repo
there's
a
couple:
ci
cd
configurations
there,
the
circle
ci
isn't
working
because
it
doesn't
have
permissions
to
write
the
report
tamil
using
the
pocato
builder,
I'm
going
to
try
with
the
sample
builder,
but
I
feel
like
last
time
this
was
reported.
It
was
an
issue
with
the
linux
version
that
was
being
used.
A
B
Updates
I've
been
plugging
ahead
with
the
sub
commands.
At
this
point
we
have
the
start
of
config
submand,
there's
and
build
pack
as
well
and
builder.
I
just
made
another
small
thing
for
pack
and
fig
default
builder
and
I
hope
to
round
out
two
more
config
ones
and
I
think
there's
discussion
over
pack
images.
I
have
posted
some
feedback
on
that
issue.
People
can
feel
free
to
chime
in
on
that
yeah.
C
D
B
A
So
one
of
the
concerns
I
have
is
is
a
theme
that
is
recently
coming
up
regarding
the
build
pack
uris.
I
know
I
haven't
technically
merged
that
pr
in,
but
it's
supposed
to
address
a
lot
of
those
use
cases
that
have
been
coming
up.
I
wonder
if
it's
worth
creating
a
a
patch
release
with
just
that
pr,
essentially
to
to
further
improve
that
part
and
hopefully
minimize
that
impact.
A
B
B
You
know
the
public
clamoring
on
our
doors
yeah,
but
at
the
same
time
I
do
I
I
don't
like
having
you
know
the
you
know
sport,
so
I
definitely
hear
that
I
just
feel
like
it
could
be
just
doing
a
patch
release
with
that
could
end
up
being
a
bit
more
complicated.
Just
you
know,
rebasing
it
etc,
but
yeah.
I
definitely
feel
like
the.
A
So
so
there
would
be
effort
there,
and
then
I
think
this
is
a
riskier
change,
where
I
would
kind
of
propose
that
we
have
a
longer
rc
period
for
and
maybe
that's
a
a
viable
option
too.
It's
like
producing
rc
if
we
are
able
to
before
the
what
is
it
the
release
date
that
we
currently
have,
and
maybe
that
way.
If
people
are
running
into
certain
issues,
we
could
tell
them
to
try
the
rc
build.
B
It'd
be
great
if
we
could
get
the
main
consumers,
I
guess
attack
that
being
the
vacato
project
and
google
to
use
c
builds
to
kind
of
actually
test
it
out
like
this
would
have
been
great
for,
if,
like
the
spring
boot,
had
used
this,
and
then
you
know
found
this
out.
While
we
were
still
in
mercy
because
you
know
they
are
one
of
the
main
consumers
that
it's
something
I'd
love
to
explore
in
the
future
I'll
jot
down
a
note.
A
D
E
I'll
just
add
that,
on
the
life
cycle
side,
we
are
looking
to
make
like
some
improvements.
I
guess
to
the
release
process
and
the
way
we
circulate
release
candidates.
You
know
to
potential
consumers
so
well,
whatever
you
learn
about
good
practices
there
I
think
we'd
wanna
try
to
evaluate
those
as
well.
A
A
E
And
so
one
idea
that
we
came
up
with
is
with
labels
so
similar
to
what
we're
doing
with
the
rfcs
using
a
label
to
designate
the
sub
team.
That
would
be
responsible
for
those.
And
then
I
guess,
there's
like
some
automation
that
we
can
use
to
designate
an
owner
so
that
person
can
not
necessarily
do
the
work
but
monitor
and
ensure
that
it
is
done.
At
some
point.
C
C
B
B
A
A
So
I
mean
sorry
to
like
really
dive
into
that
one,
though
right
so
you're,
wanting
to
assign
issues
to
yourself.
How
does
that
play
into
this
idea
where
at
least
the
rfcs
right
now
or
random
right?
So
like
you,
we
would
specify
something
like
platform
and
it
would
randomly
pick
somebody
from
the
platform
team
and
own
them
or
make
them
owners.
Are
we
saying
that
that
we
want
a
separate
mechanism
that
that
would
work
or
that
you
want
the
flexibility
to
do
both.
C
Oh,
that's
a
good
question,
maybe
there's
two
different
so
there's
like
maybe
two
different
people
that
are
opening
issues
because,
like
the
I
think
that
the
issues
I've
opened
on
the
docs
repo
have
been
like.
Oh
I've
written
a
feature,
I
should
add
documentation
for
it.
That's
like
really
part
of
the
story
delivery
and
it
would
be
useful
for
me
to
be
able
to
just
be
like
okay.
This
is
on
my
queue.
It's
like
when
the
stuff
gets
accepted
and
goes
through.
C
A
A
D
Yeah,
that's
me.
I
just
had
a
quick
question
that
came
up
during
a
one-on-one
I
had
with
joe
this
morning,
so
he
might
bring
it
up
in
working
group,
but
I
figure
since
I'm
here
I
might
as
well
ask
we
were
wondering:
what's
the
criteria
or
how
like
what's
the
process
from
going
from
an
experimental
feature
to
an
actual
feature
for
pack,
because,
for
example,
right
now,
as
we
think
ahead
with
some
of
the
registry
work
that
we've
been
working
on?
A
So
I
think
like
for
sure
the
registry
is
a
little
bit
easier
to
look
at
right,
because
I
think
we
had
a
very
like
almost
detailed
road
map
for
when
that
would
come
out
of
experimental,
and
that
was
when
we
had
the
pocato
and
roku.
And
I
guess
those
would
be
the
only
two
that
I
could
think
of
build
packs
in
the
registry
and
we
would
have
people
consuming
them
via
pack,
experimentally
right
so
like
we
needed.
D
D
A
I
think
it
isn't
until
just
very
recently
that
the
build
packs
actually
got
in
the
registry,
but
we
don't
have
any
consumption
yet
right
so
it'd
be
up
to
when
we
have
that
consumption,
where
I
think
we
could
say.
Okay,
now,
we've
we've
kind
of
ironed,
all
the
kinks
out,
and
we
could
kind
of
bring
it
to
non-experimental
mode.
At
least
that
was
the
impression
I
was
okay.
D
Yeah,
like
we're
not
trying
to
to
push
it
or
anything,
I
think
we're
just
trying
to
be
conscious
of
what
we
need
to
consider
as
we
continue
to
iterate
on
it
and
just
make
sure
that
you
know
we're
on
the
same
page.
So
it
just
sounds
like
we're
moving
in
that
direction,
but
until
it
stabilizes
a
little
more
and
we
get
more
involvement,
then
we'll
kind
of
get.
B
Yeah,
okay,
I
definitely
feel
like
urc
is
a
very
useful
part
of
that,
because,
like
it's
wouldn't
be
helpful
to
under
to
I
mean
find
it
you
can.
We
can,
you
know,
take
it
out
of
experimental
people
can
extensively
use
it,
but
the
search
the
search
functionality
right
now
is
not
super
great,
so
like
it
would
be.
It
wouldn't
be
like
super
value
adding
for
users
at
the
moment.
A
But
I
think
you
have
the
the
inverse
too
right,
like
you
could
look
at
this
where
the
registry
won't
be
the
like.
They
won't
search
the
registry
for
build
packs
to
use.
I
think
what
I've
heard
this
through
one
of
the
working
group
meetings
is
that
they'll
see
hey.
You
know
joe
just
announced
that
he
produced
the
minecraft,
build
pack
right
and
then
he
has
some
sort
of
snippet.
A
A
I
think
what
like
personally,
I'm
looking
forward
to
is
making
sure
that
there's
not
going
to
be
any
additional
changes
to
the
way
that
we've
structured
the
data,
because
those
discussions
have
come
up.
You
know
as
part
of
this
rfc
it's
like,
should
we
add
additional
metadata
every
time
we
consume
the
the
image
or
something
like
that
right,
yeah.
D
Yeah,
I
agree.
I
do
see
them
as
two
separate
things.
It
does
help
having
a
better,
more
robust
search
capability
to
you
know
to
drive
that
user
experience
from
pac
but
yeah
I
do.
I
do
see
them
as
a
as
independent
but
yeah.
I
agree
with
you,
javier,
that
I
think
there
has
been
some
good
discussions
that
would
be
nice
to
iron
out
a
little
more
and
solidify
around
that
have
come
up
in
this
rfc
so,
like
I
said,
I'm
not
in
a
hurry
personally
and
I
don't
think
joe
is.
D
A
Yeah
and
then
I'll
hammer
a
couple
more
thoughts
into
this
experimental
feature
criteria.
Other
use
case
for
experimental
is
when,
like
there's
bits
and
pieces
of
the
feature
as
a
whole
available,
but
not
in
any
way
where
it's
like
user
friendly.
Yet
right
and
that's
why
registry
fell
very
quickly
into
experimental
is
because
we
wanted
to
provide
different
functionality
right
and
then
put
that
functionality
in
different
places,
and
we
weren't
able
to
do
it
all
in
one
release.
Right
that'd
be
another
criteria.
D
B
B
This
will
kind
of
be
a
page
that
lives
together
with,
I
guess,
either
the
pac
repo
community
etc,
where
you
can
have
that
that
you
can
have
like
a
discussion
board
and
people
can
post
questions
and
get
answers,
etc.
I
guess
it's
supposed
to
be
a
bit
less
a
bit
less
friction
than
forcing
people
to
join
slacks.
They
don't
always
love
joining
another
slack
group
if
they
just
want
to
answer
to
one
question,
so
I
just
saw
this
option
today.
B
A
Yeah,
I
think
that
was
overall
the
the
only
concern
that
I
could
remember.
I
know
that
there
was
a
thought
that
potentially
that
could
be
a
way
to
discuss
rfcs
and
there
was
a
project.
I
don't
remember
exactly
what
project
was
trying
to
use
discussions
for
rfcs
and
it
just
didn't,
like
the
experience.
Wasn't
all
too.
D
A
C
C
C
C
A
C
A
So
yeah
I
I
it
might
be
worth
reaching
out
because
I
do
feel
like
we
said
we
were
going
to
try
it
in
the
community
repo.
But
I
guess
maybe
it
just
dropped
off
and
nobody
actually
set
it
up,
but
again,
I'm
still
cautious
as
to
like
what
does
this
even
mean
right,
like
forums
are,
are
great,
but
I
don't
know
exactly
how
they
tie
into
this
ecosystem.
B
The
community-
I
I
don't
know
if
I
would
see
the
value
in
so
much
because
that
then
I
guess
like
that,
would
be
more
general
discussions
on
the
cloud
native,
build
packs
project
which
I
don't
think
would
get
like
people
once
people
are
having
those
discussion.
Often
they'd
want
to
be
much
more
kind
of
integrated
with
our
normal
channel,
which
is
slack
versus
like
if
it's
on
pack,
then
it
would
more
be
like
an
faq
like
hey
I'm
trying
to
use
this.
B
A
Yeah,
I
think
the
way
that
we
saw
this
was
it's
really
hard
for
a
user
to
know
what
repo
they
should
be.
Having
discussions
in
right
like-
and
you
see
this
in
in
slack
too
right-
it's
like.
Oh,
they
asked
this
question
in
the
platform
channel
right,
but
it
was
actually
like
a
lifecycle,
implementation
question
right
and
so
it
seems
like
we
don't
expect
them
and
I
think
it'd
be
like
poor
for
us
to
expect
them
to
know
exactly
where
to
place
all
their
their
questions
and
stuff.
A
I
think
the
idea
is
like
you
have
one
bucket
right
like
one
place
where
you
could
ask
any
question
you
want,
and
then
everybody
that
you
know
is
a
maintainer
or
or
a
heavy
contributor
could
go
in
there
and
answer
those
sort
of
questions,
and
then
it
doesn't
really
matter
right.
You
don't
like.
I
think
you
don't
want
to
associate
it
with
a
particular
repo
unless
you're
you're
talking
about
a
very
different.