►
Description
00:00 Intro
02:06 Implications of Cartographer as an umbrella project
The purpose of this meeting is to discuss architecture-changing ideas (in the form of RFCs) and provide in-depth support to the community of Cartographer contributors.
You can continue the conversation by adding comments to the RFCs PR: https://github.com/vmware-tanzu/cartographer/labels/rfc
Agenda: https://docs.google.com/document/d/1ImIh7qBrOLOvGMCzY6AURhE-a68IE9_EbCf0g5s18vc/edit?usp=sharing
A
Hello
and
welcome
to
the
cryptographer
office
hours.
This
is
a
special
session
dedicated
to
the
discussion
around
rfc,
17
or
best
known
as
convention
service
rfc
for
folks
out
there
we
have
here
in
the
call.
Besides
the
maintainers
team,
we
have
some
vmware
colleagues
from
product
management,
engineering
management
and
tech
leadership
who
also
support
the
cryptographer
project
on
its
corresponding
commercial,
offering
for
the
for
this
session,
we
will
use
the
same
document
as
usual.
The
same
agenda.
A
Let
me
share
my
screen.
I
I
put
there
a
couple
of
discussion
topics
that
I
identified
from
from
the
last
from
some
previous
conversations
feel
free
to
add
to
it
feel
free
to
modify
that
and
thank
you
rashid
for
volunteering.
For
being
the
note
taking
okay.
Thank
you
cool,
so
I
don't
know
if
we
have
a
introduction
to
rfc
17,
but
from
scotland
last
session.
A
A
Cool,
thank
you.
So
the
first
topic
I
identified
from
previous
conversation
was
the
implications
of
cryptographer
becoming
a
sort
of
umbrella
project,
so.
B
Yeah
I'll
just
jump
in,
I
think
that
right
now,
I
think
of
cartographer
as
a
project
where
everybody
who
is
a
maintainer
of
cartographer.
I
well.
Actually.
Let
me
back
off
that
because
I
was
going
to
say
anybody
could
any
of
those
maintainers
can.
I
would
be
expected
to
be
able
to
like
alter
the
code
in
arbitrary
ways,
but
I
think
there
are
some
pms
that
are
maintainers
as
well,
so
I
wouldn't
expect
them
to
be
able
to
make
to
alter
code.
B
B
C
B
B
B
Josh-
and
I
were
actually
just
talking
about
like
the
values
that
are
exposed
by
kpac
as
an
example
and
the
values
that
cartographer
would
really
like
to
be
exposed.
What
would
make
our
lives
easier?
And
so,
if
there
were
a
if
there
were
a
path
to
production,
where
every
their
default
path
to
production,
where,
like
every
controller
that
was
templated
out
in
that
path
to
production,
if
every
one
of
those
were
part
of
the
umbrella
cartographer
project,
those
conversations
about.
B
About
the
api,
essentially
that's
maintained
between
the
choreographer
and
and
the
default
choreographed
objects
would
be.
There
would
be
relationship
between
those
projects
and
it
would
make
those
conversations,
presumably
a
lot
easier
and
then,
finally,
somewhat
related
to
to
my
first
point,
a
meeting
like
this.
B
Presumably,
we
would
want
to
have
some
umbrella
level
meetings,
but
then
also
there
would
probably
be
some
open
meetings
that
were
just
for
the
individual
pieces.
The
choreo,
the
choreographer
and
each
of
the
choreographed
would
probably
have
worthwhile
conversations
that
they
would
want
to
have
with
their
communities
that
didn't
necessarily
have
implications
for
the
other
pieces.
C
So
I
have
a
couple
of
responses
to
those
not
necessarily
answers
in
any
way,
but
there's
a
couple
of
things
that
I
I
the
one
about
the
choreographed,
what
projects
we
pull
in
if
we
pull
in
projects
that
mean
that
we
can
enforce
apis
more
easily,
I
still
think
there's
an
open
question
of
whether
we
want
to
do
that
like
there
may
still
be
a
requirement.
C
The
cartographer
is
still
as
malleable
as
ever
and
I
believe
that's
still
there,
which
means
that,
although
we
can
control
some
apis,
we
probably
still
have
to
support
you
know
enemies
as
the
best
way.
I
know
to
put
it
and
the
in
response
to
what
kind
of
meetings
will
we
hold?
C
I
think
it's
too
soon
to
worry
about
that,
like
we
are
still
an
adaptable
structure,
we
can
choose
what
we
do.
I'd
be
more
concerned
about
the
scope
of
the
work
for
the
existing
team.
C
B
So
one
one
response
that
I
would
have
to
the
question
of
enemies
is
that.
B
Kubernetes
resources
are,
you
know
these
arbitrary
things,
so
there
are
some
resources
that
just
wouldn't
fit
with
cartographer,
and
so
hopefully
you
know,
we
hope
that
kubernetes
best
practices
will
push
things
in
a
direction
where
we
can
work
with
all
of
them,
but
I
could
totally
imagine
situations
where
kubernetes
best
practices
don't
get
us
far
enough
and
what
we
need
are
you
know
we
just
need
like
one
or
two
best
practices
that
people
need
to
pick
up
in
order
to
be
well
choreographed
and
in
that
case,
having
a
suite
of
tools
that
one
already
work
and
two
so
one
already
works.
B
So
you
can
definitely
have
a
supply
chain
and
we
can
say
this
supply
chain
works.
We
can
get
you
to
prod,
as
well
as
saying
to
those
other
resources
that
don't
work.
That
being
able
to
point
out.
You
know
here
here
is
an
example
of
a
change
that
needs
to
be
made
and
here's
a
team.
That's
already
made
it,
and
that
could
be
a
good
conversation
point.
B
And-
and
I
guess
the
last
thing
I
would
say
about
that-
is
that
otherwise,
yes,
I
totally
agree
with
you:
cartographer
should
always
develop
with
an
eye
to
supporting
the
most
arbitrary
resources
possible.
C
If
I
can
I'd
just
like
to
step
back
and
just
say
that
early
on,
I
think
a
few
of
us
felt
like
one
of
the
hardest
things
about
selling
cartographer
was
that
it
was
dependent
on
things
such
as
convention
service,
that
really
made
it
shine
and
examples
like
you
know,
supply
chains
that
also
made
it
shine,
although
they're
full
of
ytt,
and
we're
not
sure
that
that
is
how
we
want
to
promote
at
this
point,
if
we
we'd
like
to
make
things
simpler,
less
more
declarative,
but
nonetheless
we're
thinking,
we'd,
also
love
to
see
tce
go
open
source
and
the
supply
chains
be
like
demonstrably
useful
supply
chains
in
a
one-click
environment,
be
the
the
way
that
we
start
promoting
the
product.
C
I
think
this
is
a
good
step
towards
that.
Either
way.
Just
I
mean
if
this
is
how
we
remove
the
impediment
of
getting
tce
open
source
with
open
source
supply
chains,
then
I'll
move
for
it.
D
D
You
know
what
what
direction
we're
going
with
this
is.
It
seems
like
there's
an
idea
to
make
photographer
an
umbrella
project,
and
you
know
have
convention
service,
be
one
of
the
things
in
that
toolkit
right
and
then
does
that
mean
that
we
have
a
different
name
for
what
we
have
with
supply
chain
and
delivery
right
now
see
choreographer.
Is
that
the
name
of
that
or.
C
We
hadn't
gone
as
far
as
naming
this
clearly
a
bit
of
an
issue
if
we
have
an
umbrella
site,
but
like
the
the
easiest
thing
we
could
do
is
is
create
a
site
for
multiple
projects
and
call
that
call
that
cartographer
site
and
have
cartographer
be
the
the
core
choreographer
that
sits
underneath
that
and
then
the
next
thing
will
be
convention
services.
Another
project
before
we
have
to
face
naming
facing
naming
might
be
worthwhile,
but
I'm
just
saying
there
are
ways
that
we
can
not
do
it
with.
C
D
C
C
I
was
just
wondering
josh
if
you
had
any
thoughts
about
the
team's
direction
on
this
right.
F
No,
like
my
all
my
thoughts
this
morning
were
around
how
this
isn't
really
about
like
rfc
17
right,
it's
more
of
a
meta.
It's
like
a
meta
point
right
like
we
identified.
Basically,
it's
like
what
is
what
are
the
implications
of
being
an
umbrella
project
and
then,
like
you,
know
tactical
things
of
like
how
would
we
actually
achieve
this,
but
because
I
think
it
like.
F
I
there's
like
there's
something
that
nags
at
me
in
the
back
of
my
brain
right
when
we
think
about
even
supply
chain
and
delivery,
where
like
in,
like,
ultimately
in
certain
deployments
like
these
two
things,
aren't
even
gonna,
be
on
the
same
clusters
right
and
so,
like
you
know,
maybe
even
like
even
those
two
things
like.
Are
they
really
like
one
one
component
or
are
they
multiple
components?
F
Stuff
like
that
right?
So
I
think
we
can
extend
a
lot
of
the
things
and
even
runnable
too,
like
we
take
that
as
its
own
thing
like
is
that
part
of
a
supply
chain
is
it
sub?
Is
it
separate
so
there's
even
like
parts
of
like
cartographer
as
it
is
today
that
you
know
we
could
probably
make
the
same
argument
for.
B
Yeah,
yes,
I
think
it's
totally
possible
to
I
mean
those
are
three
different
reconcilers
in
the
same
controller
right
like
we
could
definitely
see
ways
that
we
could
just
say
like
well,
let's
cleave
these
off
and
make
them
put
them
into
their
own
repos.
At
the
same
time,
those
those
reconcilers
all
share
code,
and
so
I
think,
there's
definitely
a
big
jump
between
here
is
here's
so
runnable,
obviously
the
most
different
from
the
others.
B
B
C
B
What's
the
what's
the
object
and
where
the
specifics
of
this
object,
it
doesn't
know
what
it
does
know
is.
It
knows,
stamping
out
new
objects
and
that's
super
similar
to
what
supply
chain
does
that's
super
similar
to
what
delivery?
Does
it
stamps
out
new
objects
so
much
so
that
they
do
share
code?
B
So
I
think
of
those
is
much
more
similar
than
convention
service.
F
I
think,
like
the
way
I
think
about
it.
It's,
like
my,
I
think
my
my
point
was
like
we're
already
kind
of
an
umbrella
project
to
a
certain
degree
right
and
then
the
next.
The
a
lot
of
the
concerns
you
brought
up
are
actually
the
next
point
it's
like
do.
We
want
to
maintain
a
single
versus
a
monorepo
kind
of
thing
right,
like
we're
already
a
collection
of
things
working
in
concert
to
achieve
our
goals
so,
like
yeah
to
me,
we're
already
kind
of
an
umbrella
project.
F
The
tactical
questions
are
probably
easier
like
easier
to
reason
about
in
like
do.
We
want
single
versus
mono,
repo
and
stuff,
like
that,
so.
D
I
want
a
plus
one
to
like,
let's,
let's
totally
decouple
what
repos
we
have
and
how
those
repos
are
organized
right
like
if
you,
if
we
had
a
separate
set
of
templates
for
supply,
chain
and
delivery,
those
interfaces
would
not
overlap
at
all
right.
They
would
be
totally
different,
crds
that
you,
you
could
have
you
know
if
you
didn't
know
they
shared
the
same
code
right,
you
could
use
independently.
D
Without
you
know,
any
interchange
on
top
of
them,
just
like
runnable,
is
the
supply
chain
right
now
right,
and
so,
if
we
kind
of
say
yeah
sure,
like
they
all
live
in
the
same
repo,
two
of
them
could
live
in
the
same
room
and
another
could
live
somewhere
else.
We
could
extract
things
into
libraries
if
we
wanted
to
later
like
take
that
decision
about.
D
You
know
the
technical
debt
and
you
know
how
we
want
to
do
the
organization
put
that
aside
and
say:
what's
the
user
interface,
what
do
we
want
is
somebody
who
sits
down
to
use
cartographer
as
a
toolkit
right?
What
what
you
know,
what
buttons
do
they
want
to
push?
What
things
do
they
want
to
install
in
different
places
right?
C
I've
just
put
cartographer
with
supply
chain
delivery
and
runnable
under
it,
which
is
what
people
are
saying
right.
It's
like
that's
what
we're
doing
today
cartographer
is
this
thing
that
has
a
supply
chain,
delivery
and
runnable
under
it
all
right
and
then
and
runnable
itself
is
under
both
delivery
and
supply
chain.
It
can
work
in
both
places
to
convert
edge
to
level
right,
so
we
probably
not
try
to
create
a
dangly
tree.
C
I
suspect.
So
if
we
were
to
say
convention
service,
we
wouldn't
say
this
is
a
child
of
supply
chain,
but
that's
almost
certainly
where
you
would
use
it
right,
and
then
we
just
talk
about
what
these
things
are
with
some
sort
of
like
category
theory
at
the
top
level.
Does
that
sound
about
right,
yeah.
D
I
was
going
to
say
you
just
you:
can
use
convention
service
without
supply
chain.
You
can
use
runnable
without
supply
chain
or
delivery
right
to
have
a
an
interface
with
each
other.
That
you
know
is
not
that
materially
different,
even
than
the
interface
between
supply
chain
and
delivery,
which
is
you
know,
there's
a
third
party
thing
in
one
case,
kubernetes
api.
Another
case
get
right
that
helps
do
the
interchange,
but
they
are
all
independent
things
you
could
use
by
themselves
right.
G
What
I
was
going
to
say
earlier
is
that
the
convention
service,
as
it
exists
today,
is
certainly
most
useful
in
the
context
of
the
supply
chain.
I
would
like
to
see
it
evolved
also
handle
delivery
so
as
there's
custom
config
for
an
environment
as
something
gets
delivered,
maybe
that
can
be
encapsulated
into
a
convention.
G
I've
also
been
fairly
quiet
on
these
conversations
so
far,
just
because
the
questions
about
whether
a
cartographer
is
an
umbrella
project
or
single
versus
monorepo,
I
view
is
largely
orthogonal
to
the
rfc
they're
fine
questions
to
ask,
and
I
think
they're
important
questions
to
ask
for
cartographer.
Just
that.
I
don't
think
that
the
convention
service
rfc
should
necessarily
be
tied
to
sort
of
one
side
of
the
other
of
these
questions.
I
think
it
can
work
in
either
dimension
both
ways.
B
What
would
the
implications
of
that?
It
sounds
like
you're
saying
there
aren't
any
implications
of
that
for
rfc
17.
H
G
In
terms
of
the
actual
content
of
the
rfc,
it's
the
scope
of
the
capability,
whether
it's
something
that
the
cartographer
project
believes
that
is
useful
and
important,
actually
exists
within
the
cartographer
project.
B
A
number
of
folks,
that's
called,
will
have
heard
me
say,
included
this
meeting
last
week.
I
believe
that
I
think
of
kpac
is
like
super
important
for
cartographer.
I
I
don't,
I
don't
know
of
anyone
who's
written
a
supply
chain
yet
who
hasn't
used
kpack
in
their
supply
chain?
And
it's
it's
another
project
right.
It's
it's
not
it's
not
part
of
cartographer.
B
B
The
source
controller
for
flux
very
similar,
like
we
every
every
supply
chain
that
we
write,
does
that,
and
so
that's
right
for
me,
that's
the
orthogonal
question
is
like.
Yes,
I
see
value
in
these
projects
and
that
doesn't
change.
My
thoughts
on
their
like
my
feeling
that
they
are
valuable
projects
doesn't
mean
that
I
think
that
they
necessarily
have
to
be
part
of
a
cartographer.
I
think
they
they
in
fact
present
great
models
of
open
source
tools
that
have
some
value
on
their
own.
B
Have
incredible
value
when
choreographed
the
convention
service.
B
D
I
think
I
see
a
a
difference
between
k-pac
and
convention
service
and
that
you
know
k-pac
is
presenting
this
very
opinionated
way
of
building
a
container
image
right.
It
doesn't
support
docker
files.
It's
you
know
it's
using
this
kind
of
technology,
that's
suitable
for
more.
You
know,
image
builds
at
scale
or
when
you
have
developers
that
have
certain
needs
around
how
you
build
images
right.
D
You
know
right
now,
I
suspect,
we'd
see
a
lot
more
people
using
tecton
to
do
that
image
build
step,
I'm
not
sure
if
we've
added
support
for
the
part
of
runable
that
returns
the
status
back
yet
so
you
could
do
that
right
or
if
we
have
a
good
examples
that
cover
that,
but
the
you
know
if
k-pac
were
part
of
the
project
right.
I
think.
D
Oh,
that's
that
we're
taking
a
very
strong
opinion
about
how
to
build
images
in
this
case,
but
with
convention
service,
it's
it
kind
of,
for
me
at
least
falls
into
that
area
of
like
this
is
a
more
generic
tool
for
understanding,
artifacts
and
you
know
doing
generic
kubernetes
things
on
top
of
them.
There's
no
alternative
to
convention
service.
Besides,
not
using
convention
service
right,
just
like
there's
no
alternative
to
supply
chain.
Besides,
you
know
doing
some
of
this
orchestration
yourself
right
and
so
in
some
ways
you
know
to
me.
D
I
Yeah,
I
think,
there's
a
couple
things
like
obviously
there's
a
lot
of
things
that
are
choreographed
that
bring
value
to
choreographer.
I
mean
that's
kind
of
why
choreographers
built
right
just
to
be
able
to
take
these
things
that
are
valuable,
independently
and
sort
of
chain
them
together
into
something
that's
that's
greater
than
the
whole
right,
and
so
I
think
I
think
that
makes
sense.
I
think
when
you
look
at
something
like
kpac
and
you
say
kind
of
we
haven't
built
supply
chains
for
it.
I
I
think
that's
that's
just
because
it's
been
vmware
building
it
and
we
have
kpak
close
to
home.
You
know
from
from
from
the
user
perspective
like
the
first
things,
we're
prioritizing
like
commercial
and
open
source,
but
from
commercial
people
who
are
talking
about
wanting
to
use
supply
chains.
The
first
thing
they
want
to
do
is
bring
their
own
docker
file
and
bring
their
own
images
right.
I
I
These
are
all
like
super
cartographer
focus
and
then,
when
you
look
at
like
cartographer
itself
like
yes,
it
needs
other
things
to
make
it
valuable,
but
I
think
the
sense
of
what
convention
service
does
is
sort
of
like
a
very
specific
plug-in
point
like
different
than
building,
which
is
this
sort
of
generalized
thing.
It's
literally
sort
of
aware
that
there
are
steps
that
are
coming
through
a
supply
chain
that
have
implications
on
the
status
of
a
thing.
I
You
want
to
run
right,
like
that's
the
entire
premise
of
convention
services,
sort
of
being
aware
of
the
concept
of
supply
chain.
So
in
that
sense
it's
really
like
a
custom
built
extension
point
that
cartographer
just
didn't
have
yet
so
I
sort
of
see
it
as
something
that's
like
not
like.
I
can
see
where
we
could
stretch
it
as
useful
independently
as
much
same
way.
You
can
sort
of
say
supply
chain
and
delivery
could
be
useful
independently,
but
in
essence,
these
things
they're
so
tightly
coupled
in
the
like.
I
Complete
picture
the
value
that
you're
actually
trying
to
bring
but
they're
just
they're,
just
not
different
projects
at
all.
It's
sort
of
the
way
I
think
about
it
so
like
we
wouldn't
we
wouldn't
put
a
lot
of
effort
into
convention
service
right
now,
building
up
its
own
open
source
community
in
its
own
tool
chain
and
something
to
be
plugged
into
to
see
icd,
it's
something
that's
really
like.
I
Maybe
it
could
evolve
to
that
in
the
distant
future.
If
we
see
people
taking
these
cartographer
pieces
and
breaking
them
down,
but
right
now,
it's
it's
pretty
much
how
we
plug
stuff
into
the
supply
chain
flow,
so
their
value
is
so
tightly
coupled.
It
doesn't
really
make
sense
to
like
treat
them
separately.
D
Is
there
something
to
be
said
for
specific
conventions
living
outside
of
the
project
right,
if
you
have
a
convention
for
analyzing,
build
pack
images
right,
maybe
that
that's
the
thing
that's
too
specific,
or
that's
too,
you
know
too
tailored
where
convention
service
itself
is,
you
know,
without
those
conventions,
is
kind
of
like
a
different
kind
of
stamper.
If
that
makes
sense-
or
you
know
it's
really
responsible
for
the
choreography
and
orchestration
kind
of
part,
instead
of.
G
G
I
would
lean
more
towards
none
unless
those
conventions
themselves
wanted
to
go
open
source
so
like
we
do
have
a
couple
sample
conventions,
one
of
which
is
really
just
like
the
equivalent
of
hello
world
and
the
other
was
a
little
bit
more
real
and
needy.
G
I
would
imagine
that
we
would
include
those
as
part
of
the
contribution
just
so
there's
something
to
play
around
with,
but
how
far
the
community
wants
to
go
with
actually
offering
conventions.
How
much
vmware
wants
to
open
source
of
the
conventions
that
they
already
have?
Those
are
all
good
questions
to
ask.
C
C
G
Yeah,
I
left
that
as
an
unresolved
question,
mostly
just
because
I'm
not
able
to
commit
to
any
of
those
and
even
then
I
would
have
definitely
imagined
that
individual
conventions
would
exist
like
in
that
case.
It
almost
would
have
to
be
treated
as
an
umbrella
project
to
have
this
fold
under
the
cartographer
umbrella,
because
those
kind
of
can
end
up
being
like
very
specific
to
a
use
case.
It'll
have
a
different
release.
J
So
in
case,
like
external
users
or
like
anyone
wants
to
sort
of
build
new
conventions,
they
would
then
live
in
their
own
could
have
repositories
or
if
there
are
any
conventions
we
want
to
like
samples
we
may
have
in
our
project,
but
not
actual
nothing
beyond
those
similar
to
how
we
are
thinking
about.
I
guess
the
supply
chains
for
cryptographer.
C
C
I'm
going
to
say
that
really
changes,
my
my
general
feeling
about
needing
to
split
the
repositories
asap
right.
The
convention
service
is
a
tool
that
really
empowers
the
supply
chains.
C
Then
there's
probably
not
a
problem
with
them
being
released
at
the
same
cadence.
The
idea
that
there
were
conventions
involved
in
that
which
is
sort
of
how
I
had
read
it.
It
was
definitely
a
different
reason
to
change
a
different
cadence.
So
I'm
really
glad
you
brought
that
up
scott,
I
think
basically,
the
rule.
C
The
rule
of
thumb
here
is
that
we
could
easily
not
move
on
making
it
a
umbrella
project
if
the
cadence
stays
in
lockstep
and
the
thing
that
would
make
me
say
it
won't
is
if
we
were
also
trying
to
support
something
more
concrete
than
example,
conventions.
E
F
G
So
yes,
my
goal
is
not
to
just
toss
this
over
a
wall
and
then
say:
good
luck
so
definitely
like.
I
am
extremely
interested
in
getting
this
contribution
in
and
then
you
know
once
it
gets
into
the
bigger
community
kind
of
trying
to
figure
out
how
it
evolves
from
there.
G
G
Yeah,
it's
always
difficult
to
commit
to
the
future.
Things
change
quickly
enough,
but
I
mean
I
certainly
was
created.
Jeez
I
mean
depends
on
when
you
want
to
say
it
was
created
like
up
to
two
years
ago.
It's
kind
of
the
first
kind
of
inklings
of
what
is
now
it
like.
I've
been
involved
for
those
two
years
with
varying
degrees
of
effort,
depending
on
what
our
needs
are
like.
I
don't
see
that
going
away.
C
In
in
response
to
this
discussion
about
resourcing,
there
is
a
if
we
look
at
it
and
we
decide
really
it's
fine
for
us
to
maintain
to
emily's
point.
I
don't
think
there's
much
that
we
need
to
worry
about
with
the
whole
umbrella
project
thing,
but
I
think
the
team
feels-
and
I
want
to
get
a
feel
for
this,
but
I'll
say
what
I
feel.
C
I
feel
that
if
there
is
room
for
a
team
to
be
dedicated
to
that
work
on
the
cartographer
sorry
on
the
convention
service,
it
would
be
nicer
for
us
all
if
we
do
work
out
how
to
get
an
umbrella
solution
going
just
so
that
it's
easier
to
maintain
to
do
maintainer
work
like
looking
for
prs
and
stuff.
That's
actually
related-
and
this
is
not
because
you
know
this.
This
is
a
quick
touch
on
like
the
monorepo
versus
separate
repos.
C
The
problem
with
mono
repos
isn't
git.
I
think
one
of
the
problem
with
mono
repos
is
tools
right
in
general.
It's
it's
we're
using
github
github
has
a
release
page,
it
has
actions
and
then
you'd
have
to
start
writing
actions
that
filter
on
particular
commits
and
pr's.
So
that
people
can
have
slightly
different
cadences
behaviors
expectations,
that
sort
of
thing-
and
we
just
and
don't
know
that
we
want
to
go
to
that.
C
But
I
think
that
if
we
find
that
there's
quite
a
lot
of
work
involved
in
in
that
and
it
wouldn't
be
about
moving
across
the
sub-projects
of
cartographer,
it
would
be
more
about
there
being
specific
teams
for
specific
work.
We
might
want
to
talk
about
the
umbrella
project
in
regards
to
that.
So
maybe
the
first
trigger
is
to
look
at
the
work
involved
in
consuming
convention
service.
D
I'm
not
sure
I
understand
like
it
seems
like
there's
an
idea
of
what
a
team
is
an
idea
of
how
an
umbrella
project
supports
a
team
under
that,
or
you
know
like
there's.
There's
some
assumption
there
about
how
maybe
internal
organization
and
external
organization
have
to
flow
together
in
a
certain
way,
and
I
wonder
if
we
can
kind
of
put
those
assumptions
aside
right
and
say:
there's
a
project
doesn't
like
you
know,
I
don't
really
know
what
an
umbrella
project
means
exactly,
but
there's
a
project.
It
has
a
toolkit.
It
has
some
things
in
it.
D
Some
folks
from
vmware
are
going
to
work
on
that
project
on
different
parts,
we're
going
to
make
sure
we
have
enough
people
to
work
on
all
the
parts,
and
hopefully
we
have
a
bunch
of
people.
You
know
in
the
community
who
are
up
on
that
project
too,
like
I'm,
I'm
failing
to
understand
the
underlying
problem
there.
If
that
makes
sense,
but
I'm.
C
Not
talking
about
it
in
those
terms,
I
was
thinking
being
a
little
bit
more
early
prepared
than
than
just
I
mean
some
of
us
have
encountered
those
problems
working
on
projects
that
have
to
pull
in
multiple
other
contributions,
and
I
think
the
main
question
is
about
the
maintainer
team
right.
The
team
that
is
defined
as
maintaining
prs
on
a
github
object,
a
github
repository
right
and
handling
those
and
being
able
to
read
the
work
that
they've
got
to
do
for
the
day
and
work
that
submitted
that
is
contextually
meaningful
to
them.
D
Mean
maintainers
and
the
ability
to
merge
prs
come
from
being
on
the
project
for
an
amount
of
time,
understanding
the
project
enough
that
you
know
you
have
that
responsibility.
You
know,
and
maybe
some
internally
yet
like
somebody's
saying
yes,
this
is
a
thing.
You
should
do
enough
that
you
have
time
to
do
it
right.
A
D
C
C
That's
that's
our
question.
Is
it
enough
work
that
you
would
need
a
focus
team
that
included
some
maintainers
people
who
are
responsible
for
ensuring
that
the
prs
are
merged
for
convention
service?
Have
the
context
and
keep
the
context
and
just
talking
about
a
fire
hose?
Are
we
turning
on
a
fire
hose?
C
D
C
One
of
those
points
are
one
of
the
definitions.
Is
that
it's
not
another
repo
like
at
the
moment,
if
we
don't,
if
we
just
absorb
it
into
the
existing
repo,
that's
where
this
umbrella
concept
or
discussion
comes
from.
If
it's
a
separate
repo,
I
think
a
lot
of
us
find
it
easier
to
decide
whether
something
is
important
to
us
right
now
and
what
it
relates
to.
F
I
think
rash.
Correct
me
if
I
wrong,
but,
like
part
of
your
point
is
like,
let's
just
make
sure
we're
using
the
github
tools
properly
right.
It's
like
you
know,
yeah,
are
we
just
mashing
two
things
with
two
backlogs
two
separate
workflows,
two
different
release
cycles.
Are
we
just
matching
them
together
into
one
repo
for
the
sake
of
it,
and
but
let's
just
make
that
decision
like.
C
D
F
And
like
at
the
very
top,
we
kind
of
we
what
kind
of
outlined
like?
Should
this
be
an
umbrella
project
and
like
should
this
be
monorepo
versus
multirepo
and
to
me,
like
umbrella
projects,
kind
of
like
the
marketing
term
that
comes
associated
with
being
multiple
reposts?
F
D
A
lot
of
projects
that
you
know
ship
one
binary
at
the
end
are
50
repos,
just
because
that's
how
they
want
to
organize
their
code.
Right,
like,
I
think,
shouldn't
the
decision
about
the
organization.
The
code
be
around
what
makes
sense,
what's
easiest
for
people
to
deal
with
day
to
day
and
architecturally,
and
all
of
that.
F
I
would
argue
yes,
but
are
going
that
direction
is
actually
easier
right.
You
know,
50
different
repo
shipping
together
is
actually
easier
it
to
some
respects
than
like
fighting
the
tooling
and
going
the
opposite
direction.
I
know
this
is
like
you
know.
These
are
things
that
we
can
work
out.
Just
I
think
it's
an
important
thing
point
to
raise.
C
I
think
that's
what
we
want.
One
of
the
things
we
wanted
to
discuss
is
to
have
a
shared
understanding
that
this
team
feels
like
there's,
probably
nicer.
If
this
thing
exists
in
its
own
repository,
even
if
we
are
to
maintain
it
for
now,
it
would
probably
be
nicer
unless
there's
a
really
good
reason
to
treat
it
as
a
singular
thing,
or
maybe
it's
something.
We
should
defer,
pull
it
into.
C
One
repo
see
how
we
deal,
how
we
cope
and
and
whether
whether
we
find
ourselves
treating
it
as
a
separate
assigned
workload
or
you,
I
don't
know
how
to
describe
it,
but
like
a
a
separately,
managed
or
or
maintained
project.
G
Yes,
I
think
it
can
work
in
either
model.
I
think
there
are
some
benefits
to
things
being
as
tightly
integrated
as
the
rest
of
cartographers
so
like
if
all
of
cartographers
on
the
single
repo
and
then
the
convention
service
is
off
on
its
own.
I
think
that's
a
little
bit
awkward,
but
if
cartographers
moving
in
a
direction
where
pipelines
is
a
separate,
repo
and
delivery
is
a
separate
repo
and
then
maybe
that
then
it
makes
more
sense
to
me.
G
C
C
We
don't
see
how
it's
apart,
a
really
a
part
integral
part
of
our
daily
work
and
delivering
cartographers
value.
When
we
do,
we
may
have
quite
different
opinions
about
how
it
should
best
be
structured.
All
right.
I
think
the
important
thing
is
that
we
introduce
it
smoothly
in
a
way
that
we
can
work
with,
and
I
wouldn't
mind
it
being
part
of
the
same
repo
at
this
point.
C
To
be
completely
honest:
if
we're
not
maintaining
conventions
with
it,
we're
not
maintaining
released
conventions
with
it,
and
then
we
can
discover
that
just
I'm
just
saying
that
and
I'm
one
for
splitting
repos
personally,
but
that
would
be
enough
that
we
could
just
keep
moving
forward
and
then
find
out,
and
if
and
if
it's
just
no
one
else
has
any
opinions,
but
us
with
the
technical
concerns.
C
Then
we
can.
You
know
the
engineering
team
can
then
say:
okay,
it's
time
to
split
this
out.
This
is
too
hard
because
it's
left
up
to
us
and
we
know
that
we
have
the
power
to
make
those
choices.
G
G
Like
I
wouldn't
imagine,
having
separate
rfcs
or
separate
team
meetings
or
anything
like
that,
so,
but
if
you
have
a
separate
repo,
then
you
kind
of
inherently
have
a
separate
issue:
backlog,
a
separate
set
of
pr's
and
then
those
would
have
to
be
dealt
with.
E
E
I
was
just
gonna
say
like:
should
we
have
someone
go
off
and
spike
and
try
to
pull
convention
service
into
cartographer,
like
I
think
at
least
this
entire
meeting
to
me
is
like
we
have
no
problems
like
accepting
rfc
17,
but
then
it's
like,
then
what
right
and
like
that's?
Why
we're
asking
all
these
very
specific
questions
on
how
it's
going
to
work,
because
we
just
want
to
know
what
the
next
steps
are.
G
G
Can
you
share
a
backlog
too?
It's
pretty
minor.
We
have
a
few
ideas
about
adding
additional
types
of
conventions.
G
Sorry
additional
ways
of
invoking
conventions
so
like
today,
conventions
are
implemented
as
a
web
book
call
so
to
write
a
new
convention,
you
basically
have
to
expose
a
server
that
can
receive
weapon
calls,
there's
some
desire
to
support
types
of
conventions
that
wouldn't
require
a
separate
process,
so,
whether
that's
writing
a
convention
in
something
like
wasm
and
then
just
hosting
that
inside
the
controller
or
doing
something
where
we
basically
call
ytt
and
then
let
that
handle
the
actual
work.
G
G
So
there's
not
a
large
back
work
of
well
outside
there's,
not
a
large
backlog
of
work
that,
like
has
to
get
done
or
to
like
reach,
minimal,
viable
product
like
it's.
It's
already
kind
of
at
that
stage.
B
Scott,
what
have
you
had,
folks
that
have
been
onboarded
to
convention
service
like
how?
How
long
does
it
take
someone
to
go
from
like
hey
there's
this
thing
called
convention
service
to
the
point
where
they're
you
know,
they're
ready
to
be
maintainer.
G
So
there's
a
few
of
us
who
have
been
involved
in
maintaining
the
project.
One
person
was
in
fairly
early,
so
I
was
pretty
involved
in
getting
the
code
base
set
up.
So
I
that's
probably
not
a
good
example
of
someone
getting
onboarded
there's
another
case
where
there's
a
more
recent
hire,
who
came
on
board
and
has
been
able
to
deliver
prs,
but
also
wasn't
their
full-time
effort.
G
So
it's
tough
to
say
that
like
they're,
I've
had
like
to
give
like
a
wall
clocking
in
a
measurement,
but
the
overall,
the
the
scope
of
convention
service
is
fairly
tight.
Like
it's
a
fairly
like
there's
two
crds,
the
relationship
between
them
is
pretty
well
defined.
G
C
I
was
going
to
just
throw
in
one
more
spanner
with.
C
The
outstanding
work,
which
is
merging
documentation
and
trying
to
get
the
documentation
to
fit
with
examples
and
everything
else
that
we're
already
far
behind
on
we're
trying
to
get
ahead
on
is
there
is
there
much
to
document?
G
G
G
C
C
If
you
know
what
I
mean
all
right,
they
don't
make
as
much
sense
as
they
might
when
convention
service
land,
so
there'll
be
some
rewrites
as
well
yeah.
Are
you
transparent
about
the
work
involved.
G
Project
is
dead,
so,
like
am
I
happy
with
our
current
level
of
docs
on
the
committed
service?
No,
I
think
things
can
always
be
better,
but
like
there
are
docs,
we
can
work
on
getting
that
moving
forward
and
sort
of
getting
it
integrated
and
then
iterate.
C
So
someone
mentioned
timelines
earlier.
I
still
feel
like
that's
the
last
thing
we
need
to
to
talk
about
here.
We've
we've
got
timelines
internally
as
a
company,
because
most
people
hear
vmware,
I'm
just
wondering
if
there's
any
hopes
for
when
these
things
land
so
that
we're
aware
of
that,
when
convention
services
is
consumable
as
an
artifact
of
cartographer.
G
J
There's
there's
one
implication
with
convention
service
as
it
relates
to
cartographer,
is
around
kanji
community
edition
bringing
a
lot
of
the
so.
The
core
capabilities
of
the
vmware
tap
product
to
market
and
tensor
community
edition
brings
all
of
the
open
source
only
capabilities
of
vmware
tab
product.
J
So
and
as
part
of
that
story,
tce
is
planning
to
bring
like
the
ability
for
users
to
create
workloads
with,
with
with
supply
chains,
going
from
source
code
to
running
apps.
There's
also
planning
to
support
developers
being
able
to
make
inner
loop
like
be
able
to
do
inner
loop
development
and
that
relies
on
one
of
the
developer
conventions.
That's
like
a
natural
implementation
of
the
convention
controller.
J
So
that's
the
one
implication.
Tensor
community
edition
plans
to
bring
those
capabilities
to
to
the
product
to
pce
by
the
kubecon
may
so
that's
probably
the
one
product
implication.
C
And
yeah,
so
I'm
I'm
thinking
that
our
takeaway
here
is
that
we're
looking
for
scott
to
create
a
branch
that
imbibes
the
convention
service
and
support
him
where
we
can
and
make
decisions
about.
It
would
seem
to
me
like
we'll
make
decisions
about
whether
we
want
to
split
things
with
different
cadences
if
we
discover
them
at
a
later
date,
the
mono
repo
multi-repo
debate
and
those
sorts
of
things
do
we
agree?
B
C
D
Are
we
going
to
have
people
joining
who
have
context
in
conventional
service
already
and
be
able
to
merge
prs
like
is
it?
Is?
It
may
be
better
to
start,
but
the
people
who
merge
pr's
on
service
are
people
who
are
joining
with
context
and
then
over
time
we
had
more
people
who
could
merge
prs
in
that
repo
who
understand
the
repo
better.
Instead
of
just
you
know,
saying
everybody
can
merge
pr's
or
something
like
that.
D
Maybe
that'll
get
a
little
more
clear.
Once
we
have
an
idea
of
who's
going
to
be
working
on
it,
it
seems
like
some
of
that's
still
uncertain.
G
G
I
guess
it's
probably
less
work
for
me
to
contribute
it
as
a
separate
repost,
because
it
already
exists
as
a
separate
repo,
I'm
perfectly
willing
to
do
the
work
to
try
to
get
it
into
monorepo.
So
we
can
see
what
that
looks
like
and
then
later
on.
If
the
cartographer
monorebo
splits
into
multiple
repos,
I'm
like
you
can
make
that
decision,
then.
C
I
think
the
one
thing
that
you
mentioned
is
that
it
talks
about
culture.
Our
culture
is,
if
we
see
a
pr,
we
believe
that
we
should
try
and
get
it
landed.
We
don't,
as
you
say,
you
know,
land
the
things
that
we
feel
comfortable
with.
We,
we
spread
our
knowledge
and
make
sure
we
understand,
what's
going
on
by
making
sure
we
land
the
ones
we
see.
C
So
it's
just
a
cultural
thing.
I'm
not
sure
that
we'll
be
any
different
if
it
was
a
single
rebirth
or
many
we'd,
probably
look
at
both
lots.
I
don't
know,
I
think,
that's
kind
of
core
to
what
we
were
trying
to
to
get
to
the
bottom
of
is:
is
this
something
that
we,
the
maintainers
group,
is
responsible
for
now
and
it
feels
like
we
will
be
even
if
we've
got
help
along
the
way
we
are
responsible
for
it.
So
that's
that's
where
I
personally
was
like.
Oh.
K
Personally,
I
feel
like
a
great
way
to
learn
about
the
project
would
be
to
be
the
ones
to
do
the
work
to
move
it
into
our
one
repo.
If
we
decide
that's
the
right
answer,
rather
than
someone
saying
here's,
a
branch
where
I
integrated
a
bunch
of
things
in
a
bunch
of
different
places,
and
then
you
go
try
to
learn
about
it
and
then
you
might
come
to
the
decision
that
this
doesn't
feel
like
the
right
answer
and
then
what
we
just
undo
it
all
and
just
dump
that
branch
or
we
try
and
split
again.
D
D
C
K
C
C
There
was
a
pending:
there
was
a
pending
issue
raised
to
split
already
and
not
even
on
any
of
the
products,
but
on
the
the
docks
as
being
a
product.
C
We,
the
issue
is
raised
that
that
the
docs
change
at
a
different
rate
and
it's
confusing
to
assume
that
a
tag
represents
docs
and
it
doesn't,
and
so
we
wanted
to
create
a
doc
site
for
also
because
then
waiting
for.
C
Currently
we
have
no
selections
to
get
rid
of
validations
for
code
tests
code
validations
while
we're
making
updates
to
the
docs
and
it's
quite
frustrating
when
we've
got
a
merger
we
want
to
throw
in
which
has
a
much
lower
pr
boundary
as
well.
It's
like!
Yes,
let's
get
that
dock
merged
in
and
then
let's
move
on,
they
move
at
different
rates.
So
we've
already
got
one
of
those
outstanding
that
I
thought
we
were
going
to
discuss
during
this
meeting,
but
we
never
got
the
time.
C
So
I
was
going
to
suggest
that
maybe
the
maybe
the
right
first
step
is
that
it
is
a
separate
repo.
So
that's
got
you
just
move
it
all
right.
So
it's
in
the
open,
we're
in
the
open
sooner
we
start
consuming
and
putting
into
the
docs,
which
is
still
in
our
mono
repo.
But
there
is
a
plan
to
separate
those
out,
or
at
least
a
discussion
to
be
had
about
separating
those
out,
and
that
is
at
least
the
simplest
thing
that
can
be
done
to
keep
us
moving.
K
K
All
the
other
maintainers
are
not
yet
as
sold
on
that,
and
so
it's
hard
for
us
to
kind
of
jump
on
board
with
the
idea
that,
like
until
runable
is
separate,
convention
service
can't
be
separate,
and
I
think
it's
hard
for
us
to
commit
to
like
bringing
it
in
at
this
stage
and
I
think
letting
us
kind
of
get
our
feet
wet
in
it
as
like.
A
separate
repo
will
help
us
maybe
get
to
where
you're
at,
but
it
feels
like
we're
kind
of
talking.