►
From YouTube: Office Hours: 2021-08-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
So
hi
everyone
and
I
am
hemantika
and
I
have
been
an
lfx
mentee
for
summer
2021,
and
this
was
my
officially
first
contribution
to
open
source
and
since
then
I
have
also
my
first
time
learning
golang
and
then
like
contributing
here,
and
it
was
my
start
to
say
that
I
have
been
like
after
my
internship
I
at
microsoft,
I
have
been
sitting
idle
for
a
month
almost
and
so
after
this
it
gave
me
the
confidence
to
go
ahead
and
contribute
to
other
projects.
A
So
this
was
the
kickstart
that
I
needed
and
while
I
started
with
lfx
as
I
was
very
excited,
I
really
couldn't
keep
up
my
excitement
to
the
level
or
perform
to
the
expectations
that
I
had
since
I
had
to
undergo
a
surgery,
and
almost
I
was
like
bedridden
for
one
and
a
half
months.
It's
been
on
the
two
two
and
a
half
months
right
now,
and
even
after
that
I
would
say
the
community.
It
has
been
there
to
support
me.
A
I
used
to
post
very
silly
questions
to
jbr,
who
is
my
mentor
to
anthony
and
then
to
even
like
joe,
that
I
reached
out
to
everyone
almost
in
the
community,
to
help
me,
and
everyone
has
been
there,
be
it
through
pair
programming,
calls
or
like
answering
questions
in
the
different
channels,
but
yeah
this
program
is
coming
to
an
end,
I'm
a
bit
emotional
as
well,
but
this
is
just
the
start,
and
I
think
that
as
I
go
forward
as
I
get
a
grip
over
the
language
and
buildbacks
project
as
a
whole,
I
think
that
my
contributions
will
even
increase
sevenfold.
A
So
yeah,
that's
it.
That's
how
I
would
like
to
end-
and
I
had
also
a
blog
published
about
the
completion
of
for
the
mentorship
I'd
post
it
here
in
the
chat.
A
C
I
was
a
google
summer
of
course,
student
this
time
in
some
other
build
packs,
and
I
was
lfx
spring
mentee
as
well
for
cloud
native
communities,
but
this
time
as
I
was
exploring
cloud
native
technologies,
I
wanted
to
explore
more,
and
so
that's
how
I
joined
buildbacks
and
that's
how
it
all
happened,
and
I
don't
have
words
to
express
how
amazing
this
community
has
been
from
the
beginning
and
the
way
this
project
was
built
to
whether
it
was
joe's
regular
guidance.
C
C
Is
this
even
a
question
like
like
we
usually
you
know,
but
but
when
we
ask
and
when
we
we
are
not
only
asking
we
are
also
coming
out
of
the
comfort
zone,
I
feel
and
that's
what
how
what
what
joe
let
me
always
feel
he
was
an
excellent
mentor.
C
An
amazing
guide
always
answered
my
questions,
everything
very
quickly
and
the
most
important
part
of
any
project.
I
feel
that
I
have
learned
during
this.
Entire
journey
was
not
completing
the
project,
but
the
process
involved
around
it,
like
results,
usually
aren't
defined
because
you
know
the
progress
is
never
ending.
C
This
was
my
cloud
this,
my
cognitive
world
journey
has
been
become
been
from
past
four
or
five
months,
and
I'm
just
loving
this
entire
community
as
a
whole,
like
buildbacks,
plus
cncf,
and
because
of
I
think
this,
google
somewhat
of
code
itself,
we
have
got
an
opportunity
to
present
a
talk
with
joe
kutner
in
kubecon
as
a
panel
discussion.
I
would
let
me
find
the
link
and
I
will
try
to
share
that
link
as
well.
C
So
we
have
a
panel
discussion
where
joe
is
with
me,
along
with
the
two
other
folks
one
is.
She
was
the
lead
of
humanities,
1.22
release
team
and
another
lfx
mentee
that
worked
during
the
community,
so
that
was
about
that.
My
blog
is
also
published
and
thank
you
so
much
to
everyone
who
read
it,
and
I
hope
that
I
will
continue
the
contributions
after
this
as
well.
Thank
you
so
much.
I
will
really
really
grateful
to
all
of
you.
Thank
you.
So
much.
B
B
B
Yeah,
I
don't
know
if
I'm
pronouncing
it
good,
but
for
you
and
then
also
you,
you
take
some
time
to
write
something
about
anthony,
so
I
I
I
think
that
that's
one
of
the
most
good
things
to
share
to
other
people
that
maybe
it's
thinking
to
join
the
program
or
maybe
they're
afraid
to
share
to
some
open
source
community,
I'm
I'm
just
starting
to
do
it.
B
I
was
used
to
work
for
private
companies
and
always
working
for
you
know
private
products,
and
I
believe
that
the
first
thing
everybody
thinks
when
they
want
to
share
is
everybody
is
scared,
scared,
for
you
know,
working
with
some
other
guys.
You
don't
know,
maybe
you
never
see
them
and
everybody
is
scared
to
to
give
that
first
step.
So
what
was
the
most?
B
What
what
I
appreciate
from
your
blogs
is
how
you
try
to
break
that
idea
down
sharing
that
these
people,
it's
you
know
it's
human,
like
you
and
me:
it's
they're,
not
you
know
from
other
planets
or
normal
human
beings,
and
they
can
help
you.
You
can
learn
from
them
and
you
can
teach
them
some
stuff.
So
I
appreciate
that,
and
that's
probably
what
I
wanted
to
to
say
to
you
right
thanks
for
that
and
for
all
the
good
things
and
yeah.
A
A
We
were
really
discussing
if
there
was
a
shout
out
about
this
community
somewhere
because
really
like
the
applications
that
came
in
or
like
even
the
texts
that
we
received
about
billbags
on
linkedin
or
twitter,
and
I
think
that
it,
it
is
the
best
community
to
be,
and
my
like,
being
the
first
community.
I
think
and
like
what
britons.
A
I
mentioned
that
we
never
even
thought
twice
before
asking
silly
questions,
because
I
asked
very
silly
questions
and
I
think
that
was
the
amount
of
let's
say:
that's
how
how
much
free
we
were
with
the
community
and
the
mentors
and
for
beginners
or
for
anybody
who
is
looking
to
get
started
with
open
source.
It's
definitely
a
kick
start.
C
I
would
say
the
same
thing.
Thank
you
so
much
john,
and
I
really
appreciate
your
words
as
well
as
the
point
that
you
highlighted
that
we
that
our
blogs
might
help
lower
the
barrier
for
most
of
the
students
who
are
trying
to
join.
So
I
hope
that
is
what
we
even
blog,
as
they
say
many
folks
say
in
open
source
program
that
blogs
are
also
a
way
to
contribute
to
open
source
just
like
code.
So
I
hope
that
this.
We
hope
that
this
was
the
contribution
that
direction.
E
This
is
probably
the
most
heartwarming
office
hours
we've
ever
had.
E
E
All
right,
next,
on
our
agenda,
we
have
configurable
previous
image,
unpacked.
D
Yeah,
so
I
logged
it
again
after
yesterday's
platform
meeting.
Is
it
does
it
suit
the
office
hours
meeting
as
well.
D
It's
the
related
to
pack,
but
the
singer's
code
fees
is
coming
up.
I
thought
it
might
be
worthwhile
to
bring
it
here
as
well.
If
that's
okay,.
F
I
see
okay
yeah,
I
see
a
different
issue,
but
that's
not
what
we're
talking
about
the
one
that's
linked
below
or
description.
F
All
right
I
mean
yeah,
I
think
we
could
definitely,
you
know,
go
from
the
emotional
side
into
the
technical
side
and
start
digging
into
that
a
little
bit
yeah.
What's
up
with
that.
D
D
That's
already
present
with
this
that
what
already
I
wrote
for
the
cli
flag,
so
it's
basically
just
a
flag
description,
but
while
working
on
the
issue,
I
felt
that
not
only
I
but
a
lot
of
people
who
are
familiar
with
buildbacks
also
are
not
exactly
clear
on
what
the
feature
does,
and
I
feel
like
this
has
a
limited
use
case.
So
until
we
document
it,
it's
practically
useless.
So
how
do
I
want
to
go
about
documenting
this
and
if
it
can't
document
it
in
time,
should
we
push
it
back
to
another
release.
F
Interesting,
okay,
I
I
really
like
that
question.
I
I
appreciate
it.
Thankfully,
we
do
have
people
here
that
have
a
little
bit
more
knowledge
about
how
this
flag
interacts
with
the
the
kind
of
the
inner
workings
of
the
the
process.
So
natalie,
if
you
don't
mind
me
calling
you
out
on
how
the
previous
image
works
and
how
that
changes
and
what
sort
of
like
use
cases
you
could
foresee
where
somebody
would
want
to
change
the
previous
image.
E
So
you
know,
let's
say
I
do
my
first
build
and
a
bunch
of
layers
end
up
in
the
app
on
my
second
build.
You
know.
Maybe
not
not.
All
of
those
layers
have
changed
right,
so
I
can
reuse
those
layers
without
having
to
re-export
them.
You
know
to
the
to
the
daemon
or
the
registry,
and
so
what
that
means
is
actually
for.
This
feature
is
let's
say
I
want
to.
E
I
want
to
build
an
image,
but
I
want
it
to
have
a
different
name
from
the
one
that
I
built
before
right
without
the
configurable
previous
image,
the
analyzer
will
just
it's
like
it
flows
through
to
the
analyzer
right.
So
if
you
don't
send
the
analyzer
a
previous
image,
it's
just
going
to
assume
that
the
image
you
want
to
potentially
reuse
layers
from
has
the
same
tag
as
the
one
that
you're
building,
and
that
might
not
always
be
the
case
right.
So
this
is
kind
of
just
giving
that
additional
knob
to
the
end
user.
E
That
I
can
take
advantage
of
you
know
some
sort
of
caching
and
speed
up
my
my
builds
without
being
restrained
to
not
being
able
to
choose
a
new
name.
D
Okay,
but
in
the
discussion
me
and
anthony,
were
discussing
this
with
you,
I
think
that
for
the
analyzer
we
should
hold
back
the
changes,
and
so
we
ended.
I
ended
up
making
changes
only
in
the
creator
phase,
so
does
that
somehow
affect
this.
E
Yeah,
so
the
analyzer
and
I'm
gonna
have
to
double
check
that
I
am
remembering
the
most
recent
iteration
of
things.
I
think
the
analyzer
supports
a
previous
image
flag
as
of
platform
07,
but
pac
doesn't
currently
support
that
platform.
Api
version,
so
this
is
something
we
should
probably
have
another
issue
to
to
make.
These
changes
flow
through
to
the
analyzer
when
pac
supports
o7.
F
Okay,
so
now,
if,
if
I'm
understanding
it
correctly,
the
concern
is
that
we
have
this
previous
image
flag,
which
has
a
very
specific
you
know
set
of
use
cases
but
in
reality,
pac
itself
will
only
support
this
flag
or
feature
if
you're,
using
a
trusted
builder
right
or
a
the
that
workflow
right.
B
F
So
there's
two
questions
I
have
basically
to.
I
guess
maybe
make
a
more
informed
decision.
F
So,
first
off
jawal
did
you
did
you
kind
of
gather
what
the
use
cases
are
and
do
you
think
that
documentation
for
those
use
cases
is
something
that's
more
or
less
achievable?.
D
I'm
still
not
entirely
clear
one
is,
is
the
cache
it
equals
true
option,
not
fulfilling
the
use
case
that
natalie
mentioned
of
not
re-exporting
the
layers,
and
secondly,
I'm
just
not
too
familiar
with
marketing,
fully
understand
how
we're
using
this.
So
I
can't
comment
any
further.
F
I
see
okay,
okay,
so
that's
that's
good!
We
could
keep
working
on
that.
You
know
through
some
iteration.
E
Sorry,
I
was
just
reading
the
issue
again
now
I
remember
okay.
I
know
I
remember.
Actually
this
should
be
possible
to
do
for
previous
platform
api.
It's
just
that
the
analyzer.
E
E
E
The
invocation
of
the
analyzer
will
have
to
change
so
that
you
put
the
previous
image
in
the
right
spot
where
it's
expecting
it.
But
I
think,
if
you're
just
passing
this
through
as
the
first
argument
to
the
analyzer,
you
should
be
okay.
F
F
D
Yeah
it
started
working
on
the
analyzer
first
and
and
the
discussion
that
from
api
0.6
won't
support
this.
Then
it
was
discussed
that
I
should
focus
on
the
creator
for
this
pr
and
leave
the
analyzer
for
now.
F
E
Yeah,
but
when
we
move
to
o7
we
we
should.
We
should
change
the
invocation
so
that
we
get
the
other
benefits
of
telling
the
analyzer
about
the.
E
The
tag
that
we
intend
to
export.
F
Okay,
that
makes
sense,
so
I
think
we
have
two
paths
that
I
want
to
propose.
One
of
them
is
implement
it
for
analyzer,
as
it
can
be
done
today
and
then
work
towards
providing
documentation.
F
I
I
don't
want
to
say,
like
report,
reverting
it,
but
we
could
definitely
gate
it
as
an
experimental
feature,
and
that
way,
it's
more
of
an
advanced
feature
and
we
kind
of
essentially
warn
that
it
only
works
for
the
the
creator
path.
When
a
trusted
builder
occurs,
I
would
much
rather
prefer
the
deformer
the
first
option
and
just
kind
of
try
to
get
it
out
the
door,
and
I
could
work
with
you
draw
to
try
to
reason
about
some
reasonable
documentation
for
that.
F
F
F
I
think,
no
matter
what
it
doesn't
change
too
much
unless
I'm
completely
crazy,
but
typically
life
cycle
changes
are
just
arguments
and
parameters
right.
So
it
seems
like
a
very
minuscule
change
for
an
upgrade
to
say,
delay
the
whole
feature
for
that
upcoming
work.
F
Awesome
I
like
that
plan.
Let's,
let's
see
if
we
can
get
it
done.
E
I
guess
sure
so
I
guess
next
and
last
on
our
agenda.
We
have
an
rfc
that
halil
and
myself
open.
This
is
about.
E
So
I
think
there
were
some
thoughts
that
were
discussed
in
the
platform.
Sync.
F
Yeah,
so
I
guess
I
could
start
with
a
little
bit
and
a
lot
of
it
might
actually
come
from
one
of
the
comments
that
anthony
made
where
it
was
there's
it's
a
vague
mention
that
this
would
be
a
new
executable,
as
opposed
to
being
part
of
the
functionality
of
something
like
a
preparer
phase,
right,
which
I
think
we've
discussed
in
the
past,
but
we
still
don't
have-
and
I
just
wanted
to
make
sure
that
there
was
some
sort
of
clarity
around
that
and
then
maybe
you
know
take
up
that
discussion
as
part
of
this
office
hours.
F
I
I
have
since
replied
to
that
where
ultimately
I
want
to
say
that
it
doesn't
matter
to
to
me
as
a
platform
implementer,
whether
it's
its
own
executable
or
a
function
of
the
preparer,
but
it
has
to
be
an
operation
that
has
no
additional
side
effects
right.
So
if
it's
for,
let's
say
it's
rolled
into
a
preparer
executable,
then
I
need
to
be
able
to
call
that
preparer
with
some
sort
of
flag
or
something
that
tells
it
only
do
the
transformation
and
do
nothing
else
right.
F
And
the
reason
for
that
is
because,
through
some
of
the
workflows
that
we're
talking
about
during
our
sub
team
sync
is
we're
gonna
try
to
potentially
leverage
just
this
processing
in
in
certain
platforms
outside
of
let's
say,
a
very
prescriptive
workflow.
If
that
makes
sense,
so
I
think
I
put
some
of
the
examples
for
like
in
pack
will
want
to
use
this,
be
like,
I
guess,
maybe
I'll
kind
of
throw
another
thing
in
here.
E
So
maybe
it's
worth
calling
this
out
in
the
rfc,
but
my
understanding
whenever
we
talked
about
the
prepare
phase
was
that
it?
Even
if
you
know,
even
when
we
were
saying
oh
prepare,
it
downloads,
build
packs.
You
know
it
like
whatever
okay,
I
forget
all
the
things
we
talked
about,
but
even
at
that
stage
we
said
that
it
should
be
entirely
configured
and
configurable
by
the
platform.
E
G
D
E
F
G
E
There
was
a
branch
of
a
there
was
a
pr
and
then
there
became
a
branch
on
that
pr,
I
don't
know
there
was
never
an
official
prepare
phase
rfc
and
I
think
at
some
point
we
when
we
started
talking
about
utility,
build
packs.
We
said:
there's
a
there's,
a
bunch
of
stuff
that
needs
to
get
settled
before
we
can
come
back
and
discuss,
prepare
with
more
certainty.
F
Cool,
let's
see:
okay
yeah,
I
guess
there
was
another
kind
of
like
just
opinion
that
I
really
want
to
voice,
because
I
felt
like
I've
heard
different
thoughts,
but
again
speaking
from
a
platform
implementer's
perspective
like
it
wouldn't
be
as
valuable
to
me.
If
I
had
this
conversion
utility,
if
I
still
had
to
parse
it
for
very
specific
information
that
may
or
may
not
be
deemed
necessary.
So
some
other
cases
here
would
be
things
like
the
builder
right.
F
E
B
E
B
E
Oh
sorry,
but
so
maybe
it's
worth
also
calling
out
explicitly.
You
know
just
in
a
way
that
rebase,
for
example,
currently
right
it
doesn't
expect
to
be
run
in
the
context
of
a
builder.
You
can
just
run
it
on
your
host
right.
I
think
this
would
sort
of
be
the
same
right.
You
wouldn't
have
to
run
the
preparer
or
whatever
we
want
to
call
it.
E
You
wouldn't
have
to
run
it
in
a
containerized
environment,
at
least
not
now
right
with
what
it's
trying
to
do,
but
one
other
thing
that
I
heard
am
I
correct
that,
like
just
getting
back
a
tamil
file,
isn't
that
helpful
for
you
right,
because
then
you
have
to
parse
the
tamil
file.
E
F
E
G
I
think
that's
what
javier
is
basically
asking
right
like
as
a
platform
like
pack
is
a
platform
like
salesforce
or
kpac
or
whatever
they
can
just
use
this
new
format,
because
it's
tied
to
the
platform
api
right
and
you
don't
have
to
care
what
the
user
wants
and
just
being
a
lot
more
explicit
about
that
was,
I
think,
some
of
the
discussions
that
we
talked
about
in
the
subteam
sync
and
kind
of
just,
I
think,
probably
the
part,
that's
a
little
more
nebulous,
is
like,
as
part
of
the
reverse
domain
changes
to
accommodate
some
of
the
stuff.
G
I
think
like
salesforce's
exports
like
what
happens
if
a
platform
basically
has
tables
like,
does
that
stuff
get
copied
over?
What
does
that
look
like?
I
I
think,
it's
easier
to
potentially
write
schema
stuff
for
things
that
we
care
about
as
part
of
the
bill
packs
project.
But
if
I
have
other
tables
do
I
have
to
go
back
to
the
other
file
as
a
platform.
G
E
Yeah,
let
me
go
back
and
look.
I
think
there
were
some
assumptions
made
that
the
underscore
stuff
had
a
logical
mapping
to
stuff
that
we
had
defined
in
the
01
schema
and
therefore
is
included
in
the
platform
schema.
E
E
F
So
is
the
okay,
that's
one
thing
I
was
going
to
ask
for
actually
is
to
see
like
what
the
mappings
would
look
like,
but
it
seems
like
that's
what
you
already
have
right
now
in
the
how
it
works.
Yeah,
that's
saying!
Okay,
if
I
have
this
0-1
schema
it'll
translate
into
this
o2
schema
and
vice
versa.
Right.
F
E
E
A
G
When
you
said
161
at
the
bottom,
it's
like
mapping
the
tables.
Is
it
worth
in
the
how
it
works
where
javier
was
before
to
show,
I
guess
the
output
of
what
that?
Maybe
I
missed
it.
But,
like
you,
show
examples
of
point
one
and
point
two.
G
E
G
F
G
F
That's
what
I'm
thinking
like
I
felt
like.
We
took
a
step
back
on
this.
What
happens
to
the
the
reverse
domain
stuff?
Where
does
that
go.
G
E
Yeah,
I
mean
I
think
we
were
going
with
the
assumption
that
what
does
a
platform
need
to
care
about
stuff
that
doesn't
relate
to
build
packs
right.
E
G
G
B
E
Correct,
yes,
I
think
I
mean
my
proposal
would
be
that
we
we
just
have
a
separate
table.
That
includes
the
stuff
that
doesn't
relate
to
build
packs
and
we
just
copy
it
exactly
as
it
is.
You
know
I,
whatever,
whatever
the
reverse
domains,
are
that
don't
pertain
to
build
packs.
They
can
just
go
under
that
table.
E
Yeah,
so
my
proposal
would
be
that
we
put
them
in
under
either
directly
as
top
level.
You
know
tables,
or
we
put
them
as
a
child
of
some
table.
That's
like
other
stuff
that
doesn't
relate
to
build
packs.
You
know,
but
like
effectively
retaining
the
structure
that
the
user
that
the
yeah
that
was
provided.
G
Yeah,
I
wonder
if
it's
I
wonder
in
some
chances,
if
it's
better
to
just
have
that
as
a
extra
file,
something
like
as
a
potential
like
if,
if
I'm
like
a
platform
like
I'm
thinking,
got
just
potentially
the
salesforce
case.
G
Maybe
you
don't
want
that
at
the
top
level
in
this
other
file,
because
then
it
gets
intermixed
with
maybe
like,
as
you
update
this
platform
schema
to
account
for
more
build
pack
things.
You
don't
really
want
to
deal
with
other
stuff
kind
of
stepping
on
how
the
platform
wants
to
build
out
that
schema,
but
I
would
potentially
as
the
platform
who
wrote
that
reverse
domain
thing,
or
maybe
I
pull
on
a
schema
from
another
project
or
something
they
have
a
thing,
that's
publicly
available
right.
G
E
Well,
in
that
case,
I
feel
like
you
might
as
well
just
retain
the
original
project
tommel
and
like
use
it
right,
because,
if
you're
keeping
the
same
schema,
your
validator
is
still
going
to
look
for
that
top
level
domain
inside
some
file.
You
know
what
do
you
care
if
that
file
has
extra
stuff?
That's
going
to
be
totally
ignored
by
your
validator.
F
I
think
this
is
where
again,
I
feel
like
very
conflicted.
If
I'm
going
to
have
to
look
for
a
very
specific
format
or
or
know
the
schema
version
of
the
raw,
the
initial
project
tumble,
then
I'm
seeing
very
little
value
in
in
this
part
of
it,
because
I'm
gonna
have
to
have
a
parser
for
that
initial
format
anyway,
right,
so
I'm
gonna
have
to
have
a
parser
for
a
one.
I'm
gonna
have
to
have
a
parser
402.
E
D
E
E
So
you
you,
you
have
to
have
domain
specific,
something
that
has
domain
specific
knowledge
introspecting
these
files
right,
I
guess
just
the
question
is:
do
you
put
it
at
the
top
level
or
do
you
put
it
nested
under
something
or
you
put
it
in
a
dedicated
file,
but
like
our
build
packs,
parser
is
never
going
to
be
able
to
handle
that
stuff.
F
F
The
new
the
separate
file
idea
right,
that's
that
that
makes
a
little
bit
of
sense
to
me
or
putting
it
in
a
separate
location
right
that
makes
sense
to
me
I'm
trying
to
like
maybe
get
a
more
concrete
example,
and
I
think
that's
maybe
where,
where
a
lot
of
our
communication
is
is
out
of
sync,
it's
like
we,
we
probably
have
to
like
actually
go
through
the
practice
of
like
how
does
this
file
gonna
translate
over
to
this,
and
once
we
do
that,
I
think
it'll
say:
okay,
like
this
is
gonna,
be
super
challenging
or
you
know,
hopefully
come
up
with
some
solutions
to
some
of
those
problems.
F
E
I'll
just
I'll
just
say
personally
that
the
idea
of
having
a
separate
file
per
domain
appeals
to
me
because
then
you're
kind
of
like
let's
say
I
have
a
you
know,
I
don't
know
you
have
like
a
heroku
specific
thing
right.
That's
like
just
looking
for
the
data
that
pertains
to
heroku.
You
then
don't
have
to
bake
logic
into
that
validator
or
whatever
that
ignores
all
the
other
stuff
right.
E
G
Though,
as
well
right
like
because
then
you
could
have
validators
or
potentially
you
can
imagine
a
path
where
some
part
of
repair
phase,
that
the
platform
controls
is
able
to
then
even
pull
that
stuff
down
and
is
able
to
run
some
of
those
things
after
they
get
split
or
something
I
don't
know,
hypothetical
repair
phase
that's
coming
one
day,
but
yeah
I
mean
having
it
split,
sounds
great
too.
I
just
didn't
want
to
add
additional
complexity
to
the
implementation,
necessarily.
F
Do
we
have
the
domains
defined
or
merged
in
like
how
they
reverse
domain
schema
works.
G
It's
part
of
project
descriptor
o2,
just
like
we're
assuming
and.
G
G
I
wrote
a
section
on
this,
I'm
pretty
confident
on
this.
I
think
one
of
the
the
downsides
of
the
implementation
we
went
with,
and
maybe
we
wanted
to
maybe
this
is
why
we're
talking
about
this
now,
is
that
I
think
if
you
want
to
go
down
that
path,
what
would
make
it
much
simpler
for
a
live
cycle
to
implement
this
would
be
actually
quoting
the
domain.
G
Because
one
of
the
complications
right
now
is
like
you
know
that
io
bill
packs
is
the
domain
right.
But
how
do
you
actually
know
that
if
you're
not
if
it's
not
like
written
somewhere
right
like
how
do
I
know
it's
like
com.google
versus
com.google.com
or
whatever
right
like
as
the
thing
you
actually
want
to
split
on.
F
Yeah,
so
the
term
domain
is
very
loosely
defined
right
or
not
defined
at
all.
Actually,
google
foo,
like
is
foo
a
table
of
options,
or
is
it
the
domain
itself
so
like?
Basically,
every
table
of
options
becomes
a
domain
by
that
definition.
G
If
you
want
like,
if
you
wanted
it
to
work
that
way,
I
think
right,
I
I
think
one
of
the
assumptions
right
now
is
like
we
basically
do
domains
based
off
of
like
the
two
like
just
one
dot.
Basically
right,
I
think
that's.
F
E
E
Because
of
what
you
know,
I
said
about
your
validator,
or
whatever
is,
is
still
gonna
have
to
ignore
everything
that
doesn't
pertain
to
its
domain.
So
actually
maybe
this
will
clarify
things
if,
if
let's
say
we
had
like
an
io
dot,
you
know
whatever
domain
table.
E
G
I
think
in
the
like,
if
I'm
thinking
for
the
non-I
o
bill
packs
case,
I
wonder
I
don't
know.
I
like
it's
hard
to
say,
because
you
probably
have
validators
that
are
built
against
the
user
implementation
right
or
by
using
implants.
G
I
mean
like
how
the
user
writes
it
right,
like
as
a
end
consumer,
like
I'm
running
a
cli,
valid
data
to
a
thing
that
a
user
can
run
locally
against,
I
mean
even
for
io,
build
packs
right,
like
you
would
validate
like
the
whole
table
and
not
just
not
just
like
you
would
not
expect
it
to
be
stripped
yeah,
but
I
could
see
why
you
would
want
to
strip
it
if
that
makes
sense.
E
I
just
without
without
stripping
it.
You
know,
if
we're
just
gonna
copy
the
data
as
it
is
into
a
new
file
and
the
validator
is
gonna
have
to
ignore
stuff
anyway,
that
it
doesn't
care
about.
I
I
personally
don't
see
the
the
benefit
of
you
know
why
you
just
use
the
original
project
tamil,
because
it's
the
same,
it's
the
same,
like
series
of
steps.
You're
gonna
have
to
do
as
a
validator,
but
at
the
same
time,
if
we
wanna
make
a
nice
clean
separation
between
build
pack,
stuff
and
non-build
pack
stuff
like
we
could.
E
I've
been
taking
notes.
I
can,
I
can
add
some
comments
to
the
rfc.
If
you
want
to
think
on
it
a
little
more
and
weigh
in
what
you'd
prefer.
G
E
F
G
There's
probably
a
whole
world
which
is
maybe
out
of
scope.
This
received,
like
that
whole
spleen
domain,
thing's,
actually
really
interesting
because,
like
you
potentially
could
imagine
a
registry
that
that
maps
do
potentially
too
it's
just
like
you
see
like
com,
dot,
foo
or
whatever
dot
toml,
and
that
potential
absolute
value
that
people
are
able
to
then
pull
down
and
validate
against.
F
Are
you
thinking
like
xml
schemas,
where
you
could
declare
the.
B
F
Cool
all
right,
yeah,
so
looking
forward
to
seeing
a
little
bit
more
more
here
but
interesting
I'll
go
back
and
I'll
have
to
rethink
through
some
of
my
stuff
as
well
appreciate
it.
G
Thanks
for
writing
this
and
everything
to
you-
and
I
mean
yeah.