►
From YouTube: CNB Weekly Working Group - 17 Feb 2022
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,
everyone
please
sign
into
the
document.
If
you
have
not
already
up
next,
do
you
have
any
introductions
or
new
faces?
I
see
familiar
faces,
so
I'm
gonna
assume
that's
a
no
moving
on
to
release
planning
in
updates,
starting
with
life
cycled,
with
any
updates
on
lifecycle
releases.
A
Sounds
good?
What
about
platform
do
we
have
any
pac
or
techno
other
platform
releases
coming
up.
C
Oh,
look
at
that
blog
pack
did
release,
I
believe
earlier
this
week
or
late
last
week,
but
yeah
so
that
that's
out
and
there's
no
nothing
scheduled
at
this
point
in
time.
A
A
D
Yeah,
well,
I
guess
we
cut
off
the
discussion
in
the
core
team.
Sync,
I
think
sam
was
suggesting
potentially
having
the
data
from
the
old
bomb
format
potentially
available,
like
in
the
s-bomb
directory.
D
Or
basically
string
it
like
our
other
s-bomb
stuff,
I
think
we
should
remove
stuff
off
the
label,
because
that's
what
there
are
current
issues
with
injecting
large
amounts
of
data
on
labels.
That's
all.
D
But
I
think
if
we
wholesale
just
remove
stuff,
we
are
to
some
degree
coupling
like
platform.
Api
updates
to,
I
guess,
like
build
pack
api
to
some
degree.
A
E
E
E
E
Now,
if
you
remove
the
label
and
you're
just
downloading
that
specific
folder,
which
is
that
specific
layer
like
we
lean
away
to
get
the
other
warm
files
somewhere
in
the
back
and
that
needs
to
be
stored
in
a
separate
layer
which
is
easily
fetchable
with
just
that
layer
and
nothing
else
in
the
image.
So
those
were
the
easy
way
to
solve.
This
would
be
to
just
put
it
in
the
s1
folder
on
the
top
as
a
merged
drama
file
like
this.
Currently
in
the
s1
rfc.
E
There
was
this
clause
where
you
can
merge
the
entire
thing
and
put
it
on
the
top
level
with
the
bom
extension.
E
So
if
you
just
put
dot
in
there,
it
will
never
conflict
with
the
cyclone
dx
based
pdx
or
whatever
format
we
had,
and
that
rfc
also
provided
like
canonical
location
for
merged
form
files,
which
is
what
we
currently
output
right
in
that
directory.
So
it's
just
moving
that
from
there
to
the
to
this
in
in
platform
online.
That
way,
you
don't
entirely
remove
all
of
the
boms
that
older
buildbacks
outputted
and
there's
a
single
command
on
the
backside.
Just
back
download
this
form.
It
gives
you
all
these
forms.
A
I
feel
like
this
is
similar
to
when
we
first
went
through
the
s
bomb.
Rc
sort
of
what
I
was
hoping
to
do
with
compatibility
is
like
move
to
this
file,
but-
and
I
was
gone
for
part
of
this
discussion
decision
making.
But
I
remember
there
being.
A
Push
back
around
that
that
we
sort
of
wanted
to
move
away
from
this
all
together,
mostly
because
the
format's
not
well
defined
enough
to
have
a
contract
around
it
and
getting
rid
of
this
label
is
like
sticking
with
that
decision.
We
made
as
a
group
to
try
to
move
away
from
this
in
a
more
decisive
way
and.
E
I
think
what
we
never
proposed
in
that
rfc
was
complete
removal
of
the
label.
We
decided
that
we
would
move
to
a
new
bomb
format
and
at
some
point,
we'll
deprecate
the
old
one
along
with
the
apis
and
then
get
rid
of
that.
But
now
what's
happening
is
we
are
still
keeping
those
buildback
apis
but
we're
completely
removing
whatever
output
they
had
from
from
the
output
image
in
a
way
that
is
fetchable.
A
E
Like
it's,
it's
just
how
we
define
the
spec.
The
spec
says
that
the
buildback
outputs
the
bomb.
We
must
do
something
with
it
right
like
even
regardless
of
whatever
platform
you're
on
it's
either
we
change
like
we.
We
definitely
decide
to
break
the
compatibility
we've
had
between
the
like
the
buildback
api
being
decoupled
from
the
platform
api,
which
I
think
would
turn
up
a
couple.
It's
not
not.
E
Like
we've,
never
broken
all
buildback
functionality
in
new
platform,
api
like
we
may
have
done
something
where,
like
with
this
small
change,
we
never
said
that
buildback
o5
could
not
put
a
bomb
anymore
and
that
wouldn't
go
anywhere.
We
just
said
that
buildback
was
seven,
will
not
be
able
to
output
the
bomb
in
in
the
old
format.
We
we
never
broke
that
layer
of
compatibility
that
older
buildback
apis
were
not
working
on
a
newer
platform
api
anymore.
In
a
way
that
is
expected.
E
A
I'm
curious
what
implementation
maintainers
think
of
this
natalie
and
jesse.
C
Before
we
get
into
that,
do
you
all
mind
kind
of
summarizing
a
bit?
What
the
strategy
here
is.
C
A
C
A
Right
now,
bill
packs
can
generate
two
formats
either
both
because
they're
a
new
build
pack
and
they
can
do
a
deprecated
one
in
the
new
format
or
just
the
old
one,
because
they're
an
old
build
pack,
but
you
get
two
formats
of
bom.
One
of
them
already
goes
into
a
layer.
The
other
one
goes
into
a
label.
The
question
is:
do
we
just
delete
the
label
and
just
drop
that
data
on
the
floor,
or
do
we
put
it
into
the
layer
with
the
new
data?
That's
the
question
right.
C
D
Personally,
okay,
removing
just
dropping
a
label,
but
I
I'm
not
a
heavy
s
bomb
user
and
if
that's
going
to
violate
some
sort
of
spec
contract,
then
I'm
okay,
keeping
keeping
the
file
but
yeah,
whatever
simplest.
And
so
for
me.
I
rather
just
drop
it,
but
I'm
okay
with
keeping
that
file
around.
If
we
think
that
that's
necessary.
D
That
would
be,
my
question
is
like:
are:
is
pack
gonna
read
this
new
file
like,
like,
I
don't
know
like,
I
know,
there's
probably
other
platforms
out
there.
That
will
read
it
based
on
this
conversation
like
you
know,
sam
obviously
wants
it
to
be
there
for
a
reason,
but
yeah
I'd
hate
to
introduce
like
another
file
that
literally
no
platforms
are
gonna
use.
Yeah.
E
E
C
Yeah,
that's
still
a
work
in
progress
right,
it's
like
did
it
actually
get
murdered.
E
Hey
it's
it's!
I
I
don't
even
know
from
an
small
perspective.
We
are
certainly
not
using
the
old
label
stuff
anymore.
I
don't
know
how
other
other
vendors
are
dealing
with
it,
but
it's
purely
from
what
the
life
cycle
has
done
so
far
perspective.
E
C
A
A
D
E
A
You
could
imagine
it
being
useful
both
places
right.
The
platform
wants
to
know
what's
in
there.
Kind
of
and
build
packs
want
to
know
what
to
name
the
file
for
different
outputs,
but
build
packs
are
not
outputting
the
file
in
a
new
way.
So
yeah.
E
A
E
A
A
D
A
That
is
in
the
build
pack
api,
so
it's
describing
what
types
of
files
build
packs
are
allowed
to
produce,
so
we
don't
have
to
change
it
like
maybe
on
the
platform
side,
we
would
want
to
add
some
information.
E
E
So,
just
just
some
background
around
that
the
reason
we
added
that
line
was
from
the
dockerfiles
rfc.
You
start
with
the
base
locker
file
that
has
an
s1
defined,
and
then
you
add
extensions
on
top
of
it,
and
the
life
cycle
adds
that
as
form
to
the
to
the
output
image
you
now.
E
So
there
were
two
reasons:
one
was
like
a
short
circuit
so
that
if
the
s
bomb
is
present
in
the
last
layer
and
the
image
points
to
that,
the
life
cycle
doesn't
need
to
gen
drawn
the
like
the
package,
gen
script
or
whatever
was.
I
am
forgetting
the
name
of
the
s
bomb
generation
script
and
during
extensions,
so
that
like,
if
you
provide
an
image
that
already
has
an
s4
we're
not
generating
anything
new.
We
just
reuse
that
thing.
E
If
it's
not
present
as
the
last
layer
lifecycle
would
then
run
that
package
generation
script
again
and
put
it
in
the
right
place
so
that,
finally,
when
exporter
is
reading
in
your
run
image,
there's
only
one
place
that
you
needs
to
validate
and
read
the
s1
from
regardless
of
where
it
came.
So
if
it
came
from
an
existing
image
or
whether
it
came
from
an
extension
which
then
run
gen
packages,
it
will
all
end
up
in
the
last
layer
with
the
digest
in
the
appropriate
format
in
the
label.
A
Putting
the
docker
file
extension
stuff
aside
for
a
minute,
like
maybe
there's
stuff,
we
want
to
call
out
in
that
rfc
about
how
we
generate
run
image
s
bombs,
but
just
like
as
a
user
who
has
a
wrong
image,
and
let's
say
I
want
to
use
a
docker
file
to
make
a
change
to
it,
that
you
know
I
want
to
like
change
an
environment
variable
or
something
like
that
when
you
say
enforce
that
this
must
be,
I
guess,
an
environment
variable
wouldn't
add
a
layer,
but
I,
as
a
user,
want
to
make
some
sort
of
change
when
you
say
enforce
with
the
life
cycle,
then
not
accept
this
as
a
valid
run.
A
E
I
would
assume
it
would
throw
a
warning
if
nothing
else,
because
here's
the
thing
that
rfc
proposes
that
you
have
a
post
image,
build
step
that
adds
the
s4,
so
you're
you're.
What
you're
proposing
in
that
scenario?
What
would
happen
is
someone
created
the
image
they
attached
the
spawn?
They
took
the
output
image
and
then
they
made
extensions
on
top
of
it,
and
then
they
used
it.
A
A
That's
pretty
common
user
and
to
make,
like
you
know,
like
a
new
home
directory
or
something
for
my
user,
like
you
can
do
stuff
like
that.
That
wouldn't
need
to
change
the
bomb
or
even,
if
I'm,
installing
something
on
this
image,
where
I
should
change
the
bomb
I
feel
like.
E
So
that's
why
I
said
we
should
at
least
warn
that
your
small-
maybe
if
you
want
to
remove
that,
must
or
should
and
the
life
cycle
should
warm-
should
send
out
the
warning
that
the
s
bomb
is
outdated.
That's
fine
with
me,
but
we
should
have
some
indication
that
the
image
you're
using
and
the
airspun
that's
attached
to
it
is
not
correct.
A
A
Gives
people
a
false
sense
of
confidence,
because
even
without
that
warning
like
who
knows,
if
that
thing's
up
to
date
or
not
or
you
could
move
an
out-of-date
thing
to
the
last
layer,
it's
like
we're
trying
to
use
this
as
a
hint
about
whether
it's
correct
or
not.
But
there
are
it's
not
really
within
our
control
to
know.
E
I
always
wanted
it
to
be
attached
in
a
way
that's
closely
coupled
to
the
image,
because
now
we
have
like
creating
an
image
then
like
mutating
it
and
then
republishing.
It
like
the
whole
concept
is
janky
to
me
in
the
first
place,
and
now
we're
saying
that
okay,
we
can
mutate
it
and
then
we
can
also
add
other
things
on
top
of
it
like.
What's
the
point
of
that
in
the
first
place,
then
like,
if
you're
not
fitting
about
this
from,
like,
let's
see
this.
A
A
E
But
we
would
be
able
to
figure
out,
like
let's
say
we
we
went
to
the
annotation
or
attachment
route.
We
would
be
able
to
figure
out
if
one
of
your
base
images
had
that
as
pop
and
then
what
changes
you
made
on
top
of
that
so,
like
let's
say
you
started
with
the
rel7
image
or
relate
or
ubuntu
image,
and
they
were
shipping
as
forms
as
attestations,
alongside
the
image
and
you're,
using
that
as
the
base
image
to
create
your
your
cnb
stacks
or
whatever,
like
that
way.
E
E
So
that's
why
I
I
wanted
this
whole
thing
to
be
like
stations
in
the
first
place,
so
that,
with
your
base
image,
you
have
your
digest
and
the
ds
form
is
attached
to
that
image.
Explicitly
you
don't
have
to
care
about
freebases
or
anything
or
extensions
for
that
matter,
because,
like
as
soon
as
you
use
it
in
the
app
image
each
of
the
layers
like
you
can,
you
can
just
say
this
till
here.
It
was
this
image
and
you
can
just
fetch
the
s1
for
that
image.
E
A
A
We
don't
want
to
give
like
s-pumps
have
this
place
in
the
security
world,
so
I
think
we
should
be
straightforward
about
what
we
can
and
can't
guarantee.
As
far
as
accuracy,
it's
like
you
is
the
provider
of
the
basic
image
or
the
provider
of
the
extension.
You
need
to
guarantee
that
it's
accurate
and
if
we
sort
of
pretend
we
can
then
we're
being
misleading
yep.
E
E
But
now
we
we
purposefully
are
saying
that
okay,
like
there
were
layer
editions
made
later
on,
we
know
they
were
made.
Some
things
might
have
changed,
might
not
have
changed,
but
we're
still
using
the
stainless
form
because
it
was
attached
in
the
format
that
we
defined
and
our
format
allows
response
to
be
stale
and
still
reused.
A
I
was
sort
of
using
your
point
to
argue
for
the
opposite:
we're
like
we
don't
know
whether
it's
good
at
all,
ever
whether
it's
the
last
layer
or
not,
and
therefore
it's
the
it's,
not
the
responsibility
of
the
life
cycle
to
make
that
choice,
and
we
should
make
it
clear
that
it's
not
the
responsibility
of
the
life
cycle
to
decide
whether
it's
good.
I
think.
D
That's
kind
of
where
I
am
too
yeah.
I
I
like
I
like
putting
this
on
the
platform
that
may
mean
we
need
more
platform
things
so
that
you
can
hook
into
right
before
the
export
happens,
and
you
can
know
that
that
the
run
image
no
longer.
You
know
that
has
layers
past
that
or
something,
but
I
don't.
I
don't
feel
like.
D
I
want
to
bake
this
in
a
life
cycle
like
if
a
platform
wants
to
be
super
strict
about
it
and
either
deny
building
on
run
images
that
have
layers
that
don't
end
with
an
s-bomb.
That's
fine,
but
I
don't
feel
like
it
should
be
baked
into
life
cycle
personally.
E
D
And
that's
what
I'm
saying
with
like
the
like
a
hook
into
either
right
before
exporter
or
or
similar.
You
know
we
may
need
to
do
something
else,
to
life
cycle,
to
kind
of
give
platforms
the
opportunity
to
kind
of
inspect.
What's
about
to
happen
as
far
as
the
run
image
is
concerned,
and
they
can,
you
know,
start
throwing
up
warnings
or
errors
and
do
what
they
need
to
do.
D
I
guess
that's
up
to
the
platform
if
they,
I
guess
like
I
don't
know,
I
don't
know
exactly
like
creator
yeah.
It
does
make
a
little
murky
with
creator
it's
in
process
right,
but
the
like.
I
don't
know
whether
we'd
be
able
to
call
out
two
extensions
that
way
it
depends
on
how
we
write
the
extension.
I
guess.
E
All
of
this
will
will
happen
without
the
platform
doing
anything
and
the
the
last.
There
also
was
like
a
nice
way
for
us
to
guarantee
that
the
life
cycle
knows
when
to
run
gen
packages
versus
when
not
to
run
it.
A
Stuff
belong
in
the
docker
files,
extension
stuff,
we're
talking
about
running
gen
packages
or
not
like
none
of
this
is
in
like
I'd
love,
to
get
to
the
point
where
we
could
generate
an
s
bomb.
That
includes
the
run
image
like
regardless
of
the
dockerfile
stuff,
but
the
way
I
think
about
it
is
the
dockerfile.
Extensions
are
different
than
buildpacks
in
that
you
have
to
trust
them
more
or
I
guess
you
know
similar
to
build
packs
and
that
for
the
s
bomb,
you
have
to
trust
like
right.
A
E
I
just
find
it
weird
because,
like
with
with
the
buildbacks
api
or
like
the
interface
we
exposed
to
them,
we
we
never
take
an
s
form
like
that.
The
buildback
previously
generated,
and
then
they
decided
it
was
stale
and
keep
it
like.
If
it
let's
say
it
changes
the
layer
in
any
way.
We
don't
use
the
s1
from
the
previous
launch
layer.
E
But
it's
it's
about
the
the
block
of
logic
right.
It's
like
saying
that,
there's
a
partial
s1
present
that
was
from
a
previous,
like
I
don't
know
like
it's,
it's
not
it's
not
the
same
thing.
In
this
case
there
is
an
s1
present
that
we
are
using
in
the
case
you're,
describing
there's
no
small,
present
whatsoever.
B
E
I'm
just
worried
that
you
have
in
this
form
that's
stale
and
we're,
including
that,
as
opposed
to
not
including
this
bomb
at
all,
that
would
be
a
fine
compromise
for
me
saying
that,
okay,
this
wrong
image-
I
don't
know
what
it
is
like
asmr
seems
invalid.
I'm
not
going
to
include
that,
and
that
way
it
looks.
A
E
I
I
don't
think
this
this,
the
the
video
attaching
is
the
problem
in
a
meaningful
way,
but
the
gen
packages
stuff
will
already
do
that,
for
you,
like
I'm,
not
saying
it's
small
generation
for
the
extensions
read
on
it's
like
you
using
a
random
rum
image
at
higher
than
this
form,
extending
it
outside
of
our
extensions
flow
and
then
accidentally
using
that.
B
C
E
C
Think
the
part
of
the
concern
that
I
have
is
that
we're
going
to
implement
something
that
then
we'd
want
to
eject
relatively
soon,
especially
as
we're
trying
to
stabilize
a
lot
of
the
apis.
E
B
E
E
If
these
this
image
is
only
in
the
game,
you,
you
can't
have
the
abstraction
in
the
game
it
has
to
be
in
the
registry
somewhere,
but
like
I,
for
for
any
production
use
cases
where
you're
needing
an
s
phone
you'll
probably
have
your
image
in
the
registry
anyway,
I'm
hoping,
but
that's
a
strong
assumption
to
me,
sidestepping
that
the
only
place
where,
where
something
might
break
is
when
you're,
using
a
stack,
that's
entirely
in
the
game
and
there's
no
way
to
attach
and
respond
to
it
and
like
we
are,
I
think,
the
probably
the
only
people
trying
to
solve
this
problem.
E
All
the
other
folks
in
in
the
supply
chain
security
world
have
given
up
on
this
and
they're
like
we'll
deal
with
the
s
form
once
the
image
is
actually
published
somewhere
like
if
you're
doing
something
with
the
game
and
you're,
probably
dealing
with
the
local
there
or
like
dev
use
case,
where
you're
not
actually
using
it
in
production.
So
that's
the
point.
C
Yeah,
I
think,
that's
where
my
mind
has
kind
of
carried
this
whole
demon
thing
right.
It's
I
don't
want
to
say
utterly
useless
right,
but
it's
definitely
not
as
useful
as
the
registry
and
certain
features,
I
think,
make
sense
to
either
omit
or
mitigate
through
the
platform
itself.
C
So,
like
the
platform
like
pack,
for
instance
right,
it
could
keep
a
separate
store.
It
could
spin
up
a
ephemeral
registry
and
do
everything
or
like
the
lifecycle
could
do
everything
it
wants
to
do,
and
then
pack
will
figure
out
how
to
persist
that
state
for
the
local
development
portion
of
it
right.
If
the
person
really
wants
the
daemon,
but
I
don't
think
that
that
should
be
the
limiting
factor
right.
C
And
that
being
said
right,
it
brings
me
to
the
two
possible
solutions:
one
of
them
which
is
annotations
and
then
the
other
one
I
think
was
like
the
whole
cosign.
You
know
kind
of
artifacts,
oca,
artifacts
or
sibling
images.
C
A
Feel
like
maybe
we
should
have
done
that
with
the
build
pack
s
bomb
begin
with
just
declare
bankruptcy
on
demon.
You
know
sameness,
but
given
we've
already
gone,
the
layer
way
with
the
other
s-bomb.
A
E
They
don't
have
to
worry
about
staleness
and,
like
even
creation,
is
simple
for
them.
They
just
have
to
output
a
file.
Everything
else
else
is
handled
by
us.
In
this
case,
we
are
introducing
a
new
utility
to
attach
the
s
form,
because
we
are
the
only
ones
who
will
be
supporting
and
defining
the
stressful
attachment
format.
Two.
B
E
E
Like
the
the
only
thing
we
would
need
is
the
app
image
storing
the
the
digest
for
that
in
in
a
label
which
we
already
do
and
you
can
you
can
fetch
the
attach
just
form
from
that,
whether
you
attach
it
as
from
during
the
creation
of
the
app
image
or
after
that
or
you
modify
it
or
whatever.
That's
up
to
you.
A
You
know,
maybe
what
we
need
is
just
a
way
I
mean
not
putting
this
in
the
image.
There's
a
way
for
a
platform
to
give
an
s
bomb
that
describes
the
run
image
to
the
exporter,
so
we
can
put
it
with
the
other
s.
Bombs
like
we
still
have
that
output
label
of
s
bombs,
and
I
assume
we
want
this
s
bomb
to
end
up
there
with
the
rest
of
them
right
for
now,
until
they
all
move
somewhere
better
like
we
don't
want
to
end
up
with
s
bombs
in
two
places.
A
A
E
A
A
A
E
For
for
the,
if
s
bomb
is
present
in
certain
location
in
one
of
the
input
directories
before
the
export
phase,
the
exporter
will
put
it
in
the
output
so
like
the
same
thing
with
buildbacks
right
now,
it
just
scans
the
list
of
folders,
it's
interested
in
it
and
it
finds,
and
this
one
puts
it
there
same
way
for
stack
images
or
platform
for
any
response.
If
the
platform
puts
it
in
some
directory,
the
exporter
will
put
that
in
the
final
image
and
that's
it.
A
A
B
E
Reason
I
like
this
approach
is
one
we
as
a
project,
don't
have
to
own
how
s-pumps
are
attached.
We
don't
have
to
own
how
we
get
them.
The
platform
can
decide
it
which
produces
reviews
on
our
side
and
including
it
in
the
spec
like
back
in,
like
certainly
wants
to
now
support
annotations
or
cosign,
adjustations
or
notary.
C
A
When
you
all
change
your
mind
in
the
future,
I'm
gonna
start
like.
I
should
start
in
advance
making
clips
of
these
videos
for
things
that
I
think
people
are
going
to
walk
back
later,
so
I
have
them
ready
to
pull
out
at
different
moments,
not
that
this
is
one
of
them.
Natalie
won't
walk
this
back,
but
it's
more
about
the
rest
of
you.
A
C
So
we
have
five
minutes
and
I
didn't
want
to
walk
back
to
the
previous
conversation,
not
throwing
any
wrenches
or
anything.
But
I
was
looking
at
the
spec
and
I
was
wondering
it
sounded
like
we
wanted
to
define
what
this
legacy
bomb
format
would
be.
That's
generated
is
that,
where
is
that
going
to
be
defined?.
E
A
C
C
I
think
to
me
I
I
I'd
favor
like
it
being
specified,
because
I
think
people
that
implement
a
platform
would
want
to
reference
the
spec
and
not
have
to
search
around
for
that
sort
of
answer.
I
know
again,
it
kind
of
adds
a
little
bit
more
work,
but
if
we're
trying
to
say
that
the
spec
is
the
source
of
truth,
I
think
it
should
be
clear
in
that
regard.
A
C
A
C
A
A
C
I'll
take
a
deeper
look
at
it
because
I
am
looking
at
what's
on
main,
so
I
wonder
if
stuff
that's
on
different
branches
might
appear
better,
but
to
me
it
feels
like
if
it's
not
well
defined
in
the
spec,
for
a
platform
implementer
to
be
able
to
use
it.
Then
what's
the
point
right,
if
it's
just
a
backwards
compatibility
thing,
then
that's
maybe
slightly
different
and
that's
okay.
C
E
A
Maybe
I'm
being
unnecessarily
defensive
against
like
creep
of
work
here,
like
maybe
there's
something
to
be
done.
That's
like
a
throwaway
line
like
instead
of
it,
could
be
one
of
the
extensions
to
find
and
build
tech
spec
or
our
legacy
bomb
extension
link
to
it
somewhere
where
it
already
exists.
You
know
like
if
it's
not
adding
a
bunch
of
stuff
that
makes
it
seem
like
a
first
class
citizen,
then
I'm
okay,
if
it's
just
a
pointer
to
where
someone
could
answer
their
question
more
than
like
this
is
a
very
important
feature.
B
C
Yeah,
I
guess
part
of
me
was
just
expecting
like
pointers
to
different
formats
that
didn't
even
have
to
be
part
of
this.
This
project
right
but
again,
I
I
just
didn't
see
that
reference
there
and
that's
really
my
my
sticking
point.