►
From YouTube: Working Group: 2022-03-22
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
All
right
welcome
everyone
to
the
ghetto
working
group,
noodles
yeah-
maybe
thank
you
for
that.
A
I
will
hand
down
the
tmcsd
stuff.
All
right,
yeah
feel
free
to
add
yourself
to
that
in
this
list.
If
you
don't
have
the
meeting
note,
let
handy
share
this
with
you,
real
quick
feel,
free
to
add
yourself
there
to
the
list.
A
Okay,
so
could
we
have
a
note
taker
today.
A
To
any
new
faces
will
be
played
chris,
I
don't
think
so
right,
no,
no.
A
Irish
for
me,
you
are
on
your
face.
I'm
sorry
if
you
are
not,
but
welcome
and
really
love
you
to
me
that
I'm
really
sorry
for
some
sure.
D
C
No,
I
think,
just
getting
some
approvals
from
at
least
a
couple
of
the
folks
who
are
on
the
maintainers
list
that
aren't
myself
and
emily
and
dan.
This
would
be
tim
and
forrest,
and
david
and
arjun
looking
at
that
list.
C
D
I
think
this
is
still
waiting
on
sam
to
address
some
feedback
and
I
know
he's
out
for
on
vacation
for
a
couple
weeks.
So
I
don't
know
if
we're
gonna
hear
back
in
the
near
future
here
if
we
thought
it
was
urgent,
I'm
sure
he
wouldn't
mind
if
someone
you
know
took
over
this
and
made
the
updates,
but
if
we
don't
feel
like
it's
urgent,
I
think
we
can
just
wait
for
him
to
come
back.
D
I
feel
like
I
was
being
the
hold
out
on
this
one,
but
I
thought
about
it
more
and
I'm
pretty
convinced
that
dan
is
right
and
we
getting
our
policy
in
place
early
will
help
us
do
this
sustainably
in
the
long
run.
My
only
request
at
this
point
is
that
we
include
the
dependencies
in
there
too,
because
I
think
all
the
same
rationale
applies.
E
C
I
think,
in
most
of
the
cases,
the
dependencies
support
basically
aligns
with
the
like
upstream
dependencies
support
windows,
so
things
like
when
node
falls
out
of
support
for,
like
the
actual
node
maintainers,
we
would
then
no
longer
support
the
node
dependency.
C
The
problem
for
this,
I
think,
is
like
there
are
some
dependencies
that
are
supported
for
like
a
really
long
time.
I
want
to
say
like,
for
example,
like
ruby,
I
think,
is
one
of
these.
I
think
they
support
their
stuff
for,
like
upwards
of
like
three
plus
years.
C
Yeah
but
basically
they
just
are.
C
They're,
like
supporting
you,
know
the
three
last
miners
and
they
come
out
with
a
minor
basically
every
year
and
so
you'll
see
like
a
security
patch
on
like
a
minor
version
from
three
years
ago
that
we
arguably
would
support.
C
E
It
maximum
yeah
what
it
sounds
like
the
policy
would
have
different
rules
for
dependencies
since
there
are
different
kind
of
like
you
were
saying
ways
to
track
this.
D
D
And
then
also
that
would
affect
sort
of
the
mitigation
strategies
we
proposed
to
people
yeah
right
now,
at
least
for
the
you
know,
our
bill
packs
download
these
dependencies.
So
if
we're
saying
to
people,
you
know
you
can
relocate
the
build
pack
image
if
you
want
to
pin
past
two
years
well,
that
doesn't
work
so
hard.
If
we
delete
the
things
it
depends
on
right,
so
you'd
have
to
you
know,
go
through
the
steps
to
make
an
offline
version
and
relocate
it.
E
Along
that
train
of
thought,
it
seems
like
we
might
want
to
have
different
retention
policies
for
for
like
builders
and
run
and
build
images,
because
they
would
have
different,
possibly
life
cycles.
I
guess
than
the
build
pack
itself
and
right
now.
I
think
this
proposal
just
kind
of
lumps
every
image
type
together.
It
doesn't
differentiate
between
those.
Does
that
seem
like
something
we'd
want
to
break
out
as
well,
because
I
mean
at
that
point
we
could
have
a
similar
thing.
C
Yeah
we're
very
getting
we're
very
quickly
getting
to
a
point
where,
like
image,
retention
policy,
isn't
really
like
a
it's
like
more
of
an
abstract
concept
than
like
something
that
really
matters,
because
we
retain
images
for
so
long
that
you're
just
going
to
have
like
effectively
infinite
corpus
of
images.
Anyway,.
D
D
Maybe
this
is
what
we're
verging
on,
but
when
we
tell
people
to
rely
on
a
mutable
tag,
so,
like
you
know
it's
the
builder
base
and
we
expect
people
to
keep
using
it.
You
know,
I
think
we
can
clean
up
old
things
that
used
to
be
at
the
latest
version
of
that
tag
after
a
certain
retention
policy,
but
we
should
talk
about
when
we
would
be
open
to
totally
removing
one
of
those
tags,
and
I
think
we
should
be
more
cautious
about
that.
D
E
Yeah,
that
was
one
of
the
edge
cases
called
out
was
like
what
do
you
do
when
there
is
no
newer
image
and
that
image
gets
older
than
you
know,
two
years
or
whatever
you
know,
the
policy
is
says
and
the
way
that
it's
in
there
right
now,
I
believe,
is
that
it
will.
We
will
keep
that
until
there's
an
official
announcement
of
basically
that
thing
being
retired,
and
then
I
don't
remember
what
it
was
six
months
or
a
year
past
that
then
we
would
cut
it,
we
would
drop
it.
E
Okay,
that
sounds
like
I
got
some
rewriting
to
do
and
if
someone
from
the
the
dependency
team
wants
to
to
chime
in
and
help
with
that,
I
would
appreciate
it
rewriting.
C
I've
made
the
kind
of
like
suggested
changes
that
this
is
optional,
that
there
are
a
set
of
rules
that
should
be
followed.
If
buildpack
opts
into
supporting
this
behavior,
one
of
them
being,
they
should
attach
a
label
onto
the
image.
So
it's
easy
to
actually
detect
if
a
user
manually
disabled
the
s-bom
functionality
by
just
inspecting
the
images
labels,
and
then
I
changed
the
environment
variable
so
that
its
omission
is
equivalent
to
having
explicitly
set
it
to
false.
A
Select
no
more
here:
okay,
leave,
cmb
updates
questions.
A
E
E
We
should
have
a
datadog
build
pack,
hopefully,
by
the
end
of
the
week,
it'll
be
1.0.
There's
a
beta
release
right
now
that
we
have
published,
but
it's
looking
good
so
we're
thinking
that
by
the
end
of
the
week
we'll
have
that
published
and
that
supports
java
and
believe
node.js.
E
A
Yeah
from
my
side,
I
will
be
triggering
a
a
health
assessment.
A
Open
source
projects
initiated
or
maintained
by
vmware
there's
a
set
of
guidelines
that
define
the
health
status
for
an
open
source
project,
and
I
believe
that
the
first
or
the
best
way
that
I
have
found
so
far
to
see
where
to
start
and
where
to
continue
the
good
work
you've
been
doing
for
the
project
is
to
actually
compare
the
current
status
against
the
baseline
and
see
where
we
are
doing
good,
where
we
need
support
and
help,
and
that
will
also
help
me
lay
out
a
plan
for
increasing
community
engagement
for
the
project.
So.