►
From YouTube: Working Group: 2022-04-26
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
All
right
new
faces
here:
police,
john,
if
you're
around
shaq,
I
don't
know
your
new
face.
Who
is
meaning,
at
least
for
me,.
A
From
june
okay
miles,
no
all
right
next
up
outstanding
rfcs,
I
think
about
the
secure
runtime
imbalance.
If
I
remember
well,
it
was
missing
a
review
but
yeah
it
was
already
approved.
A
D
A
D
Emily
to
get
back
on
this,
one
just
make
sure
that
her
concerns
had
been
addressed
with
the
recent
changes.
A
All
right
hell,
checker
billboard.
This
is
a
recently
created
proposal,
so
I
don't
know
if
daniel
would
like
to
introduce
it
like
some
comments
around
it.
Daniel
here.
A
D
Yeah,
I
just
pinged
him
to
ask
if
he
was
coming
to
the
working
group.
It
looks
like
he's
online.
D
You're
running
on,
like
a
docker
composer
kind
of
thing,
you
the
way
that
those
actually
do
health
checks
of
the
containers
that
they're
running
is
they
invoke
some
like
exec
some
command
inside
the
container
and
then
look
at
the
status
of
that.
Like
actual
executable,
I
think
dan's
coming
in.
He
maybe
can
explain
this
better
in
the
past
folks,
I
think
have
asked
us
to
put
stuff
like
curl
or
wget
into
the
stack,
so
they
can
say
invoke
those
things.
D
I
think
what
dan's
proposing
here
is
an
alternative
that
he's
kind
of
suggested
previously
in
interacting
with
these
folks.
Who've
requested
this
type
of
behavior,
but
hopefully
does
it
in
a
much
more
lightweight
manner
that
doesn't
result
in
us
having
to
add
even
more
stuff
than
the
stack,
but
I
don't
know
dan
we're
talking
about
the
the
health
check
buildback.
If
you
want
to
chime
in
here.
E
Yeah,
sorry,
I'm
late
yeah,
no,
you
pretty
much
nailed
it.
You
know
we,
this
isn't
as
much
of
an
issue
if
you're
running
on
kubernetes,
but
if
you're
trying
to
just
run
with
docker
or
docker
compose,
there's
not
really
a
native
http
health
checker
built
in,
and
so
you
have
to
use
curl
or
w
get
or
whatever.
We
don't
have
those
in
our
containers.
So
people
are
kind
of
stuck
having
to
pack
together
some
other
solution.
E
E
A
B
I
think
this
is
filed
under
the
dot-net
core
language,
family
yeah.
It
is
meaning
that,
like
technically
for
merge
all
that
this
needs
is
the.net
core
maintainers,
but
since
this,
like
is
kind
of
a
significant
change
to
the
language
family
and
may
impact
a
lot
of
pocketo
users.
I
at
least
would
be
happy
to
like
hear
from
people
across
the
project
about
how
they
think
this
would
impact
users.
F
I
think
forest
isn't
here
today
to
talk
about
it.
I
think
the
explanation
is
pretty
in-depth
if
people
want
to
read
it,
but
at
a
high
level
we're
seeing
some
failures
in
the
newer
versions
of
net
sdk
when
we
perform
builds
on
certain
types
of
apps
and
the
only
solution
that
frankie
enforced
had
come
across
was
using
sdk
as
it
comes
from
microsoft
directly
frankie.
F
Please
correct
me
if
I'm
wrong
about
any
of
this,
but
when
it
comes
directly
from
microsoft,
it
includes
the
runtime
and
the
asp.net
like
binaries,
as
well
as
the
sdk
and
that's
kind
of
considered
like
a
net
hive,
and
we
do
not
see
failures
when
that
version
of
the
sdk
is
used
and
everything
is
together
and
whether,
instead
our
build
packs
like
separate
those
three
dependencies
into
three
separate
build
packs.
So
the
proposal
here
is
for
the.net
core
sdk
build
pack.
F
We
will
be
installing,
like
the.net
hive
version
of
the
sdk
dependency,
rather
than
you
know
like
just
stripping
out
the
runtime
and
the
asp
net,
and
just
installing
sdk
by
itself,
and
because
of
that,
it's
like
a
much
bigger
dependency
and
we
also
have
some
like
overlap,
because
other
parts
of
the
proposal
include
still
including
downloading
the
runtime
and
asp.net
in
separate
build
packs.
F
I
won't
like
get
into
why
you
can
read
the
rfc,
but
essentially
this
is
a
proposal
to
change
what
we
ship
for
the
sdk
dependency
in
order
to
overcome
this,
and
also
like,
follow
more
of
like
the
net
core.
Like
best
practices
like.
I
think
this
is
the
type
of
thing
that
they
do
in
like
the
docker
alternatives
with
multi-stage
builds
so
yeah
check
out.
I
might
have
butchered
that
but
check
out
the
rfc.
It
has
big
ramifications,
for
you
know
like
download
times,
and
things
like
that.
So
I
think
that's
it.
A
Thank
you
for
that.
Yeah
feel
free
to
continue
conversation
in
the
rfc
all
right,
great
next,
up,
updates
or
questions
are
on
this
cnd
project
cloud
native,
build
packs.
I
mean
I
was
scrolling
through
every
single
async
communication
channel
from
the
cmd
project
and
wasn't
able
to
find
a
relevant
update
from
last
week.
A
All
right
actually.
F
One
thing
I
think
build
pack
api
0.8
is
out
and
we,
the
piketto
team,
is
like
working
towards
like
implementing
support
for
that
in
packet.
So
eventually
we'll
be
able
to
move
our
build
packs
over
to
build
pack
0.8
api
0.8.
A
That's
pretty
relevant,
you
have
a
link
for
that.
Please
drop
in
the
notes,
so
otherwise
I
will
try
to
find.
A
Okay,
next
up
project
update
speaking
of.net
there's
a
new
version
of
the
dot
net
core
build
pack
rules
to
forest
and,
frankly,
and
just
simply
find
the
shout
out
from
selfie.
A
It
will
be
stand
for
walking
on
this.
I
don't
know
if
maybe
frankie
would
like
to
comment
something
around
this
release.
B
Yeah,
as
this
note
states,
this
should
include
a
form
of
incremental
build
caching.
So
this
means
that,
if
you're
building
a
don
at
app
from
source
code,
if
you
build
it
and
then
rebuild
it,
you
should
see
your
rebuild
times
like
in
the
compilation.
Step,
be
a
lot
faster
because
you'll
have
your
effectively
the
contents
of
that
obj
folder,
which
is
what
makes
rebuilds
on
your
local,
faster.
A
A
Okay,
thanks
for
your
time,
I
hope
to
see
you
next
week.