►
From YouTube: Implementation Sync: 2021-06-24
Description
Meeting notes: https://bit.ly/38pal2Z
A
I
actually
like
it,
I
I
I
don't
mind
it.
I
guess
we
could
do
status
updates.
I
could
go
really
quick.
I've
been
working
on
a
github
action
to
let
us
cut
a
release
candidate.
A
There
was
an
earlier
pr
that
was
merged.
This
is
just
kind
of
adding
a
little
bit
of
change
and
functionality.
To
that.
So
take
a
look.
I
want
to
publicize
the
fact
that
we're
planning
to
ship
a
release
candidate
for
the
next
release
on
the
mailing
list,
so
I
have
that
on
it
on
my
to-do's
and
other
than
that,
I
think
probably
we
will
have
a
discussion
around
this,
but
I
think
we're
going
to
be
shuffling
some
stuff
for
the
o-12
milestone.
C
Side,
I
can
go
it's
pretty
quick
update.
I
don't
think
I
really
have
done
anything
this
week
besides
review
some
pr's
kind
of
just
talk,
stack
packs
and
what
we're
going
to
do
there,
so
I
don't
really
have
anything
to
add
I'll,
be
on
vacation
for
a
long
weekend,
but
I'll
be
back
by
this
time.
Next
week,.
D
Well,
on
my
side
from
for
the
implementation
stuff,
I've
been
working
with
the
registry
validation
issue.
There
are
a
couple
of
pr
in
the
there
is
one
pr
in
the
msu
deal
that
natalie
took
a
look
on
it
and
I
did
some
fixes
it's
there
and
today
I
create
this
draft
pr
for
the
changes
in
the
life
cycle.
I'm
still
working
on
it,
but
yeah.
That's
that's
my
idea.
B
A
If
that
is
all
for
status
updates,
I
guess
we
can
move
on
to
release
planning.
I
can
share
my
screen
so
that
we
can
take
a
look
at
the
milestone.
I
think
this
sort
of
leads
into
what
I
mentioned
in
my
update
each
year.
A
Okay?
So
let's
take
a
look
at
the
milestone.
A
So,
as
I
mentioned,
there's
there's
a
fair
amount
of
uncertainty
around
stackpack.
If
you
haven't
seen
steven's
rfc
to
remove
the
stack
concept,
please
check
it
out.
There's
some
good
conversation
happening
there,
but
given
the
uncertainty
that
exists,
I
think
some
of
the
issues
that
we
have
in
our
milestone
don't
make
sense,
or
at
least
before
we
double
down
on
mixins.
A
Let's
make
sure
we're
you
know
if
we're
going
to
have
mix-ins,
and
I
think
that
they
are
these
two
providing
makes
it
the
analyzer
providing
mixed-in
information
to
the
detector
and
then
the
detector
actually
taking
that
information
to
validate.
If
mixins
are
satisfied.
A
This
I
mean
this
doesn't
require
stack
packs,
but
it's
just
like
for
adding
further
functionality
around
mixins
that
you
know
that
maybe
not
wouldn't
make
sense
if
we're
moving
away
from
them.
So
I
I
propose
taking
them
out
of
the
milestone
and
just
kind
of
waiting
to
see
what
happens
with
that
rfc
and
we
can,
you
know,
always
bring
them
back
to
a
future
milestone
if
that
makes
sense.
So
I'm
going
to
clear
the
can
I
do
that
I
just
clear
the
milestone
on
these
right.
A
Okay
and
then
there's
some
question
around
validating
the
stack
id
because
we
had
added
added
a
to
the
existing
schema
for
spectromel.
We
had
added
the
build
image
with
its
stack
id
and
mix-ins,
and
I
think
we
want
to
remove
that
schema
change.
A
A
If
you're
running
in
an
untrusted
builder
situation,
where
the
analyzer
is
actually
running
in
the
lifecycle
image,
they
won't
have
a
stack
id,
but
I
think
we
said:
if
present
we
could
validate
it
or
we
could
just
completely
revert
the
commit
that
the
merge
of
jesse's
pr
that
added
this
stuff,
I'm
not
sure
if
there's
thoughts,
one
way
or
the
other.
C
Yeah,
I
don't
have
strong
feelings
here
either
way
like,
I
think,
I'm
all
for
reducing
complexity.
Always
so,
if
we
don't
think
that
we
would
need
that
tom
will
change
in
the
eventual
future
of
whatever
stack
packs
becomes.
Then
I
think
I'm
okay,
like
yeah,
pulling.
A
A
C
Sure
yeah,
I
I
don't
have
any
if
there's
pieces
of
this
we
do
want,
then
I
can,
you
know
maybe
try
to
work
on
patching
those
back
in
when
I
get
back.
If
there's
pieces
of
it,
we
want
to
keep
or
you
know
like
I
said
I
can
kind
of
re.
Take
another
look
at
it
with
the
new.
C
A
Why
don't
we
revert
it
and
then
we
could
add
back
pieces
of
it
if
we
feel
that
that's
you
know
that
that
would
be
valuable
just
in
the
interest
of
like
essentially
being
able
to
ship
what
we
have
sounds
great.
A
So
I'm
going
to
leave
this
in
the
milestone.
Just
so
I
remember
to
go,
and
I
don't
know
it's
a
process
for
reverting.
A
We'll
give
that
a
shot,
I
think
so,
as
juan
mentioned
in
his
update.
This
issue
is
being
worked
on
actively
and
I
am
working
on
this
chore,
so
I
think
we're
we're
getting
close
to
being
able
to
ship
this
thing.
The
only
thing
I'll
add
is
that
actually
before
we
ship,
we
need
to
also
make
a
pr
to
the
spec
to
like
the
pieces
that
we're
taking
out
should
be
taken
out
of
the
spec
as
well.
I
don't
know
if
somebody
wants
to
own
that.
A
I
think
I
know
what
needs
to
be
done,
but
yeah,
if,
if
you
don't
get
to
it,.
C
D
A
I
guess
with
that
said.
You
know
just
on
the
release
we
already
touched
on
this,
but
I
want
to
ship
a
release
candidate.
A
B
Sorry
so
rc's
aren't
ships
they're
shipped
manually.
I
guess
not
not
like
I
don't
know
just
temporarily
on
some
ongoing
basis
every
week
or
something.
A
No,
so
we
we
talked
about
night
leads,
but
that
just
organizationally
kind
of
felt
like
a
bigger
headache
and
we
weren't
sure
of
the
value
given
that
we
aim
to
ship
a
complete
implementation
of
an
api,
but
the
rsc.
The
process
for
cutting
in
rc
is
very
similar
to
the
process
for
cutting
a
release.
It's
just
I
I.
This
is
documented
in
the
markdown
file
that
we
have,
but
it's
essentially
it's
the
same
process.
You
just
make
a
release
branch
that
includes
an
rc
designation.
D
A
D
Of
life
cycle
yeah
before
we
ship
a
release,
candidate
lifecycle-
I
don't
know
if
there
are
any
rules
about
released
candidates
right,
it's
not
really
a
it's,
not
a
release.
It's
just
a
thing
that
we're
putting
out
there
for
people
to
evaluate
so
yeah.
You
know
if
the
spec,
I
think
in
an
ideal
world
that
the
spec
would
go
first
before
we
make
any
functionality
available
through
the
channel
of
things
that
we
imagine
become
life
cycle
releases,
but
I
would
not
think
it's
a
hard
rule
for
rc's.
D
I
would
just
note
that
this
is
a
release
candidate
and
it
contains
functionality
that
hasn't
landed
in
this
back.
Yet
the
word
release
candidate
versus
like
beta,
is
also
for
like
a
beta
release.
I
think
it
would
be
especially
okay,
but
it
released
candidate
implies
that
you
know
this
thing
is
about
to
go
out.
This
thing
literally
could
become
a
release,
so
maybe
there's
a
little
bit
of
a
stronger
thing
there,
but
no
hard
guidance,
that's
just
my
it
might
take.
I
think
it's
fine
to
do
without
it.
A
A
I
think
we
just
we
covered
this
in
the
notes.
I
don't
think
we
have
any
new
ones
in
the
needs
discussion
we
covered
this
one
last
week,
there's
been
some
movement
on
that
one,
the
keychain
question
and
the
others
really
to
stack
packs,
so
we
should
pause
them
until
the
other
discussion
has
happened.
A
Rfcs.
This
is
just
to
advertise.
What
rfcs
are
pertaining
to
our
team?
I
think
the
ones
that
are
new
and
and
very
interesting
are
these
three
that
were
mentioned
in
the
working
group
that
we
just
had,
but
just
everyone
I
don't
know.
If
there's
anything,
we
want
to
say
here.
C
I
don't
think
so
I
mean
other
than
the
one.
That's
on
the
agenda
review
stats.
A
Okay
and
we
don't
have
any
other
items
on
the
agenda-
I
had.
A
I
didn't
add
this
here,
but
I
I
know,
there's
been
various
slack
conversations
about
how
we
might
improve
the
organization
of
our
code
to
make
it
easier
to
manage
multiple
platform
and
build
pack
apis,
and
I
think
at
one
point
we
had
suggested
doing
sort
of
a
deep
dive.
A
I
personally
don't
feel
totally
prepared.
I
do
have
this
pr,
I
guess
maybe
this
is
just
an
advertisement
for
the
the
pr
that
I
open,
which
is
in
draft.
Maybe
I
should
undraft
it,
although
it's
not
complete
to-
and
this
is
on
a
again
an
issue
that
we've
we've
punted
for
now
right
the
mix
and
validation.
But
this
is
like
a
proposal
for
how
we
might
deal
with
some
of
the
complexity
by
having
a
fronting
interface.
A
So
I
don't
know
it's
not
very
satisfying
to
go
through
a
review
of
pr
that
we
have
no
intention
of
merging.
But
I
don't
know
this
is
my
one
contribution
to
that
ongoing
conversation.
So.
C
Yeah,
I
think
I
think
I
took
a
look
at
it.
It
looked
pretty
good,
like
I
think
you
know
any
any
steps
towards
you
know
pushing
stuff
away
from
commands,
and
you
know
into
the
into
the
business
logic
area
that
we
that
we
like
is
it's
gonna.
C
Gonna
be
good
for
okay,
not
kpac.
What's
the
other
one
build
kit,
yeah
build
kit
as
well,
like,
I
think
I
like
seeing
all
this
stuff.
A
A
C
D
B
No
I'm
with
you
that
you
know
it's
hard
to
have
the
conversation
asynchronously
right,
but
maybe
having
a
meeting
where
we're
sort
of
discussing
this
for
the
first
time
right
like
for
brainstorming,
it
might
not
be
too
effective.
Maybe
we,
you
know
if
people
have
strong
opinions
you
can
make.
B
I
don't
know.
Personal
pr's
like
natalie
did
not
intending
to
merge
it,
but
you
know
just
at
least
having
a
proof
of
concept
for
the
architecture
that
you
have
in
mind,
and
then
you
know
at
least
that
can
be
reviewed
before
the
meeting
right.
I
want
to
make
the
time
that
we
are
using
right
like
when
we
do
have
to
meet
up
valuable
right.
C
Yeah,
that's
a
good
point
yeah.
I
wonder
if
we
could
do
like
a
you
know,
pic
pick
one
of
the
phases
to
kind
of
like
push
code
away
from
the
areas
that
are,
you
know
just
like
push
a
little
code
around
and
detect
her
or
something
like
that
right
and
then
like,
and
I
could
take
a
stab
at
doing
it
maybe
and
then
like.
If
natalie
has
opinions,
she
can
do
what
she
did
here
for
detector,
maybe
maybe
not
do
them
all.
A
I
just
add
that
at
least
to
me
I
it
seems
like
we
might
have
a
little
bit
of
kind
of
breathing
room.
You
know
once
we
should
like
kind
of
get
what
we've
done
sort
of
out
there.
A
While
the
dust
settles
around
stack
packs,
you
know
that
that
might
be
like
perfect
opportunity
for
us
to
kind
of
jump
on
this.
While
we
don't
have
you
know,
feed
features
that
are
urgently
needing
to
be
worked
on,
so
maybe
we
can
make
that,
like.
I
don't
know
if
we
as
we
plan
the
next
milestone.
Maybe
that
could
be
where
we
pull
in.
You
know
jesse
some
of
the
issues
that
you
opened
general
code
refactoring
and
that
kind
of
stuff.
C
C
A
We've
covered
everything
I
had
one
more.
I
just
remembered
a
meta
item
that
I
added
last
week
and
you
know
we-
we
had
different
participants
in
that
conversation,
so
this
is
maybe
a
good
time
to
just
ask.
How
do
people
feel
about
the
cadence
of
this
meeting?
A
I
personally
feel
that
going
through
the
milestone-
and
you
know
like
that
kind
of
stuff-
every
single
week
is
maybe
not
as
valuable
because
things
don't
change
that
often
and
we're
in
a
spirit
right
now
of
cancelling
as
many
meetings
as
we
don't
find
totally
valuable.
B
Again,
I
hope
I'm
not
a
major
party
here,
but
I
would
love
you
know
a
longer
cadence
between
meetings.
All
of
these
things
being
able
to
especially
being
able
to
forcing
people
to
talk
about
these
things,
asynchronously
would
help
my
life
a
little
bit
easier.
D
Yeah,
I
think
I
agree
and
also
with
what
you
just
said
that
maybe
at
some
point
after
delivering
these
milestones
and
stuff-
and
maybe
we
will
be
thinking
on
what
we
are
going
to
be
working
next,
maybe
at
that
time
we
can
reevaluate
if
we
need
to
do
the
meeting
weekly
again,
because
we
have
more
things
to
do
more
things
that
maybe
change
in
a
week,
but
right
now
in
the
state
we
are,
I
believe,
it's
more
helpful
to
you
know
maybe
buy
weekly
having
them
in
this
meeting.
I
agree
with.
D
A
A
B
D
C
A
I
I
think
the
only
thing
I
was
going
to
add
is
that
emily
has
mentioned
that
this
time
this
particular
time
is
bad
for
her,
I'm
wondering
if
we
can
maybe
put
out
a
doodle
for
people
to
sort
of
indicate
what
times
really
are
optimal,
and
you
know
with
the
knowledge
that
it
would
be
on
a
bi-weekly
cadence
that
might
help
us
land
on
a
you
know
better
slot
for
everyone.
D
A
So
see
everyone
in
two
weeks
then.