►
From YouTube: Implementations Sync: 2021-01-28
Description
Meeting notes: https://bit.ly/38pal2Z
C
Yeah,
I'm
I've
got
a
couple
pr's
out
for
one
for
acceptance
test
and
I've
got
a
spec
pr.
That's
sort
of
holding
up
the
implementation
of
that
spec
pr
they're,
both
very
minor,
though
so,
I'm
just
kind
of
waiting
on
this
to
work
their
way
through
the
approval
system
and
then
yeah.
That's
all
I've
got
this
week.
D
C
A
D
Oh,
I
have
one
more
thing
to
share
regarding
the
question
that
I
put
like
a
week
or
two
ago
about
the
go.
Mother
guns
go
some
I'm
having
some
conversations
with.
Maybe
I
put
it
in
our
slack
channel.
Oh,
although
it's
in
the
vmware's
live
channel,
so
forget
about
it.
I'm
having
some
conversation
with
people
that
are
kind
of
should
be
considered
as
experts
in.
B
E
My
only
update
is
kind
of
a
non-update
as
well.
Besides
submitting
the
sid
rfc,
I've
been
kind
of
distracted
with
other
other
stuff,
unfortunately,
but
definitely
looking
to
address
your
comments
on
there
thanks
everyone
who
commented
so
far
and
happy
to
talk
about
it
further
here
too
deeper
in
the.
B
B
C
C
The
way
we
name
the
directories
for
volume.
Caching
is
not
valid
on
windows;
it
wasn't
a
problem
until
it
suddenly
wasn't
ciac
when
it
couldn't
check
out
the
repo,
and
so
I
had
to
rebase
and
rewrite
those
commits
to
have
friendly
names
that
could
be
checked
out
on
windows
and
so
just
kind
of
led
me
to
think
that
we
should
at
least
discuss
what
that
you
know
what
changing
it
might
look
like
or
whether
we
want
to
continue
supporting
sort
of
both
paths,
because
I
know
there's
some
runtime
translation.
C
You
know
if
it's
windows,
it
looks
for
them
named
a
different
way,
but
you
know
just
from
a
platform
perspective.
I
think
it
would
be
kind
of
nice
to
consolidate
to
a
single,
a
single
directory
name,
but
there's
a
lot
of
things
to
consider
that
we,
you
know,
I
think
I
was
talking
to
emily
in
a
side
conversation
briefly
and
it's
like
we
don't
have
versions
in
the
metadata
and
we
don't
have
you
know,
then
you've
got
to
kind
of
make
decisions
around.
C
A
I
think
to
really
solve
this
and
other
problems
that
I
think
will
arise
as
we
want
to
make
other
changes
to
the
cash
metadata
like.
I
could
see
us
wanting
to
make
sure
that
we're
only
restoring
cashes
that
were
for
the
correct,
stack
or
stuff
like
that.
I
think
we
then
need
to
right
now.
The
cache
format
is
totally
left
out
of
the
platform
api,
but
I
think
we
should
need
to
roll
that
into
the
platform
api.
A
I
think
it
will
create
an
issue
where,
right
now,
you
can
kind
of
use
a
new
platform
api
and
then
fall
back
to
a
life
cycle.
An
older
life
cycle
with
an
older
platform
api
and
the
same
cache
can
still
be
used.
We'll
probably
have
to,
I
think,
maybe
the
first
step
is
just
building
in
a
default
into
the
lifecycle.
Let's
say
the
o5
api.
A
A
A
C
C
Yeah,
that's
where
I'm
I'm
a
bit
confused
like
a
platform
perspective
where
you
build
both
windows
and
linux,
and
you
don't
really
know
where
it's
going
to
go
like
I'm
sort
of
worried
that,
like
you
know
they
might
just
like
pull
volume
down
and
like
it
might
be
intended
for
windows.
But
then
you
know
I.
C
E
And
forget
my
ignorance
on
it
is:
is
the
main
concern
about
and
the
main
motivation
to
to
spec
this
out
and
version
it
to
prevent
cache
misses
on
a
on
upgrade
like
we
had.
We
would
have
old
caches
that
if
we
were
to
make
this
change,
they
would
just
be
ignored
or
the
other
bigger
consequences
than
that.
A
Downgrade
and
we
could,
we
could
use
life
cycle
version
information
to
sort
of
describe
what's
going
wrong
to
people,
but
we
typically
don't
at
this
point,
like
all
of
the
descriptions
of
what
doesn't
doesn't.
Work
is
in
the
language
of
apis
right
rather
than
life
cycle
versions,
and
I
don't
know
if
we
want
to
make
people
think
about
both
lifecycle
versions
and
api
versions.
When
they're
doing
compatibility.
C
C
C
C
Anyway,
I
don't
think,
there's
anything
else
to
discuss
there.
I
can
remove
the
label,
maybe
maybe
I
could
create
an
issue
in
life
cycle
that
is
pretty
broadly
suggesting
that
we
add
more
data
to
the
metadata
and
then
whatever
that
looks
like
we'll
spec
it
out,
and
you
know
from
there
or
something
like
that.
B
B
D
B
B
B
D
So
the
first
thing
is
that
all
this
discussion
came
up
because
we
had
this
issue
with
hcr
and
office,
so
we
started
looking
at
our
go
mod
and
go
some
files,
and
I
saw
that
there
are
some
like
lines
with
a
comment.
That's
saying
this.
These
lines
are
indirect
and
I
said
I
mean
I
was
wondering
what
are
these
and
I
decided
just
to
remove
all
of
them
and
I
ran
make
all
and
everything
passed
successfully,
and
I
was
wondering
why
do
we
have
them?
D
I
know
that
sometimes,
when
you're
running
gomo
tidy,
I
mean
it
deletes
them,
and
sometimes
it's
not,
but
if
you're
manually
doing
this,
then
I
mean
it
looks
like
they're.
We
don't
really
need
them,
so
I
was
wondering
why
they
were
being
added
like
from
the
first
place,
and
the
other
question
was
that.
D
After
I
pushed
my
last
pr,
I
think
then
natalie
told
me
that
she's
running
like
make
unit
or
make
build.
I
don't
remember
exactly
what
on
her
local
machine
and
she's,
seeing
changes
in
mod
and
go
some
files,
and
I
did
the
same-
I
mean
same
commits
everything
was
exactly
the
same
on
my
machine.
Everything
was
like
clean
and
we
were
worried
that
when
github
will
do
this
and
we
will
get
like
a
dirty
image
because
it
will
see
some
changes
so
again
we're
not
really
sure
what
happened.
D
We
saw
that
there
is
a
bit
different.
I
mean
they
we're
using
and
different
minor
versions
of
go
and
also
there
are
a
few
packages
under
the
go
path.
That
now
is
having
and
I
don't
have.
But
anyway,
it's
like
two
open
questions
that
I
have
no
idea
what's
going
on
there.
So
if
anyone
has
any
experience
with
this
kind
of
issues,
I
would
love.
D
C
I
don't
know
why
they're
necessarily
brought
in
and
how
it
works
without
them
being
in
the
go
mod
when
you
manually,
do
it
yeah.
I
know
some
of
the.
I
think
there
were
some
changes
in
one
of
the
pr's.
I
did
as
well
with
like
the
go
mod
tidy
or
something
did
it
updated
as
well,
and
I
think
it
was
the
tools
folder,
which
is
a
whole
another
concept
that
is
really
confusing.
If
you
haven't
done
before,
and
I
think
they're
changing
it
up,
let
me
go
so
like.
D
D
C
Yeah,
I
know
there's
some
is
it:
it's
not
go
vet,
but
there's
something.
Is
it
go
mod
anyway?
There's
something
that
we
we
used
to,
or
we
run
on
quite
a
number
of
our
go
repos
that
will
fail
ci
if
the
repo
is
dirty
before
you
go
to
the
next
step
right,
so
you
always
run,
go
mod,
go
tidy
or
whatever
and
then
and
then
bail.
So
we
can
at
least
do
that
to
prevent
the
dirty
images
problem.
A
I
was
just
looking
at
the
when
it
adds
this
and
when
it
doesn't,
I
can
put
something
in
the
chat
here.
This
is
just
my
internet
perusing,
but
it
seems
like
it
adds.
This
is
basically
what
justin
said,
but
it
adds
indirect
dependencies
only
when
your
direct
dependency
doesn't
have
a
go
on,
so
any
indirect
dependency
from
a
dependency
that
isn't
using
go
mod
will
get
recorded
as
indirect,
but
it
seems
like
there's
a
slight
difference
in
behavior
between
when
go,
build
and
go
test.
A
A
So
I
can
imagine
that
this
is
why
we
see
inconsistencies
because
someone's
running
go
build
on
mac,
but
then
you
know
you're
not
getting
all
the
indirect
dependencies
that
only
happen
when
you're
compiling
for
windows
but
come
on
tight.
You
would
have
them
that
kind
of
thing.
So
I
wonder
if
we
just
add
a
check
in
on
make
file
that
ensures
gomod
tidy.
Didn't
that
runs.
Go
mod
tidy
is
part
of
the
process
and
also
like
fails
the
build
if
there
was
any
diff
I
feel
like
that
should
should
suffice.
A
D
C
If
there
were
indirects
that
are
showing
up
in
one
versus
not
the
other,
it
could
be
like
that.
Your
non-go
mod
version
of
that,
like
the
docker,
if
those
are
not
the
exact
same
then
like
it,
could
be
pulling
in
different
indirect
dependencies
like
because,
as
they
were
added,
naturally
to
docker,
who
doesn't
use
gomod,
then
they'll
get
you
know,
slurped
in
by
the
gomod
tidy
on
one
person's
computer,
but
not
on
the
other,
because
it
has
to
like
you
know,
navigate
the
go
source
tree
to
figure
out
the
dependencies
I
think
or
whatever.
D
C
That's
just
a
documentation
thing
basically
like
I
don't
think
it
actually
affects
the
build
process.
It
basically
just
pulls
it
in
just
to
like
document
that
this
is.
These
are
the
things
that
were
pulled
in
when
this
person
had
this
thing.
That's
not
a
go
module
there,
so
I
think
it
all
probably
stems
to
having
different
versions.
Potentially
in
your
like
go
directory
of
a
dependency,
that's
not
a
go
module
and
then
it
sort
of
cascades
out
into
all
of
its
dependencies
that
potentially
could
make
this
different
just
reading.
What
I'm
putting
there.
D
C
A
A
B
C
B
E
B
E
E
Thank
you
all
for
who
I've
read
through
that
already
and
for
the
comments
that
are
on
there.
I
was
kind
of
thinking.
If
it's
useful,
I
could
give
kind
of
just
the
verbal
summary
if
anyone
wants
to
know
kind
of
what's
intended
there
and
then
there
were
a
couple
more
like
conver,
controversial
things
that
probably
would
be
best
solved
in
conversation
after
that.
E
E
It's
just
much
more
verbose,
but
intending
to
do
the
same
thing,
unique
identifier
in
a
system
this
doesn't
show
all
the
the
places
where
the
spec
states,
the
sid
behavior
there's
also
talks
about
the
group
id
or
for
the
group
value
as
well,
and
what
I
was
kind
of
hoping
before
we
actually
attempted
to
implement
it.
This
way
and
based
on
a
lot
of
other
feedback
that
folks
had
submitted
to
and
issues
that
we
probably
don't
actually
want
to
overload
this
environment
variable
with
the
sid
format.
E
Right
now,
the
uid
is
an
integer
group.
Id
is
integer,
works,
fine
and
then
sid
is
this
special
string
that
has
a
series
of
integers
surprise.
Surprisingly,
windows
users
are
probably
familiar
with
this
format,
so
they
would
look
at
it
and
say:
oh
that's
s
id.
I
know
if
that
is
so.
It's
not
really
that
esteric
of
a
format,
but
it's
a
misfit
for
the
particular
variable
that
we're
already
using.
E
So
the
suggestion
here
was
to
for
the
user
facing
values
to
switch
over
to
calling
a
cmd
user
or
cmd
owner
sid,
and
that
kind
of
matches
the
internal
windows
definition
for
what
that
field
is
called
when
it's
saved
to
a
file.
It's
the
owner
and
the
group,
as
opposed
to
the
user
and
the
group
for
unix,
ids
and
so
yeah.
E
I
originally
suggested-
maybe
just
keeping
these
same
flags
on
here,
but
don't
really
feel
strongly
that
they
should
be
that
they
should
accommodate
both
for
the
for
the
implementations,
but
then,
as
it
goes
to
the
implementations,
all
images
that
are
are
written
by
the
an
implementation
or
platform
would
instead
of
writing,
and,
as
we
know,
those
are
tar
formats.
Instead
of
writing
the
to
the
uid
field,
it
writes
to
the
special
windows
field,
which
is
talked
about
a
little
bit
more
down
here.
E
E
Now
it's
probably
also
a
little
bit
confusing
is
that's.
You
know,
that's
all
well
and
good,
but
something
happens
now
today
and
the
there
is
some
conversion
that
happens
in
image,
util
for
and
used
in
both
pac
and
lifecycle,
where
this
cnb
user
id
is
converted
into
a
windows
permission,
and
it's
it's
pretty
hand-wavy
how
it
works,
rather
than
picking
a
very
specific
sid
to
convert
it
to
we
instead
convert
it
to
another
valid
sid
or
proxy
for
nsid.
E
E
E
So
again,
the
the
general
justice
to
to
make
the
windows
implementation
work
as
close
as
possible
to
the
linux
implementation.
Remove
the
translation
logic.
That's
there
today,
but
have
it
very
clearly
two
different
variables
for
windows,
rather
than
overloading
the
cmd
user
id
kind
of
bounced
around
there
a
little
bit
any
questions
kind
of
high
level
of
how
this
works.
A
C
E
It's
a
great
question:
there's
a
much
more
de
facto
standard
for
windows
images
today
or
specifically,
like
windows
hosts
docker
has
hard-coded
sid
in
here
that
corresponds
to
the
container
user
user.
There's.
Also,
if
you
oh
wait.
No
sorry!
I
think
this
is
probably
dinner
administrator.
If,
if
this
is
a
two,
it's
instead
container
administrator,
those
are
hardcoded
in
docker
and
in
container
d,
so
there's
always
guaranteed
those
two
users
to
be
present,
and
I
think
de
facto
all
windows
stacks
will
correspond
to
one
of
those
two
users.
E
E
You'd
have
to
do
some
magic
where
you
would
create
a
user
offline,
find
out
what
that
s
id
was
that
was
created
in
there
and
then
go
and
write
it
back
into
a
later
layer
in
your
image
or
modify
your
image
metadata
data
so
in
practice
no
one's
going
to
try
and
make
a
user
and
put
their
sid
in
there.
In
the
same
one,.
C
E
C
E
Yeah,
what
I
would
guess
like
if
I,
if
a
user,
really
wanted
to
do
that
I'd,
probably
recommend
them
to
use
a
group
id
rather
than
a
specific
user
sid
and
as
they
make
that
user.
Ensure
they're
part
of
that
group
whose
id
doesn't
change
and
windows
has
a
whole
bunch
of
of
pre-existing
groups
too.
That
could
probably
give
you
the
permissions
that
you
want.
A
I
think
what's
nice
about
the
fact
that
there's
such
strong
defaults
in
windows
is
that,
unlike
the
linux
version
of
this,
we
could
probably
make
this
optional
and
just
default
to
the
good
defaults,
which
would
be
a
good
experience
for
users,
like
I
think
most
people
wouldn't
have
to
think
about
it.
The
only
people
would
have
to
think
about.
It
are
folks
that
are
already
well-versed
in
this
stuff,
because
they're
already
going
through
a
lot
of
effort
to
change
the
esid's
right.
C
D
E
That
looks
like
there's
a
typo
there
too.
I
don't
know
why
that's
not
resolving
already,
but
this
is
a
the
sid
in
here-
is
the
a
city
for
this
group
and
so
right.
Now
every
file
is
owned
by
either
every
file
that's
created
by
pac
or
lifecycle,
is
either
run
by
built-in
administrators
or
by
built-in
users.
E
E
All
of
us
just
sometime
down
the
road,
we'll
be
troubleshooting,
a
a
user
report
that
says
my
app
got
this
user
id
and
I
don't
you
know
sid
or
my
file
got
this
sid
and
it's
not
working,
and
I
want
to
know
why
and
I
feel
like
if
it's
a
very
specific
sid,
the
one
that
matched
that
came
from
the
stack.
It's
like
you
don't
need
to
know
that
much
windows
or
a
lot
of
the
linux
documentation
will
match
up
with
the
reasons
there,
but
so
yeah
we
I
haven't.
B
This
is
this
is
I'm
just
kind
of
thinking
out
loud
here,
but
you
mentioned
that
this
logic
is
used
both
in
pack
and
the
life
cycle.
Right
so
in
in
theory,
like
pac,
is
also
going
to
be
making
changes
to
how
it
creates
like
builders
right.
The
permissions
that
are
written
in
the
builder
does
that
have
any
like
versioning
problem
with
the
like
an
older
builder
and
a
newer
life
cycle,
or
vice
versa,
that
we
need
to
worry
about.
E
E
A
I
feel
like
one
of
the
things
that's
different
between
linux
and
windows
right
now,
and
also
between
how
life
cycle
and
pack
use
image.
Retail
is
that
pack
basically
only
has
two
cases
in
both
linux
and
windows,
where
it's
either
like
in
linux.
It
wants
a
root
on
thing
or
it
wants
a
stack
user
owned
thing
in
the
live
cycle.
We
have
stack
user
owned
things,
but
we
also
have
their
parent
directories
that
we
have
to
put
in
folders
and
we
want
to
keep
whatever
permissions
they
currently
have.
A
So
I'm
a
little
leery
of
helpers
that
are
aggressively
going
to
change
all
the
s
ids
because
I
think
we
actually
want
to
be
in
a
life
cycle
have
sort
of
fine
grain
control
for
each
and
every
entry
like
what
sid
it
has,
and
we
have
sort
of
a
schema
for
tar
writers
there.
That
would
make
that
pretty
easy
to
do
in
windows
in
a
way
that's
analogous
to
how
we
do
it
in
linux.
A
E
Yeah
that
makes
a
lot
of
sense
yeah.
I
think.
Oh
sorry,
I
think
we
can
actually
get
rid
of
some
of
the
sort
of
smart
translation
and
instead
have
both
life
cycle
and
pack
everywhere.
They're
setting
a
very
explicit
uid
there'll
be
a
line
below
it.
That's
a
very
explicit
sid
if
it's
a
windows
image
and
the
helpers
I
was
thinking
on
imageutil-
would
generally
just
be
ways
to
convert
a
sid
into
the
binary
representation
needed
there.
E
So
I
would
hope.
Actually
we
get
even
more
fine
grain
for
free
and-
and
I
would
also
hope
that
we
like
every
time
that
we
add
a
new
line
where
we're
explicitly
setting
a
uid
or
a
gid.
It
just
becomes
pretty
automatic
to
set
the
the
corresponding
sid
one
after
that,
and
maybe
there's
some
light,
some
little
helpers
that
make
the
syntax
easier
there,
but
yeah.
E
E
Just
to
touch
that
a
little
bit
more,
the
part
that
makes
some
of
this
complex
of
converting
from
say
this
sort
of
representation
into
the
thing
that
needs
to
be
recorded
on
the
tar
header
is
that
the
implementation
on
windows
right
now
is
actually
only
available
through
a
syscall.
So
I
had
to
do
some
reasoning
and
some
bit
banging
to
actually
figure
out
how
to
do
that,
but
the
the
implementation
that
I
have
somewhere
is
pretty
tidy.
It
does
just
do
that.
C
I
saw
it
in
there
before
yeah-
okay,
that's
probably
the
yeah,
the
scariest
part
about
this.
For
me,
just
knowing
that
we
I
mean,
I
know
s,
ids
have
been
around
for
a
long
time
and,
like
you
said
this
is
sort
of
a
known
thing,
but
it's
still
sort
of
scary
that
when
windows
11
ships
whenever
they
decide
to
ever
make
another
version,
if
they
do
decide
to
do
something,
to
make
containers
permissions
better.
E
A
E
E
And
also
to
that
point
there
is
a
like
this
is
a
reference
implementation
written
in
c
sharp.
Technically,
this
is
not.
This
is
not
the
assist
call,
or
at
least
to
my
knowledge,
I'm
not
exactly
sure
what
the
implementation
of
the
windows
syscall
is,
but
here's
an
equivalent
implementation,
but
it's
in
c
sharp.
E
A
I'm
not
super
worried
about
this
changing
because
I
feel
like
it
would
if
it
changed
in
an
incompatible
way,
it
would
hose
windows
in
general
right
yep,
because
there's
tar
files
out
in
the
world
with
these
things,
they
can't
just
make
a
breaking
change
to
this
format.
So
if
we
have
a
working,
goaling,
inline
implementation,
I
feel
like
we
should
just
use
it
not
worry
too
much
about
it.
E
A
A
question
that
I
also
left
in
the
rfc,
which
is
right
now
like
this,
does
a
very
good
job
of
covering
how
these
values
are
used
when
generating
layers
and
the
permissions
and
layers.
There
are
a
couple
other
ways.
The
current
uid
and
gid
values
are
used
in
lifecycle
in
terms
of
how
we
use
them
to
figure
out
what
permissions
to
drop
to
after
we
do
things
that
need
to
be
privileged,
and
I
was
wondering
how
that
ties
into
this.
A
Like,
first
of
all,
do
we
have
the
same
problems
in
windows
that
we
have
in
linux?
For
why
we're
doing
this?
Like
do?
We
need
to
run
as
we're
to
connect
to
the
docker
demon
socket,
I
mean
not
root
administrator,
and
even
if
we
don't,
I
assume,
like
it
could
come
up
if
we
ever
did
root
build
plex
or
windows,
but
probably
10
million
years
before
we
get
around
to
that.
A
So
that
just
wondering
like,
if
we
ever
had
to
worry
about
permission
user
changes
in
process
in
lifecycle
in
windows,
do
we
have
to
use
the
values
you're
passing
in
to
do
the
file
permissions
to
to
make
that
change?
And
if
we
think
that's
something
you
might
want
to
do
in
the
future
like
do
we
want
to
call
it
user
sid
said
owner
sid
because
we'll
use
you
know
that
user
is
the
owner
of
the
file.
E
Yeah,
that's
a
really
good
point
I
feel
like.
We
would
also
want
to
do
that.
There
is
the
there's
like
a
impersonation
feature
and
the
windows
api
to
kind
of
draw
privileges,
and
we
do
you
do
need
container
administrator
privileges
to
access
the
docker
socket,
and
I
guess
I
don't
quite
understand
why
we
hadn't
been
bitten
by
that
yet,
but
but
yeah
and
and
the
naming
too
yeah
that
does
kind
of
make
sense
like
we
do.
E
We
did
kind
of
benefit
from
the
uid
or
the
naming
originally,
because
the
uid
and
user,
the
user
meant
the
same
thing
in
those
contexts
but
yeah,
as
you
said.
I
wonder
if,
if
that
does
feel
like
a
better
fit
of
cmb
user
sid
or
is
it
two?
I
mean?
Maybe
it's
too
subtle
at
the
environment
variable
level,
but
like
maybe
it's
fine
still
too,
but
then
I
feel
like
a
windows
user.
That
would
be
fine
for
them.
So
if
we
want
to
go
with
cnb
user
sid,
I
think
that
makes
sense.
A
E
E
E
What
we're
talking
about
too,
is
worth
talking
about
these
flags
too.
I
like
the
I
originally
kept
them
the
same
way.
Just
I
don't
know,
I'm
not
sure
where
I
went
with
that
changing
and
this
not
changing,
but
I
would
also
be
fine
with
that.
It
just
feels
like
it's.
It
makes
the
cli
flags
a
little
more
complex,
but
they
still
just
can
switch
on
the
goose
flag
and
it
shouldn't
matter.
A
I
feel,
like
the
same
reasons,
for
changing
the
environment.
Variable
apply
to
the
flags
right,
which
is
we
have
a
type
for
these
flags
that
we're
using
in
the
flag
library
and
it's
not
something
that
we
couldn't
work
around
in
both
cases.
If
we
wanted
to
keep
them
the
same.
But
if
we're
making
one
different,
I
don't
say
I
would
make
the
other
different
and
us
also.
We
sort
of
very
directly
map
from
environment
variable
to
flag
for
all
of
our
existing
configuration
options,
and
this
one
being
slightly
different
feels
like.
A
E
A
If
this
was
any
indication
it
seems
like
we
probably
need
the
hour.
I
think
we
should
also
add
going
over
rfcs
that
are
labeled
with
implementation
to
our
standing
items,
maybe
maybe
a
standing
item
at
the
end.
So
we
have
time
for
whatever's
most
pressing
to
people,
and
then
we
can
fill
the
remaining
hour
because
I'm
sure
there's
always
going
to
be
things
to
talk
about
in
the
rfcs.
A
B
B
There
was
an
open
question
about
the
label
which
I
brought
up
because
it
encodes
this
label
encodes
information,
that's
in
analyze.tamil,
which
is
derived
from
the
layer
tommles
and
you
know
essentially
like
since
we
kind
of
threw
out
the
key
renaming
from
this
rfc.
It's
really
would
be
about
adding
types
to
that
label
and
I
know,
there's
an
argument
to
be
made
kind
of
on
either
side.
B
C
A
A
B
A
B
B
E
A
That
information
sort
of
indirectly,
like
there's
a
launcher
version,
there's
either
directly
a
lifecycle
version
that
we
put
in
or
there's
a
launcher
version,
but
the
launcher
version
is
always
the
same
as
the
lifecycle
version
that
built
it.
So
you
could
figure
it
out,
but
it's
again
in
terms
of
lifecycle
versions,
we
may
want
to.
C
I
can
see
this
becoming
yeah
an
issue,
because
obviously
labels
are
pretty
pretty
nice
abstraction
for
getting
info
out
without
having
to
crack
open
an
image
and
and
for
a
platform
that
maybe
allows
someone
to
bring
their
own
builder
if
they
have
to
go
back
and
forth
because
of
a
breaking
change
of.
Like
you
know,
an
upstream
builder,
they
don't
control,
it
seems
like
downgrades
would
be
something
we
definitely
want
to
allow
platforms
to
be
able
to
support
as
best
they
can
and.