►
From YouTube: CNB Core Team Sync: 2021-11-03
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
B
That's
fine.
They
don't
need
to
see
five
minutes
of
people
just
sitting
around
cool.
Thank
you
for
doing
that.
Javier.
B
B
Let's
start
with
outstanding
spec
prs
continuing
this
trend
of
a
lot
of
a
decent
amount
of
spec
activities.
So
that's
cool.
C
B
Share
my
screen
awesome,
so,
okay,
so
for
these
draft
things
we
still
need
to
open
up
a
pr
into
the
rfc's
repo
to
put
or
close,
I
think
the
asset
package
rfc
before
I
guess
closing
these
drafts
from,
I
guess:
ben
slash,
daniel.
B
For
release,
I
went
ahead
and
split
out
the
thing
into
contributing
md
that
emily
suggested
and
then
kind
of
just
waiting
on
approvals
from
ben
stephen.
B
I
assume
emily
approves
her
own
pr,
but
yeah
you
don't
know
we're
getting
around
the.
B
Yeah,
but
I
don't
know
I
I
don't
stand
on
anything
and
here's
super
controversial.
I
think
one
of
the
suggestions
I
had
at
one
point
was
just
to
help
shepherd
some
of
the
spec
releases
along
to
appoint
police
managers,
but
I
don't
know
if
we
need
to
necessarily
do
that
and
we
can
come
back
that
at
a
later
point.
I
think
emily
was
mostly
documenting
what
she
was
doing
today
or
before
she
left.
B
So
I'm
happy
to
just
kind
of
take
that
as
is,
and
then
we
can
iterate
on
it
as
we
want
so
ben
and
steven
if
you
want
to
approve
or
have
any
outstanding
feedback.
I
feel
like
this
has
been
open
for
since
right
before
she
left
so
yeah
a
little
while.
B
I
feel
like
kind
of
the,
how
are
you
feeling
about
this?
One
stephen.
B
E
C
E
B
Because
I
don't
think
there's
any
unless
you
have
like
stuff,
you
want
changed
or
something
if
you
are
plus
one
and
there
isn't
any
other
changes.
Do
you
want
to
merge
that?
And
instead
of
kind
of
having
to
wait
a
cycle
for
it
to
be
next
week,
it.
E
B
You
should
be
able
to
just
hit
the
merge
button
and
the
only
thing
to
check
which
it
is.
I
already
did
it.
It
should
be
in
this
kind
of
point
three
branch
and
then
kind
of
I
think
we
have
milestones
for
all
that
stuff,
but
I
can
make
sure
all
the
other
stuff
that
is
not
click.
The
button
is
set
up,
so
you
should
just
be
able
to
hit
the
button
once
you
review.
C
A
So
I
I
feel
like
this
one's
pretty
much
ready
as
well.
I
did
tag
natalie
as
a
reviewer,
since
it
has
to
do
with
a
process
that
they're
currently
doing
that
might
have
some
impact
to
it,
but
otherwise
I
think
it's
pretty
straightforward.
A
Yes-
and
we
did
incorporate
that,
as
you
can
see
there
on
line
82.,
we
basically
use
the
same
phrasing
that
we
used
for
build
packages.
A
B
And
then
you
were
fine
with
that.
I.
C
B
B
Cool
yeah,
I
think
that
all
looks
good
to
me.
B
B
I
think
with
ben.
In
theory,
we
have
enough,
if
you
vote
in
that's
how
the
rules
work
or
do
we
need
without
emily.
We
need
joe
as
well.
B
Yeah,
I
can
paint
joe
about
it
or
we
can
paint
joan
leadership
as
well.
That's
a
fall
fashion
item
but
I
think,
with
the
I
think
javier
said
he's
like
past
halfway,
so
it
would
be
nice
to
kind
of
get
this
in
place,
so
he
can
actually
do
the
non-spec
work.
B
Well,
did
you
want
to
talk
about
the
draft
build
image
stuff,
javier.
A
A
I
think
there's
still
some
confusion
on
that,
but
I
just
want
to
make
sure
that
it
isn't
something
that
is,
you
know,
embedded
or
baked
into
the
build
image
right.
Those
cnb
target
variables,
but
the
rsc
also
says
that
they're
not
passed
through
the
platform
environment
variables-
and
I
guess
maybe
just
some
clarification-
how
those
environment
variables
are
derived
and
who's
the
one
that
actually
sets
them
sets.
E
Their
balance,
it's
an
identifier
that
is
provided
dynamically
at
build
time.
That's
in
run
image
metadata
that
lets
the
build
pack
know
this
is
a
a
it's
optional,
but
let's
the
build
pack
know
this
is
a
special
kind
of
run
image
right.
It
looks
like
this.
Like
an
example
would
be
you
have
a
version
of
ubuntu
bionic
that
you
know
has
some
special
modifications
to
it.
You
want
to
indicate
to
build
packs
that
it
is
this
particular
revision
of
this
image
right.
So
it's
not
baked
into
the
build
image.
E
It
comes
from
the
front
image
and
it's
not
provided
through
the
platform
directory.
That's
all
that
was
the
comment,
because
cnb
underscore
environment
variables
are
always
set
directly
in
the
environment
because
they
don't
have
the
same
security
related
issue:
that
user
provided
environment
variables
that
come
into
the
platform
directory
do.
A
So,
but
practically
from
a
practical
standpoint,
it
would
be
the
life
cycle
that
retrieves
that
information
from
the
run
image
selected.
Yes,
okay,
that's
that's
it!
So
then
it
wouldn't
be
part
of
this
rfc.
So
this
rc
should
or
sorry
this
pr
should
be
good
and
should
not
be
a
draft.
A
A
C
C
B
Too
terrible
cool
yeah,
I
will
try
to
I'll
make
sure
to
get
to
this
before
I
head
out
as
well,
so
you're
not
blocked
by
me.
B
Well,
I
can
also
do
that
today.
B
Is
there
anything
you
want
to
talk
about
for
this
spec
vr
besides,
please
take
a
look.
C
I
would
just
say
that
it's
it's
sort
of
at
least
the
way
I
wrote
it.
It's
dependent
on
there
being
stuff
in
the
build
pack
spec
that
describes
us
bomb
and
I'm
still
working
on
that
part.
So
maybe
take
those
two
together.
I
hope
to
get
the
other
pr
up.
C
B
B
Yeah,
that's
what
I
was
saying
that
I
I
need
to
go
ahead
and
well.
I
guess
it
does
not
be
me,
but
I
was
planning
on
going
ahead
and
doing
that.
I
guess
in
accordance
to
the
release
stuff,
that
emma
loved
us.
B
Okay,
cool.
B
Anything
that
is
coming
out
are
we
closing
this
builder
0.1
stuff.
I
feel
like
there
was
discussion
from
last
week
about
builders.
Not
we
were
not
going
to
release
a
builder
extension.
A
B
Actually
cut
it
yeah,
it
has
been
released
out,
but
are
we
moving
it?
We're
moving
into
platform
was
that
the
plan.
A
C
A
A
It
easy
no,
but
we
can
try.
We
could.
B
And
then,
if
we're
not
doing
that,
I
will
then
just
close
builder
one
if
that
is
cool
with
the
rest
of
the
core
team.
Here.
B
Cool,
so
I
think
this
is
still
blocked
right
from
the
spike
work
support.
Docker
files,
I
think,
is
moving
along
and
joe
has
started,
work
on
basically
just
figuring
out
how
to
actually
spec
all
this
stuff,
which
is
here.
B
Supported
bill
packs,
I
think
joe,
was
making
some
updates
this
and
I'd
not
check
if
he
ready
kind
of
cool
yeah.
So
it
looks
like
they
see.
B
Sam
and
I
probably
just
need
to
re-review
this
and
then
we
should
be
good
there.
B
This
walk
down
this
getting
in,
doesn't
look
like
there's
any
changes
to
this
so
still
waiting
on
some
work.
There
there's
a
bunch
discussion
last
week
on
this
on
friday.
C
B
And
then
this
is
kind
of
anthony's
rfc
on
adding
the
s-bomb
to
the
run
image.
B
C
E
B
There's
something
from
that
that
you're
talking
about
coming
scope
on
that.
What
that
you're
thinking
about
adding
in
but
it
didn't
actually
wasn't
originally
in
the
rfc-
is
that
still
true.
E
I
think
this
this
is
that
thing
that
we,
the
original
rfc
cut
scope,
is
saying
specifying,
where
the
base
image
s
bomb,
how
that
should
be
specified
in
the
resulting
in
the
run
image
and
thus
and
the
resulting
images
that
carries
forward,
and
so
I
think
it
also
didn't
clarify.
Like
you
know,
when
you
do
the
rebase,
you
move
the
run
image
s-bomb
the
from
the
new
run
image
over
the
old
one
and
not
just
move
the
layers
over
right.
E
So
that's
a
good
thing
to
clarify,
and
so
this
this
covers
that
gap
that
wasn't
specified
in
the
original
version,
but
is
inferable,
and
it
doesn't
really
because
you
can
always
you
know,
whatever
you
put
in
the
run
image
ends
up
in
the
final
image
right.
You
know
you
can
use
whatever
format
for
or
whatever
label
for
identifying
that
you
would
like
to
this
just
standardizes.
It.
E
So
it'd
be
good
to
get
this
through.
Just
clarify
some
of
that
stuff.
B
Cool
anything
else,
just
the
run
image
stuff.
E
Is
there
I
know,
there's
been
a
lot
of
talk
about
project
descriptor
in
general,
like
what
the
best
path
forward
for
project
descriptor
is
that's
kind
of
come
up
again.
You
know
from
like
more
existential,
you
know
in
a
more
existential
sense
with
you
know,
is
a
project
descriptor.
We
have
now
too
widely
scoped
and
not
enough
of
an
advertisement
for
the
project.
I
don't
know
if
joe's
talked
to
parents
about
this
there's
some
conversations
in
slack.
E
That
might
be
a
good
topic
for
tomorrow.
Also
because
I
think
that's
you
know
imminent.
B
Yeah,
I
saw
some
stuff
javier
matching
some
stuff
on
friday
and
when
we
met
but
I've
not
synced
up
with
joe,
I
think
tommy
and
I
are
supposed
to
get
together
to
deal
with
some
stuff.
There
yeah,
I
mostly
just
saw
notes
as
well
in
the
office
hours.
I
think.
E
It
might
be
the
type
of
thing
where,
if
we
have
ideas,
we
could
run
them
by
kind
of
a
larger
group
of
people
and
see
how
the
community
feels
about
it.
So
I
was
thinking
about
it
for
working
group
like
see
how
people
feel
by
project
humble,
more
generic
thing
versus
something.
That's
more
called.
You
know,
pac-tunnel
whatever
you
want
to
call
it.
It's
more
project,
specific,
get
some
feedback,
but
whatever
you
think,
I'm
not
it's
just
an
idea.
A
Yeah,
I
think,
if
I
recall
where,
in
my
mind,
we
are
with
that
is
the
there's
a
converter
rfc,
that
we
want
to
definitely
take
advantage
of.
I
think,
from
my
side,
it's
helping
with
some
of
the
interface
on
how
the
platform's
gonna
interact
with
it
and
what
it
expects
back.
A
But
how
that
ties
to
more
or
less
the
separation
of
the
project
descriptor
and
maybe
rebranding
it
to
be
more
user-centric.
And
we
talked
about
a
little
bit
of
the
idea
of
application.
Api.
E
I'm
not
sorry,
I
don't
want
to
cut
you
off,
but
I'm
not
actually
talking
about
the
interface
for
how
you
consume
the
descriptor
or
the
converter
process,
or
how
we
version
apis.
I
think
that's.
That's
one
whole
unit
of
stuff
to
talk
about
there's
like
a
little
bit
of
a
different
conversation,
that's
like
is,
is
more
of
a
design
question
about
project
tamil
being
seeming
like
it's
scoped,
to
try
to
solve
a
problem.
That's
kind
of
far
outside
of
the
project.
E
There's
some
there's
some
threads
in
slack
that
are
kind
of
talking
about
that
idea.
Like
you
know,
do
we
need
to
project
tom?
Do
we
need
that
second
version
of
the
application
descriptor
given
kind
of
the
usage
and
feedback
and
how
platforms
have
adopted
the
current
version?
And
you
know
how
we're
feeling
at
this
point,
sort
of
a
separate
conversation
for
what
the
api
should
look
like
and
what
it
would
look
like
to
make
changes
to
it.
If
that
makes
sense
like
should
we
do
something.
A
Yeah,
that's
kind
of
what
I
was
getting
to
where
a
lot
of
the
conversation
we've
had
thus
far
resolved
was
the
back
end
side
of
things
but
yeah
for
the
front
end.
I
believe
the
next
steps
where
terence
and
I
we're
gonna
propose
something
that
might
be
radically
different,
that's
more
tailored
to
the
app
developer
right
and
keeping
it
in
that
sort
of
vein
at
that
layer.
If
that
makes
sense,
sorry,
I
shouldn't
cut.
E
C
B
Do
we
feel
like
that's
something
we're
ready
to
talk
about
like?
Would
it
be
good
to
just
start
talking
about,
or
do
you
want
to
come
to
table
like
a
strong
man
proposal?
First.
A
I
think
if
we
have
a
large
enough
audience,
it
would
be
interesting
to
get
different
people's
takes
before
we
invest
too
much
time
in
bringing
in
this,
like
maybe
a
radical
idea
that
people
may
not
be
fond
of
to
begin
with,
but
yeah
for
me,
it
sounded
like
we
were
already
aligning
towards
it.
So
again,
I
think
it's
it's
worth
it.
B
Well,
I
I
mean
I
am
happy
either
way.
I
just
know:
config
files
seem
to
be
the
ultimate
technical
bike
shed,
so
if
it
doesn't
get
rained
in
it
can
be,
it
can
kind
of
spiral
out
I
feel
like,
but
the
do
you
want
to
lead
or
do
that
stephen
or
javier.
Is
that
a
thing
you
want
to
talk
about
tomorrow
or.
E
Sure
I
mean
if
people
feel
like
it's
a
good
time
to
talk
about
it,
see
what
people
think
I
had
one
more
for
tomorrow.
Also
charles
is
working
through.
I
think
he's
on
pto
for
a
couple
weeks,
but
he's
working
through
a
proof
of
concept
of
docker
file
support,
and
I
think
it's
right
in
the
middle
of
two
solutions.
I
think
he's
he's
working
on
a
version
of
it
that
is
probably
not
usable
locally
in
pack
and
also
not
usable
in
a
environment
like
tecton,
right
and
the
way
I'd
imagine
this
is.
E
Maybe
there
are
two
implementations:
one
provide
a
purely
user
space,
one
provided
by
the
lifecycle
and
a
purely
docker
daemon
or
podman
compatible,
so
one
provided
by
pac
as
a
place
to
start,
and
we,
I
don't
think
charles-
is
going
to
be
there
tomorrow,
but
we
could
talk
about
those
two
options,
some
of
the
semantics
and
then
see
if
anybody
disagrees
that
that's
not
a
good
path
forward.
So
I
put
the
support
dockerfiles
rfc
on
there
again,
which
is
still
not
merged.
We
should
figure
that
out
too.
B
B
B
F
Cool,
can
we
just
yeah?
Can
we
just
talk
about
the
two
paths?
Again,
you
know,
I
believe,
we're
all
in
the
group
at
one
point
in
time,
just
to
make
sure
this
conversation
is
moving
along.
We
said
you
know,
for
the
proof
of
concept,
we're
just
trying
to
get
the
fastest
thing
out,
which
might
you
know
be
something
in
the
life
cycle
just
to
just
to
see
that
it
even
works
and
sets
out
any
any
possible
forks
in
the
world
right,
but
ultimately,
maybe
they
should
fall
on
the
platform
side
right.
E
I
I
think
my
concern
is
that
charles
is
looking
for
a
path
forward
and
he's
using
some
tools
that
mix
user
space
and
privileged
operations
like
like
you
know
they
require
user
name
spacing
inside
of
the
container,
and
so
it
it
kind
of
looks
like
stuff
on
both
sides.
It's
okay!
If
he
wants
to
kind
of
figure
out
some
of
the
hard
problems
in
that
implementation,
make
it
working
and
get
that
working
right.
But
I
worry
that
he's
going
to
have
to
solve
a
lot
of
hard
problems
that
you
wouldn't
have
to
solve.
E
C
B
E
E
There
I
put
an
issue:
this
is
just
informative.
I
put
in
an
issue
into
life
cycle
so
for
some
context
in
sam's
ass
bomb
rfc,
we
said
we're
not
going
to
pick
winners
for
s-bomb,
we'll
just
support
a
whole
bunch
of
different
s-pawn
media
types
I
put
in
a
and
also
we
said
that
new
new
media
types
don't
require
an
rfc,
we'll
just
add
them
to
the
media
type
list.
E
So
I
put
in
an
issue
on
lifecycle
to
add
sift
s
bomb,
so
originally
it
looked
like
cyclone
dxs
bomb
would
be
enough
to
do
vulnerability
matching,
but
the
big
tool,
like
the
big
open
source
security
scanning
tool
that
does
s-bomb
matching,
is
sift
and
gripe
and
gripe
doesn't
parse
cyclone
dxs
bomb.
Yet
it's
going
to
be
a
while
before
they
do
that,
and
so
we
could
add
support
for
sift
sif's.
E
E
The
it
requires
adding
a
media
type
but
an
rfc
explicitly
says
that
spec
changes
or
it
says
that,
if
we're
gonna
for
just
adding
additional
s-bah
media
types,
those
can
go
straight
to
spec
constraint.
To
so.
E
E
B
I
guess
I
can
look
at
it.
You
said
some
life
cycle,
the
issue
you
open
yep.
B
I
think
it's
up
to
people
here
on
the
core
team.
If
you
want
to
nix
the
other
meeting
and
just
continue
on
spectrum
organization,.
A
Yeah,
I
could
briefly
touch
on
this.
I
think
when
we
were
talking
about
spec
refactor.
At
some
point,
we
talked
about
alternatives
to
the
current
branching
strategy
and
how
we're
maintaining
the
the
spec
as
a
as
a
whole
and
the
rce
that
I
have
right
now
in
draft-
is
to
basically
create
directories
for
different
schemas,
there's
some
prior
art
behind
that,
and
I
think
it
brings
a
lot
of
benefit.
A
But
I
did
hear
that
at
a
meeting
where
I
was
absent,
there
was
a
discussion
of
potentially
breaking
up
the
spec
repo
into
multiple
repositories
similar
to
the
oci
spec.
I
I'm
curious
to
get
a
feeler
for
I
guess
which
one
we
want
to
pursue
in
the
rfc.
I
don't
really
think
I
have
a
strong
opinion
either
way,
but
I
could
at
least
formulate
the
rfc
one
way
or
the
other.
B
E
I
think
that
we
want
to
version
it
as
files
inside
of
one
monterey
boat
is
a
signal
that
we
really
want
to,
and
also
that
we've
asked
people
to
split
prs
into
multiple
pr's
that
are
separate
into
the
same
repo
as
a
signal
that
maybe
those
things
should
be
two
repos
oci
also
does
this:
they
have
a
separate
image,
spec
and
distributions
back
and
whatever.
So
it
follows
accepted
conventions.
F
All
right,
so
you
know
I
remember
a
prior
conversation
about
this
and
we
said
you
know
with
with
the
git
approach.
The
concern
is
when
you
have
to
make
a
pr
that
touches
multiple.
You
know
different
components
like
let's
say
these
are
separate
things
and,
let's
say
we're
sub-moduling.
It
are
we
concerned
now
that
it's
going
to
be
difficult
for
an
outside
contributor
still
to
like
contribute
to
something
that
touches.
You
know,
let's
say
platform,
and
you
know
another
component.
A
We
nested
the
nested
directory
structure
would
ease
that
actually
right,
because
we
would
have
the
way
it's
proposed
right
now
we
would
have
a
development
version,
and
so,
therefore,
you
could
create
a
pr
for
both
build
pack,
api
and
platform
api,
for
instance,
in
one
pr.
A
So
in
that
regard,
that
is
the
benefit
that
I
see
in
putting
it
all
in
one,
but
again
no
real,
strong
opinions.
A
A
Maybe,
as
part
of
the
migration
strategy
would
be
that
the
current
spec
repo
stays,
as
is
with
the
readme
saying
that
hey
these
are
all
the
new
repos
and
archived.
F
B
Already
today,
we
ship
out
like
when
we
release
a,
I
think
good
example.
This
is
like
we
release
platform
07,
but
we
did
not
release
like
build
paco7
with
it,
even
though
I
think
historically,
since
we've
been
making
changes
to
both
of
those
specs
kind
of
during
the
course
of
the
project,
so
we
would
still
cut
a
release
for
that.
The
only
kind
difference
is
if
we
do.
The
multiple
repo
thing
like
steven
said
those
kind
of
tags
and
other
things
would
be
in
different
places.
Now.
B
I
feel
like
the
big
thing
I
want
to
see.
That's
a
bit,
I
think,
tangential
to
the
separate
or
one
repos.
I
would
like
to
see
the
spec
broken
up
into
multiple
files
for
any
individual
spec
so,
like
I
would
like
to
see
like
if
we
use
a
directory,
for
instance,
for
build
pack
that
build
pack
can
have
multiple
files.
B
I
think
we're
starting
to
see
kind
of
that
need
with
the
kind
of
support.rt,
like
we've,
probably
won
this
for
a
while,
but
I
feel
like
that
particular
one
where,
like
when
steve,
and
I
had
kind
of
that
discussion
like
yeah
a
lot
of
stuff-
should
belong
in
the
buildpack
api,
but
I
don't
know
if
it
makes
sense
to
just
continue
to
jam
it
into
buildback
md,
and
so
I
know
that's
like
one
of
the
things
that
I
would
like
to
see
out
of
this.
B
And
so,
instead
of
like
a
just
bill
pack
md,
you
just
have
like
a
bill
pack
folder.
If
it
was
one
repo,
if
it's
separate
repos,
I
guess
you
just
have
different
files
in
that
particular
repo.
A
B
If
they're,
if
we
have
this
back
repo
link
out
to
all
the
different
repos,
does
that
help
enough
anthony
or
do
you
feel
like?
And
I
guess
I'm
picking
on
you
because
you
work
with
the
project
but
don't
have
to
live
with
all
this
stuff.
I
guess
all
the
time
potentially
but.
F
No,
that's
a
fair
call
and
and
completely
no,
that
makes
sense.
I'm
you
know,
I'm
always
just
thinking
pragmatically
and
to
me
you
know
if
you
release
these
independently
and
you
can
contribute
in
the
way
that
was
just
explained
yeah.
I
see
no
problem
with
multiple
repos.
C
B
B
C
B
D
Yeah,
like
I,
don't
love
breaking
it
into
a
bunch
of
different
repos.
Personally,
I
think
keeping
them
close
and
having
a
complex
system
inside
is
better
simply
because
we
haven't
successfully
made
truly
decoupled
specs.
I
don't
think
we
even
want
to
right,
which
means
that,
having
the
ability
to
sort
of
flip
back
and
forth
or
having
a
co-located
ver,
you
know,
representation
of
them
feels
good.
D
Now,
like
I'm
open
to
an
argument
that
says
actually
having
a
bunch
of
different
repos,
is
fine,
because
the
way
people
shouldn't
be
looking
in
repositories
where
we
edit
them,
but
they're
that's
a
source
for
like
generating
into
web
pages
right
just
hugo
the
whole
thing
they
sit
right
next
to
one
another,
complete
with
version
numbers
in
a
table
and
stuff
like
that.
But.
D
We
have
enough,
I,
I
think,
there's
also
a
point
that,
like
we
have
enough
problem
trying
to
get
issues
opened
into
the
right
repo
right
now,
right
like
if
you
wanna,
if
you
wanna,
open
an
issue
about
something
in
cloud-native,
build
packs,
you
have
to
kind
of
have
an
understanding
of
what's
going
on
like
do
you
open
it
against
the
life
cycle?
Do
you
open
it
against
pacquiao,
against
whatever
and
like
now
splitting
out,
spec
changes
feels
like
overcome.
E
D
Do
you
think
lockstep
like
like
I
I'm
interested
that
you
chose
that
those
words
because
I
don't
think
of
it
that
way,
right
like
I
think
they
are
related
and
they
build
on
top
of
one
or
one
another
and
they
leverage
features
in
one
another.
But
I
don't
think
like.
I
think
the
fact
that
we've
had
to
do
platform
and
build
pack
api
changes
every
time
is
an
anti-pattern,
whether
like
sort
of
orthogonal
to
whether
or
not
it's
in
the
same
repo.
E
I
mean
you're
saying
that
it's
convenient
if
they're
in
the
same
repo,
because
you
can
link
between
the
two
specs
right
at
the
same,
commit
right.
So
that
implies
that
the
things
you're
linking
between
those
there's
a
relation
between
when
you
click
on
a
link
in
one
spec
and
you
end
up
on
a
you-
know
a
particular
revision
of
the
other
spec
that
there
is
isn't.
D
Right
like,
I,
don't
think
it
necessarily
means
you
want
to
be
able
to
link
between
two
different
files
on
the
same
commit,
but
I
do
think
you
want
to
be
able
to
say
that,
like
the
distribution,
spec
does
actually
leverage
a
particular
feature
with
a
particular
heading
in
the
name,
whatever
spec
it
needs
to
be
build
pack
spec
or
something
like
that.
Right.
E
But
I
think
the
links
we
have
right
now
do
link
on
the
same
commit
and
if
you
wanted
to
link
to
different
commits
you
use
a
fully
qualified
uri
to
a
different
commit
of
that
happens
to
be
in
the
same
repo,
and
at
that
point,
isn't
it.
You
know
why
not
just
have
them
be
in
separate
repos
instead
of
one
parsing
of
you
know,
one
sit
down
parse
of
the
specification
to
understand
what's
happening
requiring
you
to
you
know,
jump
through
multiple
revisions
of
the
repository
that
feels.
Like
you
know,
it's
confusing.
D
I
don't
see
splitting
it
into
multiple
repositories
as
a
significant
downside,
I
think
process-wise.
I
think
it's
actually
going
to
be
a
lot
heavier
than
it
is
today,
but
I
also
don't
I
don't
observe
that
there's
a
huge
amount
of
advantage
to
it
either
like
the
work
that
we're
going
to
do
in
the
expense
we'll
pay
like
a
year
from
now
we'll
have
paid
a
year
from
now.
I
don't
think
we'll
have
been
worth
the
effort
that
we
put
into
it.
E
I
think
there's
a
bunch
of
effort
involved
in
keeping
many
revisions
of
each
specification
tracked
into
a
repo
at
every
commit
right
like
that.
That
feels
very
which
I
believe
is
the
alternative.
That's
being
proposed
right,
like
we're,
not
saying
keep
it
the
way
it
is
or
split
into
multiple
repositories,
multiple
repos
or
copy
the
file,
and
recommit
that
back
into
the
thing
every
when.
C
A
C
D
D
If
the
pain
is
referring
to
older
versions
of
them,
then
like
let's
render
proper
documentation,
let's
not
use
git
as
the
way
it's
the
place
that
we
host
this
documentation,
like,
I
don't
have
a
problem
if
we
want
to
have
like
a
jekyll
repo
or
like
a
jekyll
project
that
has
50
pages
in
it,
but
I
think
that's
different
than
like
this
is
friggin
bosch
all
over
again
right
for
those
of
you
from
the
cf
world.
This
is
a
mistake.
A
D
Practically,
do
we
see
that,
like
we,
we
went
in
today
and
moved
something
from
master,
sorry
maine
to
to
the
distribution
zero,
three
or
whatever
it
was
like.
Literally,
we
changed
a
thing
in
a
get
a
github
ui
and
no
one
did
anything
else.
I
I
did.
A
D
Like
the
whole
point
was
if
a
pr
goes
into
change,
just
the
distribution,
spec
there's
exactly
one
file,
that's
a
problem,
so
if
you
rebase
whatever
that
change
is
out
of
main
and
on
and
like,
and
no
other
files
have
changed,
like
that's
the
key
here
on
to
another
one
of
those
branches,
it
doesn't
show
as
this
huge
massive
delta,
because
only
one
change
has
happened.
There's
only
one
file,
there
could
be
a
conflict
in
and
it's
conflicts
that
absolutely
have
to
be
resolved.
A
A
If
an
individual
right
creates
a
pr
off
of
main,
and
then
we
want
to
re-point
the
branch
to
put
it
to
distribution
of
three,
it
tries
to
take
all
of
main
all
of
the
stuff.
That's
been
changed
in
main
into
the
distribution
of
three
and
that's
where
his
pr
now
encompasses
all
the
files
outside
of
just
distribution,
o3.
D
So
if
you
did
this
with
a
rebase,
if
you
needed
to
get
a
pr
off
of
main
and
move
it
onto
one
of
these
branches-
and
you
did
a
git
rebase
to
to
make
that
happen,
the
delta.
The
thing
that
you're
re-basing
is
the
addition
of
10
lines
to
one
file.
It
does
not
bring
a
thousand
files
along
with
unless
those
thousand
files
have
been
changed
as
part
of
the
pr.
In
the
first
place,.