►
From YouTube: Implementations Sync: 2021-03-25
Description
Meeting notes: https://bit.ly/38pal2Z
A
You,
I
think,
that's
you,
okay,
I
don't
I
don't
mind.
I
just
you
know
want
to
give
others
the
opportunity,
so
we
recorded
the
meeting
status
updates.
A
I
could
start
I
think
this
morning
I
merged
the
last
or
one
of
the
last
pr's
that
that
would
go
into
the
release.
I
think,
what's
still
outstanding
is
cutting
a
release
branch.
We
need
to
update
the
readme
with
the
supported
apis
and
creates
release,
notes,
there's
also
the
step
of
manual
validation
that
we
usually
do
with
pac,
which
is
the
kind
of
the
looming
storm
cloud
of
will.
We
have
a
windows
environment
that
we
can
use
to
do
the
validation
on
windows,
but
hopefully
that'll
be.
A
That
will
be
fine.
The
only
other
thing
is,
I
noticed
mike
had
just
undrafted
his
pr
to
fix
or
to
enable
acceptance
tests
on
windows
for
the
analyzer,
which
I
don't
know.
You
know
it's
kind
of
low
risk
either
way
I
don't
know
if
we
want
to
pull
it
in
for
the
release,
but
you
know
if
it
doesn't
make
the
release,
it
doesn't
have
too
much
impact.
So
I
think
maybe
we
can
just
proceed.
B
I
don't
have
anything
this
week,
I'm
gonna
try
to
help
with
the
release
and
acceptance
testing.
I
guess
so.
We
can
kind
of
release
this
and
then
I've
got
some
work
on
some
rfcs
respect,
respect
vrs
that
I
need
to
accomplish
hopefully
by
next
week,
so
we
can
get
the
invokes
in
for
the
next
0.70
for
spec
pr.
A
C
A
A
But
I
guess
that
I
am
reminded
everyone
on
this
call
is
aware,
but
for
anyone
who
might
watch
the
recording
later,
we
need
to
merge
or
we
need
to
release
the
spec
before
we
can
shift
the
life
cycle.
So
that's
why
we're
kind
of
you
know
just
in
that
game
of
completing
tasks
in
a
certain
order,
but
all
is
moving.
So
I
guess
we
can
go
on
to
release
planning,
although
we
kind
of
I
mean
did
that
with
our
status
update.
A
A
Currently,
the
milestone
includes
support,
stack
packs,
but
I
wonder
you
know,
given
that
I
guess
in
the
draft
pr
that
that
jesse
opened
you
know
a
while
back.
We
have
seen
that
it's
possible
to
break
that
up
into
smaller
units
of
work,
so
maybe
it
makes
sense
to
create
multiple
life
cycle
issues
that
could
be
tackled
independently.
B
Yeah,
I
think
so
too.
I
don't
know
if
it
makes
sense
to
create
like
a
feature
branch
for
stack
packs
and
then
like
merge
into
that
branch,
so
that
the
concurrent
streams
don't
have
to
like.
I
hate
the
light.
If
we
don't
make
012
for
some
reason
have
to
revert
out
like
individual
commits
that
are
like
that.
C
B
Sort
of
finish
the
feature
as
far
as
o12
is
concerned,
but
but
I
don't
know,
I
don't
have
a
strong
opinion
there
either.
A
C
A
A
A
A
I
just
have
a
comment,
or
maybe
a
confession,
like
I
know
a
few
times
when
these
like
questions
of
where
should
we
put
this
file
have
come
up.
A
Personally,
I
find
it
very
hard
to
keep
in
my
head
an
inventory
of
what
all
files
exist
and
where,
in
the
build
container
as
well
as
you
know,
there's
some
expectation
that,
like
oh
well,
the
platform
is
going
to
be
read
only
or
you
know
like
just
things
that,
because
it's
hard
to
keep
in
my
head,
it's
hard
for
me
to
have
an
opinion
about
where
things
should
go.
C
A
All
right,
I
guess
we
could
move
on
a
couple.
We
had
one
more
standing
on.
Oh
so
we
talked
about
release
planning,
but
notably
we
didn't
make
any
mention
of
docs,
which
I
think
is.
A
You
know
an
ongoing
struggle
right
to
keep
the
docs
updated
with
our
latest
functionality.
D
Sorry,
I'm
muted,
there
you
go.
Did
you
all
see
the?
I
guess
the
guidance
recommendation
for
coordinating
releases
for
the
docs
repo,
I'm
hoping
that
will
you
know
help
in
this
in
this
case,
and
so
I'm
not
sure
exactly
what
the
question
is
like
who's
gonna
do
the
docs
right,
but
but
as
far
as
some
sort
of
guidance
of
structure
and
how
it
can
be
done.
D
I
I
wonder
if
that'll
give
you
something
to
work
with,
but
I've
heard
in
the
past
that
we've
want
to
get
a
little
bit
better
about
that.
So
I
would
some
people
have
said,
although
I
I
wouldn't
put
any
you
know
any
force
behind
it
is
that
it
should
be
like
a
forcing
function
right
like
the
release,
should
not
go
out.
Unless
there
are
stocks
completed
to
go
along
with
it
again,
I'm
not
here
to
police
that,
but
it
sounds.
A
I
actually
just
remember
that
I
had
it
to
do
to
reach
out
to
the
paquetto
folks,
so
I
did
that
one
minute
before
this
meeting
started
to
see
if
they
could,
you
know,
had
any
interest
in
consuming
that
artifact.
A
A
D
I
guess
are
we
concerned
that,
even
if
an
art
yeah,
an
rc
release
candidate
is
produced
and
nobody
uses
it,
whether
it's
providing
any
value
like
because
I
feel-
and
I
hear
that
it's
kind
of
already
going
to
produce
some
value
by
letting
you
have
at
least
a
time
window
in
which
the
focus
could
be
primarily
dogs
right,
whether
the
potato
team
chooses
to
to
test
it.
D
I
guess
seems
somewhat
separate
to
the
conversation,
because
again,
we
could
also
find
additional
individuals
to
test
it,
especially
those
that
are
looking
for
very
specific
features
in
that
life
cycle.
The
other
benefit,
too,
is
from
a
platform's
perspective.
D
Pack
could,
during
that
time
frame,
be
the
one
that
starts
consuming
it
and
testing
it
at
that
point
in
time
as
they
try
to
bump
up
to
the
next
platform.
Api
version.
D
A
A
I
remember
when
pac
implemented
a
more
formalized
release
process.
You
know
calendar
and
procedures.
There
was
an
rfc
that
detailed
that
I
think,
maybe
a
you
know,
an
implementation,
scoped
rfc
detailing
some
of
these
procedural
formalizations
might
be
helpful.
So
I'm
happy
to
write
one
if
we
think
that's
a
good
idea.
D
My
only
input
to
this
conversation
would
be
that
if
it
does
come
through
that
the
outcome
be
that
there's
like
a
release
and
the
if
there
isn't
already
one
for
the
life
cycle
that
details
this
right
this
process,
because
people
should
not
have
to
go,
look
up
an
rxc
to
figure
out
exactly
how
a
release
process
works
for
a
repo
or
component.
D
A
Part
of
my
like
thinking
here
is
that
this
is
a
little.
This
feels
like
a
little
bit
of
like
growing
the
scope
of
the
rfc
beyond
you
know,
having
a
release
candidate
binary,
but
actually
also
putting
in
there
that
there's
a
certain
threshold
of
documentation
that
we
expect
before
releasing
so
like,
maybe
at
a
minimum.
A
migration
guide
from
to
the
latest
supported
platform
api
build
pack
api.
What
have
you?
A
Because
I
do
think
that
we
need
a
forcing
function
around
docs
and
I
think,
having
like
the
more
eyes
on
it
and
more
people
saying
yeah.
We.
A
A
A
A
All
right,
if
we
want
to
move
on,
we
have
one
more
item
on
the
agenda,
which
is
to
review
the
roadmap.
I
don't
know
you
know,
maybe
it
makes
sense
to
sort
of
introduce
this
as
a
thing
that
we
will
do
and
then
kind
of
do
it
like
more
deeply
in
our
next
meeting.
If
we
come
in
with
that
expectation,
this
is
just
something
that
came
up.
A
D
D
You
know
north
star
of
the
road
map,
but
also,
if
there's
some
sort
of,
because
my
understanding
is
that
the
core
team
will
review
the
roadmap
quarterly
now
right,
so
there
might
be
some
adjustments
every
quarter
and
so
keeping
an
eye
on
it
and
making
sure
that
we're
all
kind
of
all
sub
teams
are
aligned
on
that
same
roadmap.
I
think,
makes
a
lot
of
sense.
B
Yeah
I'll
be
curious
to
see
how
this
works
out
like
the
roadmap.
I
know
it's
sort
of
the
north
star
but
like
what's
going
to
kick
off
these
meetings
so
that
we
actually
create
like
spec,
prs
or
rfcs
or
whatever
needs
to
happen
like
I
don't
know
how
that's
going
to
be
driven.
This
is
the
first
time
I've
sort
of
been
around
for
the
roadmap
part
of
this
but
yeah.
I
assume
this
team
will
be
at
least
partly
responsible
for
writing
the
spec
pr's.
B
A
Heading
now
like
each
one
of
these
things,
I'm
just
looking
at
I
I'm
just
looking
at
the
document
right
now.
I
you
know
documentation.
Rework
like
we
touched
on
that
kind
of
naturally
right,
but
maybe
there's
more
like
targeted,
focused
activity
that
we
could
be
doing
specifically
on
making
the
docs
better.
You
know
it
isn't
kind
of
a.
C
D
So
first
I
want
to
say
you
know
that
image
that
says
like
that
goes
like
this
and
does
like
all
the
things
right
like
that's
how
I
envision
the
docs
right
like
we
just
want
to
document
all
the
things,
but
I
think
more
generally,
there
was
a
discussion
about
this
yesterday
in
the
working
group.
I
don't
know
if
you
were
present
for
that
conversation,
but
I
think
there's
different
levels
of
documentation
right
that
we
want
to
provide
that.
I
think
we've
we've
done.
D
Okay
at
the
tutorial,
the
guides
right,
like
the
things
that
walk
people
through
doing
certain
operations
and
things
like
that.
But
even
those
are
very
you
know
like
we
don't
have
all
of
them
quite
there.
Yet
right
like
we,
don't
have
all
the
use
cases
there
and
they're
very
specific
to
pack
right
because
that's
the
tool
that
we
maintain
and
stuff,
but
then
there's
the
reference
documentation,
which
is
something
that
I
think
like
very
imp.
D
There
was
a
huge
kind
of
like
push
for
this,
especially
on
the
life
cycle
side
of
things
and
on
pack.
We
already
have
like
the
pack
reference
stock
right,
which
is
like
the
auto
generated
ghost
stuff.
That
tells
you
all
the
options
and
stuff
like
that.
But
we
don't
have
anything
like
that
for
the
life
cycle
right
so
like
the
life
cycle,
having
something
like
that
where
it
tells
you
like
hey
when
you
call
this
face
or
this
binary.
D
These
are
the
operations
and
stuff
like
that,
like
that's
in
the
spec
right
now,
but
it's
not
on
our
docs
right
so
again,
we're
kind
of
trying
to
move
things
where
there's
three
tiers
right.
There's
the
tutorials
there's
the
reference,
which
is
like
inputs,
outputs
type
of
thing
mechanical
and
then
there's
a
spec
that
talks
more
of
like
this,
like
almost
like
a
high
level,
but
very
contractual
interface,
saying
like
when
you
know
when
this
is
present,
these
other
things
have
to
occur
right.
It
talks
about
the
operational
side
of
things.
D
So
again,
all
the
things
right.
Yes
for
for
pack
as
a
library
right
for
the
pack
commands,
we
already
have
that
for
pack
as
a
library,
we
we
were
okay
with
that,
but
we
could
improve
the
pack.
Refactor
is
going
to
improve
that
again,
like
I
don't
want
to
take
up
too
much
time
talking
about
packs
specifically,
but
you
know
on
the
life
cycle.
A
I
I
just
want
to
say
dan,
you
shared
an
article
earlier
about
like
doc's
organization,
which
I
just
read,
and
I
actually
think
that
that's
spot
on
sort
of
like
you
know,
tree
organization
versus
graph.
For
me,
sometimes
it's
like
report
tamil
is
the
perfect
is
an
example
right
report
tamil.
Where
does
that
go
like?
Who
cares
about
that?
Does
it
go
in
the
platform
operators?
You
know
or
the
app
developers
guide,
or
does
it
go
in
the
exporter
guide,
because
you
know
it's
an
output
of
the
exporter
like
where
does
it
land?
A
B
B
B
It's
okay,
that
it's
known
that,
like
maybe
people,
make
mistakes
as
they
write
the
documentation
for
like
how
to
use
analyzer
and
all
of
it's,
like
you
know,
human
described
arguments
in
this
collection
to
produce
this
result,
and
maybe
it
gets
out
of
date
slightly
more
often
than
the
spec
does
right,
but
I
think
that's:
okay,
like
I
think,
having
a
collection
documentation.
That's
like
a
slightly
you
know,
less
less.
C
A
A
C
Yeah,
I
guess
okay,
oh
one
follow-up
thing
is,
I
think
that,
like
javier,
the
I
vision
you
describe
is
like,
like
sounds
amazing,
but
it
does
seem
like
that
is
like
a
little
ways
like
that's
the
end
right
like
the
pot
of
gold
at
the
end
of
the
rainbow,
where,
like
once,
we
get
here,
we'll
be
we'll
be
happy,
but
like
the
in
the
immediate
like
we
have,
we
are
trying
to
get
there.
How
do
we
take
our
first
couple?
C
D
That
doesn't
sound
too.
I
totally
agree
with
you,
and
I
was
I
had
it
in
the
back
of
my
mind.
Right
like
I
was
like
whoa,
you
know:
what's
the
next
step
right,
I
think
that
definitely
makes
sense.
It
ultimately
depends
on
exactly
again.
We
have
those
different
levels
right,
and
so
what
we
could
do
is
like
break
it
down
like
okay.
What
level
do
we
want
to
focus
on
next
right?
I
think
we've
talked
about
the
spec,
it's
pretty
good
as
far
as
providing
inputs
and
outputs
for
the
life
cycle.
D
So
now
you
know
we
have
no
idea
of
this,
like
reference
documentation,
documentation
for
the
life
cycle
right
like
maybe
that
is
the
next
thing
that
we
should
focus
on.
So
the
the
questions
then
come
up
where,
like
okay,
where
do
we
put
it
and
you
know,
is
there
one
issue
for
the
entire
thing,
or
should
we
just
like
break
it
up
into
smaller
pieces?
D
Like
this
is
the
documentation
we
have
for
the
life
cycle
right
now,
let
me
share
it
with
everybody
or
actually
I'll,
just
share
my
screen
for
the
recording
so
like
this.
Is
it
right
like
this?
Is
the
reference
documentation
for
the
life
cycle
right
and,
and
obviously
there's
some
things
missing
here
right.
D
So,
okay,
so
this
is
the
life
cycle.
We
could
add
it
on
here.
I'm
not
entirely
sure
that
would
be
the
best.
We
could
add
it
under
tools
right,
which
I
kind
of
feel
weird
about,
but
that's
I'm
going
to
show
again
what
pac
does
right
so
pac
has
these
cli
docs
right?
Where
then
you
could
again,
it
could
be
improved,
but
you
have
this
like
reference
of
inputs
and
outputs
of
all
the
commands
right,
then
we
also
have
a
link
to
the
go
as
a
library
right.
D
I
think
something
like
that
makes
sense
whether
we
want
to
consider
a
life
cycle,
a
tool.
I
think
that's
where
my
opinions,
maybe
start
grinding
or
or
I
have
like
some
internal
conflicts
because,
like
a
the
build
packs
life
cycle,
implementation
of
the
life
cycle
is
just
that
it's
in
the
implementation
of
the
life
cycle
and
so
like
this
top
level
life
cycle
here
this
seems
like
that
general.
D
You
know
again
that
very
general
spect
version
of
the
implementation
right
or
sorry
yeah,
the
spec
api
or
whatever
you
want
to
call
it
of
this
thing,
called
the
lab
cycle.
I
know
that
there's
some
opinions
right.
I
discussed
them
recently
in
the
chat
that
there's
some
opinions
that
the
current
implementation
of
the
life
cycle,
the
one
that
we
maintain,
has
that
aren't
part
of
the
spec
right.
D
So
I
feel
like
there's
a
slight
deviation
in
the
implementation
and
what
the
spec
says
right
and
for
because
of
the
deviation
and
the
opinions
that
are
put
into
it
to
me.
It
sounds
like
it
should
be
here,
but
I
hate
again
the
fact
that
we
called
the
life
cycle.
The
life
cycle,
which
is
the
life
cycle
component
of
the
cloud
native,
build
packs.
C
Discuss
I
mean
yeah,
I
have
no
opinions
about
where
this
stuff
lands.
I
I
think
it's
whatever
you
think
is
right.
I
will
go
along
with,
but
it
is
a
little
longer
yeah.
C
B
C
C
Yeah
I
mean,
I
guess
the
one
thing
I'm
just
I
feel
like
we.
Maybe
this
is
incorrect,
but
my
idea,
my
vision
would
be
like
we
do
one
thing
we
do
it
well
and
then
we
figure
out
how
to
do
two
things
and
do
it
well
and
then
figure
out
how
to
do
three
things.
Maybe
that's
unreasonable
because
this
sort
of
thing
is
immediately
useful
and
like.
D
So
sorry.
A
Go
ahead,
I
was
just
gonna.
Add
that
for
me.
A
I've
been
I've.
I
have
a
dr
I've,
been
writing
the
migration
guys
yeah
yeah
as
well,
right
and
the
for
me
that
that
seems
to
be
like
the
information
that
is
currently
the
most
relevant
right,
because
it's
the
stuff
that
we're
releasing
and
when
I'm
writing
these
guides,
I'm
like
can
I
link
to
anything
in
the
in
the
docs
so
that
someone
can
get
more
information
about
this
right.
Or
is
this
literally
like
the
paragraph
that
I'm
writing
right
now,
the
only
mention
of
x,
you
know
like
profile
scripts.
A
Well,
okay,
for
more
information,
see
the
spec
really
you
know
so
that,
because
at
the
end
of
the
day
you
know
we
all
have
limited
time.
We
need
to
actually
like
choose
to
work
on
this
and
we
also
need
to
kind
of
know.
What's
the
most
important
thing
to
work
on,
you
know
to
your
point
right,
so
I
sort
of
feel
like
using
the
the
release
notes
or
the
migration
guides
as
like
a
place
to
to
start
feels
pretty
good.
D
I
want
to
go
back
to
answering
the
where
to
put
stuff
just
so
that
we
remove
that
blocker
right,
I
think
with
jesse's.
You
know,
statement
of
like
it
doesn't
matter
as
long
as
it's
somewhere.
I
I
totally
agree
with
that
right
and
I
don't
want
anybody
to
get
blocked
by
the
question
of
like
hey.
Where
do
I
put
it?
D
I
literally
say
like
put
it
on
this
page
right
like
just
start
shoving
information
into
this
page
right
here
and
then
once
it
grows
to
a
certain
amount,
we're
like
we
feel
like
we
need
to
separate
it.
Then
we
could
discuss
of
how
to
break
it
down
or
move
it
or
whatever
right.
But
I
think
the
first
step
is
like
just
jotting
it
down.