►
From YouTube: Implementations Sync: 2021-03-18
Description
Meeting notes: https://bit.ly/38pal2Z
B
B
B
So
I
think
we're
all
maybe
discussed
this
previously,
but
jesse
and
I
met
earlier
to
kind
of
think
over
and
decide
to
push
the
swapping
of
analyze
and
detect
to
the
next
release.
C
Ahead:
okay,
I
guess
I'm
still
unmuted.
Let's
see,
I
think,
yeah
working
working
on
getting
been
doing
much
life
cycle
this
week.
I've
been
off
most
of
the
week,
but
I'm
going
to
try
to
get
the
spec
prs
updated
so
that
I
can
kind
of
re-target
the
move
moving
in
the
phases
to
07
other
than
that.
I
think
I've
got
everything
else
off
my
plate
for
o6
other
than
just
reviewing
what
comes
through
between
now
and
then
so.
That's
it
for.
A
Me
after
a
very
like
weird
week
where
we
found
some
bags,
where
I
try
to
do
things
that
are
not
possible
and
go.
But
finally,
I
think
my
pr
is
ready
for
review
nali
and
I
just
finished
testing
all
the
scenarios
and
everything
is
working
as
we're
expected.
A
So
I
I'm
going
to
write
the
scenario
that
we
tested
in
the
pr
and
then
go
back
to
work
on
my
on
the
stack
issue
that
relates
to
the
same
thing:
yeah,
that's
funny,
and
if
I'll
have
time
before
the
release,
I
really
want
to
review
some
of
the
pr's
that
are
still
open
and
I
just
didn't
have
enough
time
to
preview
them.
D
No,
no
big,
no
big
deals
from
me.
I
did
briefly
try
to
look
at
and
test
the
image
util
one
that's
sort
of
already
linked
in
the
agenda.
B
B
There
are
no
other
updates.
We
can
move
on
to
release
planning
which
you
already
kind
of
touched
on,
but
I
can
share
my
screen
just
to
just
to.
B
Are
the
pr
that
yell
has
been
updating
and
is
probably
ready
to
merge
and
this
one's
on
the
agenda?
B
This
one
is
like
pending
spec
finalization,
but
it's
been
approved.
I
think
it
just
needs
to
be,
like
literally
someone
needs
to
click
the
button
in
the
spec
repo
to
merge
this.
So
it's
ready
for
review.
If
anyone
wants
to
take
a
look,
it's
very
small
change
and
this
one
we're
kicking
out
to
next
release
and
this
one
I
think
we
already
merged
that
tr
yeah.
B
I
have
to
find
it.
I
swear
we
merged
this
pr,
but
anyway
in
progress
likely
to
be
to
be
in
the
next
release.
The
only
thing
that's
actually
like
up
in
the
air
at
the
moment
is
there
was
a
stephen,
had
some
feedback
on
the
spec
pr
for
the
default
process,
change
which.
B
B
Awesome
and
maybe
it
starts
making
sense
to
also
look
a
little
bit
further
ahead
at
12.
B
B
B
B
Work
right
any
anything
else
we
should
say
about
at
least,
if
not
we
can
move
on
to
to
needs
discussion,
which
I
don't
think
we
had
anything
last
time
and
there's
still
nothing.
So
that's
fine
and
then
there's.
B
Rfcs
did
we
talk
about
both
of
these
last
time
they
were
discussed
in
the
working
group
yesterday
I
don't
know
if
there's
anything
more
to
add
in
this
forum.
B
Okay,
so
I
guess
moving
on
to
next
on
the
agenda
I
put
this
here.
What
do
we
think
about
this?
Pr
really.
Credit
goes
to
dan
for
figuring
out
what
was
going
on
to
cause
those
errors
that
were
that
were
reported.
I
guess
this
happens
when
you're
doing
like
many
build
pack
builds
in
parallel.
I
think
back
to
the
issue
is
like
20
builds
at
a
time
the
original
issue
trying
to
create
20
potato
images.
At
the
same
time,.
C
Lot
of
the
expectations
around
this
are
related
to
just
how
docker
itself
is
fairly
reliable,
with
504s
and
stuff
like
that,
like
I
think
it
just
sort
of
you
know
if
you've
ever
pushed
anything
to
a
flaky
registry,
you
get
a
lot
of
retrying
automatically
built
in
from
the
docker
client,
and
so
I
think
some
of
that
is
just
that.
You
know
maybe
registries
aren't
as
stable
as
we
expected
them
and
so
using
gtcr.
D
Yeah,
just
on
the
pr
itself,
I
I
don't
have
any
issue
with
it.
I
just
wanted
to
know
that
it
actually
works
right
before
we
do
anything.
B
D
D
Right
I
was,
I
was
getting
some
trust
or
build
errors
or
something
I
guess,
the
builder
you
build
that
uses
that
it
becomes
untrusted
anyway,
I
was
just
hoping,
maybe
like
someone
had
ran
into
that
already
and
sort
of
had
steps
on
how
to
go
about
building
an
ad
hoc
life
cycle
and
testing
with
it.
C
Way
I
currently
do
it
is
I
mount
the
I
mount
the
life
cycle
in
an
existing
builder
and
and
then.
D
B
C
A
volume
mount
or
something
and
then
like
copy
it
in
and
save
to
kind
of
overwrite,
a
builder
with
a
particular
like
local
copy
of
the
built
life
cycle,
or
you
can
build
the
builder
locally
if
it
builds
and
then
sometimes
I'll
docker
run
and
mount
a
workspace
into
that
and
then
throw
that
container
away.
So
I
I
normally
don't
use
pack,
it's
kind
of
the
the
cavity
out.
B
B
Is
one
of
the
biggest
scratches
that
I've
encountered
in
trying
to
modify
the
life
cycle
and
test
it
out
with
pac?
D
B
B
B
D
Honestly,
I
have
no
strong
feelings.
I
just
the
only
thing
I
I
want
to
know
is
that
it
works.
It
actually
fixes
something
before
it
gets
worse.
That's
that's
what
I'm
thinking
on
that
front.
I
I've
had
a
I've,
maybe
looked
to
a
life
cycle
maintainer
to
to.
Let
me
know.
B
D
All
right
not
to
get
too
in
the
weeds
here,
but
I
think
javier
had
a
good
point
right
in
this
case.
I
don't,
I
don't
think,
there's
a
status
code
being
returned
right.
If
it
was,
it
would
have
been
retried
normally
right.
This
is
just
some
eof
thing
yeah
and
then
he's
saying
it's
up
to
us
to
handle
that
right
like,
and
I
think
I
think
that
holds
weight
right.
Maybe
ggcr
shouldn't
be
handling
it.
Maybe
they've
decided
not
to
handle.
B
C
B
C
It
works
but
yeah
I
other
than
that.
I
don't
really
have
much
to
say
on
it
like
if
it
retries
and
it
succeeds,
that's
going
to
be
great
but
kind
of
like
you
said.
If,
if
this
eof
is
because
of
a
failure,
then
you
know
that
isn't
recoverable.
Then
we
may
just
be
hammering
the
registry
in
question,
but
it's
only
retrying
a
few
times.
If
I
recall
right
three
times
or
something
like.
D
C
B
Wanted
all
right,
there's
nothing
more
on
that
one.
We
have
just
one
more
item
on
the
agenda
which
I
put
there
about
shipping
release
candidates.
B
A
A
B
C
It
would
be,
it
would
be
interesting
to
potentially
ship
pr
lifecycles,
at
least
now
that
pac
has
the
ability
for
you
to
pass
or
releases,
has
ability
to
pass
a
life
cycle
like,
even
if
we
don't
ship
proper
rcs.
I
think
like
having
the
github
ci
stuff
be
able
to
push
to
maybe
a
different
repository,
maybe
not
build
packs,
slash
lifecycle,
but
build
packs.
C
You
know
beta
lifecycle
or
something
like
that,
would
go
a
long
way
to
being
able
to
make
it
easy
for
observers
of
prs
to
test
and
potentially
integrate
those
changes
into
their
systems.
For
you
to
kind
of
help,
help
verify.
B
So
I
guess
the
prs
and
commit
so
this
commits
to
mean
and
commits
to
the
release
branch.
They
do
publish
all
the
artifacts.
So
if
you
wanted
to,
you
could
go
and
run
a
build
with
those
artifacts,
but
you
kind
of
have
to
know
where
to
look
right
like
to
go,
find
the
commit
sha,
that
it
was
tagged
with,
and
it's
just
like
a
little
messy
right.
It
would
be
more
convenient.
I
think,
if
we
had
a,
I
mean,
let's
just
like
go
to
pack
right,
did
they
show
their
releases?
B
B
Do
you
know
jesse
if,
like
on
the
heroku
side,
that'd
be
something
you'd
be
willing
to
invest
in,
or
is
that.
C
Yeah,
I
don't
think
we'd
be
against
it.
I
don't
know
what
the
timeline
would
look
like
for
doing
something
like
that.
But
if
there
was
a
consistent
rc
release
process,
then
I
don't
think
we'd
be
opposed
to,
like
you
know,
having
a
heroku,
slash,
buildbacks,
you
know
tagged
as
like
20-rc
or
something
like
that,
because
that
may
give
us
a
playground
to
kind
of
play
around
with
our
build
packs.
In
that
same
same
thing
as
well,
it
would
basically
be
a
separate
builder,
but
the
but
yeah.
C
I
don't
think
I
think
our
languages
teams
would
be
would
be
up
for
that.
B
We
can
ask
on
the
pacquiao
side
and
they
I
don't
know,
maybe
google,
who
knows.