►
From YouTube: 2022-12-15 Crossplane Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right
recording
has
started,
and
this
is
the
December
15th
2022
cross
plain
community
meeting.
I
am
traveling
right
now
and
on
the
road
I
think
my
connection
is
fairly
stable,
though,
but
if
I
do
happen
to
cut
out
anything
like
that,
then
you
know
we
can
have
somebody
else
step
in
to
continue
driving.
A
I
will
drop
into
the
zoom
chat
right
now,
a
direct
link
to
the
agenda
documents
and,
if
folks
want
to
add
a
new
topics
or
things
they
want
to
chat
about
today,
the
agenda
is
always
open
and
people
are
more
than
welcome
to
to
to
add
things
to
it.
So
let's
go
ahead
and
start
off
with
the
Milestone
checkup.
A
Here
we
will
be
driving
in
or
diving
into
deeper
details
on
some
of
these
features
in
areas
of
focus
for
this
Milestone
at
later
points
in
the
agenda,
but
we'll
we'll
get
into
the
high
level
right
now,
all
right.
So
a
couple
of
quick
updates.
A
Actually
let
me
see
the
participants
list
real,
quick
too,
which
is
just
taking
up
more
and
more
of
my
screen.
So
it's
hard
to
see
everybody
here:
okay,
sweet,
so
yeah,
so
I
think.
Let
me
see
if
there's
like
big
notable
updates,
I
think
probably
one
of
the
biggest
updates
is
that,
in
terms
of
the
observe,
only
resources
Hassan
has
put
out
a
design
document
for
that
and
we'll
be
walking
through
in
more
details.
A
Hassan
will
take
us
through
some
of
the
high
level
areas
of
the
design
and
some
of
the
key
changes
there
and
taking
in
some
feedback
as
well,
so
we'll
be
able
to
to
go
through
that
together
a
bit
interactively
today
during
this
meeting
so
that'll
that
will
be
a
good
usage
of
our
time.
Nick
has
continued
to
work
on
the
custom
compositions
effort
as
well,
and
so
I
know
that
there
is
some
some
runnable
code
that
is
usable
right
now
and
I.
A
Think
Nick
is
continuing
to
push
on
that
and
continue
driving
to.
You
know
an
alpha
release
in
1.11
of
this.
This
initial
feature
here
so
I,
don't
know
oh
Nick
you're
on
the
call.
Actually,
can
you
give
us
a
quick
update
on
on
where
the
custom
compositions
are,
and
you
know
if
there
is
ready
for
feedback
from
folks
who
start
taking
it
for
a
test
spin
or
anything
like
that?.
A
That
sounds
really
far
away
when
until
I
realized
it's
basically
holidays
already
so
yeah
next
year
is
totally
reasonable.
All
right,
hey
thanks
for
continuing
to
drive
that
next
I
did
want
to
ask
about
on
2099.
If
there
is
so
Yuri
I
know,
you've
done
a
couple
reviews
on
this.
One
support
Patrick
from
common
data
sources.
A
Is
there
anything
that's
still
pending
for
from
the
reviewer
side,
or
is
there
some
updates
you're
waiting
for
for
Max
or
what's
what's
the
latest
on
this
this
one,
because
I
really
want
to
continue
to
push
to
get
that
into
1.11
as
well.
C
Yes,
a
very
several
rounds
of
review.
I
just
managed
to
return
from
to
it
after
my
PTO
yesterday
and
I
think
there
are
some
issues
with
this
PR
after
the
rebase,
so
I'm
waiting
for
the
fixes
from
Max,
but
I
didn't
check
it
today.
But
yesterday
it
was
like
pipes
are
broken
and
I
also
suggested
that
for
this
complex
feature,
we
want
some
examples
to
be
around
in
the
commentation
so
Visa,
which
would
demonstrate
the
outer
outer
idea
how
to
use
environment
configs.
A
Got
it
got
it
and
is
there,
do
you
think,
there's
any
sort
of
support
that
Max
Max
would
need
to
continue
pushing
on
or
like
adding
those
examples
or
like
he's
he's
got
everything
he
needs
to
be
able
to
execute
on
that
on
incorporating
that
feedback.
C
Yeah
I
have
a
example
of
Ripple
on
my
side
so
like
he
actually
kind
of
grips
that
trip
on
that
month.
He's
he's
like
additional
samples
and
that's
it
and
incorporate.
C
There's
actually
a
good
question
where
to
put
that
examples,
because
so
yeah
we
have
a
place
in
like
a
dog's
embedded
in
a
cross
plane,
but
I'm
not
sure
the
core
cross
playing
Ripple
has
a
good
good
place
for
for
this
kind
of
examples.
Apart
from
the
commentation
what
I
and
just
to
clarify
so
yeah,
there
are
like
a
chunks
of
the
patches
for
a
modern
configs
that
are
already
there
in
the
part
of
this
pairs
were
edit.
C
You
know
after
one
of
the
review
but
say,
and
they
do
not
provide
enough
context,
how
to
use
the
environment
config
in
general,
so,
like
I
I
made
some
attempt
it
worked
for
like
it
worked
like
for
one
of
the
use
cases,
but
another
one
I,
like
totally
missed
the
original,
alter
intention.
I
guess
so,
so
these
kind
of
examples
would
would
help
with
the
consumption
of
the
future
long
term
for
sure.
A
Okay
got
it
so
it
looks
like
you
know
your
ask
here.
This
is
just
from
yesterday
so
yeah,
so
that
makes
sense
that
Max
hasn't
followed
up
on
this
yet,
but
your
ass
here
is
fairly
clear
about
what
you
want
to
see
as
we
you
know.
Obviously
we
need
to
get
the
buy
buttons.
You
know
working
again,
but
then
the
adding
the
example
like
this
ask
is
fairly
clear
and
Max
has
what
it
needs.
C
E
Cool
all
right,
I'll
follow
up
with
you
all
on
on
where
we
can
put
that
in
the
documentation
I'm
about
to
take
on
a
bit
of
a
reorg
of
some
of
the
existing
Dock
and
I
think
we
can
make
sure
we
have
a
good
home
for
that
kind
of
thing.
E
A
All
right
so
yeah,
so
those
are
some
of
the
high
profile
things
are
in
process.
We
talked
last
time
about
the
work
that
Esky
had
finished
on
maturing
composition.
Revisions
to
Beta
is
there
anything
else
to
add
on
that
Esky
or
that's?
You
know,
you've
you've
got
to
put
that
into
place
and
it
was
ready-
and
we
talked
about
it
last
time-
nothing
new
to
add
on
that
one.
A
Awesome
that
sounds
good
yeah
and
then
yeah
do
do
reach
out
for
me
for
anything,
you
need
with
the
blog
post
as
well
I'm
still
standing
by
to
help
out,
but
get
that
out.
A
Awesome
and
then
Jesse
is
there
anything
that
you
wanted
to
add
for
the
signature,
validation
work
that
you
had
been
working
on
any
updates.
You
want
to
share
hey.
G
How
you
doing
I,
I,
I
I,
have
to
admit
I,
haven't
gotten
enough
time
to
actually
put
any
code
down,
but
I
have
been
doing
a
bunch
of
research
into
the
way
that
some
of
the
the
more
recent
implementations
of
package
managers
have
been
doing.
Cosign,
validation
and
I've
added
a
lot
of
notes
in
response
to
some
of
the
the
one
pager
comments
that
had
gotten
submitted.
G
There's
a
couple
of
open
questions
that
I
have
I
might
actually
seek
some
insight
from
yourself,
Jared
or
maybe
Dan,
to
understand
what
a
MVP
might
be.
What
MVP
features
might
be
appropriate.
Given
some
of
the
comments,
it
does
seem
to
me
that
it's
it's
actually
pretty
it
there's
not
much
more
to
adding
keyless
signing.
G
Then
the
keyful
signing
that
we
have
in
the
POC
that
I
submitted
with
that
one
pager,
so
I'm
wondering
if
it
makes
sense
for
us
to
just
to
take
the
time
to
actually
do
the
keyless
signing.
It
is
going
to
be
more
valuable
in
the
long
run
and
with
something
that
I
kind
of
knew
would
be
a
next
step.
G
But,
given
that
the
examples
that
I'm
looking
at
instead
of
inside
of
flux,
for
instance,
there's
really
not
much
more
to
adding
the
keyless
signing,
so
it's
it's
kind
of
to
me
like,
like
a
low
hanging
fruit
at
this
point,
maybe
we
should
just
go
that
route.
A
G
A
Like
a
nice
addition
to,
you
know,
make
the
scenarios
of
coverage
here
more
robust
with
what
hopefully
would
be
fairly
minimal
effort
that
does
sound
like
a
nice
trade-off.
G
Yeah
and
I
think
that
I
could
probably
put
together
a
revised
proof
of
concept
with
keyless
signing
in
the
next
couple
of
days.
So
I
would
imagine
that,
maybe
even
by
end
of
day
tomorrow
before
the
weekend,
that
that
way,
we
could
have
something
to
review
before
the
the
holidays.
G
And,
and
if
this
does
slip
out
past
1.11
I
think
that
that's
you
know
an
understandable
situation.
I
wouldn't
I,
wouldn't
want
to
hold
up
anyone
on
that
release.
A
Yeah,
that's
totally
reasonable,
too.
You
know
it's
just
it's
good
to
get.
Some
updates
on.
You
know
like
what
the
focus
area
is
or
if
you
know,
especially
if
you
need
help
or
feedback
on
things,
you
know
to
help
unblock
you.
You
know
with
this
audience
here.
So
that's
yeah.
That's
that's
totally
reasonable.
If
that
happens,
I
think
that's.
That's
fine!.
A
Jesse,
thank
you.
Man,
okay,
sweet,
so
I
think
that's
the
major
stuff
for
1.11..
Does
anybody
else
want
to
bring
up
1.11
related
Milestone
news
as
we're
kind
of
going
to
go
a
little
bit
dark,
a
fair
amount
of
people
here
over
into
the
year
holiday
time
and
then
come
back
at
it
strong
to
wrap
up
the
release
and
get
it
out
mid,
mid
late,
January
time
frame.
A
All
right
keep
moving
on
then.
So
there
are
some
fresh
provider
releases
from
from
this
week.
A
There
are
direct
links
to
all
of
the
the
major
ones
that
I
was
aware
of,
at
least
for
you
know
the
AWS,
GSP,
Azure
ones,
and
then
one
thing
I
did
want
to
bring
up
with
this
group
is
that
there
there's
a
official
upbound
official
provider
for
the
terraform
now,
but
I
did
want
to
see
if
it's
possible
to
get
like
release
notes
into
the
repo
as
well,
because
you
know
it
is
a
nice,
a
nice
landing
page
for
the
provider,
and
you
know
examples
and
documentation
and
all
that
sort
of
stuff,
but
the
releases
page
is
empty.
A
So
maybe
Yuri
is
that
something
that
you
could
follow
up
on
or
speak
to,
so
that
there's
there's
like
going
forward,
at
least
with
releases
that
we
have.
You
know,
release
notes
that
kind
of
give
details
about.
What's
what's
you
know
in
each
each
release,
and
we
have
some
of
that
there.
A
You
awesome
man,
okay,
that
sounds
good
cool
and
then
I
did
want
to
call
out
a
new
provider.
There's
a
not
scare
provider
that
got
added
and
shipped
as
well
to
our
S5
is
not
provider
its
configuration.
That
has
a
bunch
of
really
good
examples
for
for
configuration
for
multiple
Cloud
fighter
agnostic,
multi-cloud
examples
of
manuscripts
and
kubernetes
offerings.
A
So
this
is
a
great
example
to
use
and
follow,
along
with
to
help
you
install
and
use
you
know,
cluster
abstractions
across
multiple
writers,
so
I
wanted
to
call
that
one
out
as
well
and
any
other
providers
that
have
been
released
recently.
I
just
threw
this
together
really
quickly
right
before
the
meeting.
Any
other
providers
that
folks
want
to
call
out
that
have
recent
releases
are
more
than
welcome
to
be
added
here
as
well
too.
D
The
next
days
there
will
be
the
provider
AWS
release
from
the
community
provider.
We
will
work
on
this.
A
All
right
sounds
good
man,
all
right
so
yeah,
so
that's
providers
and
1.11
features
I
wanted
to
move
into
another
section
here
where
we
wanted
to
give
some
transparency
and
some
insight
into
what
what
about
it's?
You
know
an
Engineers
there
are
working
on
that
is
highly
relevant
to
the
community.
Some
of
this
will
be
supplemental
to
you
know,
obviously
what
we
have
on
the
roadmap
and
the
you
know
core
Crosswinds
leases
Etc,
but
I
did
want
to
give
a
a
space
for
any
company.
That's
working
on
things.
A
You
know
for
cosplaying
in
the
prospect
ecosystem
to
be
able
to
share-
and
you
know,
get
feedback
and
collaborate
with
that
here
as
well.
So
this
is
certainly
open
to
anybody
else.
Who
wants
to
be
adding
their
thoughts,
and
you
know
updates
and
things
that
they've
been
working
on
as
well,
so
Matthias
and
Jean.
Do
you
want
to
go
ahead
and
start
talking
through
some
of
these
topics
here.
I
Yeah
so
I
think
yeah
that
it
was
a
little
bit
of
like
a
discussion
in
slack
on
on
this
sort
of
like
what
are
our
plans
here
and
you
know,
what
are
we
doing
and
I
think
one
of
one
of
the
to
Do's
is
that
we
that
we
write
this
up
but
happy
to
you
know,
respond
to
any
questions,
concerns
or
anything
right
now.
I
So
the
the
idea
for
official
providers
if
you've
read
the
the
blog
post
right
is
that
we
are
you
know
building
these
with.
You
know
a
certain
set
of,
like
you
know
the
Technologies,
underneath
with
upjet
and
the
core
generation
of
just
making
the
core
building
blocks
available
to
our
customers
and
just
making
sure
that
we
have,
like
all
the
you
know,
necessary
processes
in
place
that
we
can
support
this
from,
and
you
know
official
point
of
view
from
an
Enterprise
support
point
of
view.
I
I
It's
it's
not
too
much
of
a
news
that
we're
building
a
new
provider
at
Azure
ad
right
just
to
close
up
the
the
Azure
folks,
but
from
an
API
point
of
view,
a
vendor
point
of
view.
This
is
like
this.
Is
it
right?
This
is
like
we
don't
have
like.
I
You
know,
immediate
plans
to
build
any
kind
of
other
other
official
providers.
Quite
the
contrary
right.
This
was
always
a
goal
of
us
and
you
know
again
like
on
the
phrasing
we
you
know
should
be
a
little
bit
of
clearer.
We.
We
want
to
make
sure
that
there's
like
a
healthy
ecosystem
of
providers
right
which
is
like
you
know,
you
know
the
marketplace
lists
all
kind
of
providers.
It
doesn't
really.
You
know,
judge
there.
We
we
want
to
make
sure
that
you
know
if
people
are.
H
I
Of
like
what
we
can
do
for
our
customers
on
these
providers,
and
the
same
as
goes
through
goes
is
through
true
sorry
for
the
terraform
provider,
which
we
just
made
official.
It's
just
like.
You
know,
making
sure
that
we
have
the
the
processes
and
and
and
things
in
place
that
we're
able
to
provide
our
customers
now
making
it
official
does.
I
You
know,
come
with
with
a
certain
level
of
guarantees
of
like
what
a
bound
puts
behind
this
right
of
just
making
sure
that
that
you
know
it's
it's
maintained
and
supported,
and
that
you
know
we
have
a
certain
level
of
you
know:
internal
processes
that
that
we're
working
with
these
they're
still
Apache
too
right,
they're
still
open
source.
So
you
know,
if
there's
any
feedback
around
this
or
for
for
any
problems
or
any
any
issues.
I'm.
I
You
know
more
than
welcome
to
to
listen
to
this
we're
working
with
the
respective
maintainers
of
these
providers
right
in
this
case,
this
was
Bob
and
Bob
and
Yuri
right
mainly
around
provided
terraform
and
for
others.
I
This
is
provider
Helm
and
kubernetes,
which
are
on
our
pipe
we'll
do
the
same
and
make
sure
that
you
know
folks
that
are
working
on
the
provider
are
happy
with
the
path
that
that
we're
taking
yeah
so
yeah,
that's
that's
like
the
gist
of
it,
but
again,
I
think
it's
important
that
we
have
a
blog
post
around
this
or
or
somewhere
specifying
this.
So
this
is
on
my
my
radar.
I
You
know,
together
with
Jared
or
someone
of
making
sure
that
this
is
like
a
transparent,
transparent
process
and
transparent
way
of
of
looking
to
this
any
any
odds.
Any
questions
yeah.
D
I
can
add
something
because
I
had
I,
don't
know
five
or
six
talks
from
the
community
directly
pinging
me
and
asking
me
here:
Christopher.
Did
you
know
why
about
moves
the
provider
terraform
from
the
cross,
plane,
contract
repositories
to
the
outbound,
because,
from
the
governance
perspective,
it's
like
missing
communication
in
the
community
that
you
that
upbound
will
deprecate
such
providers
and
release
official
one.
There
was
no
communication
in
the
past
Community
meetings
or
I
missed
it,
but
other
folks
also
missed
it
and
it's
it.
D
It
feels
like,
from
a
governance
perspective,
something
changed
for
this
provider,
because
the
community
Can
can
now
only
open
issues.
Something
like
this,
but
the
upbound
forks
will
take
care
if
it's
merged
or
if,
if
they
have
a
completely
other
view
on
on
the
things-
and
there
was
some
big
companies,
they're
asking
me
what
what's
going
on
there
with
this
provider.
That's
why
I'm
edit
the
the
thing
in
in
the
announcement
channels
that
we
can
talk
about
this
in
the
community
meeting
so.
I
If
you
could,
could
you
be
a
little
bit
more
specific,
like
from
a
governance
point
of
view,
what
what
has
changed?
So
you
know
previously,
there
were
contributors
to
like
the
contributors
haven't
changed
right.
It's
only
that
that
we're
additive
of
like
making
having
more
abound
employees
on
this
of
make
again
like
making
sure
that
this
is
supported
and
the
right
bug
fixes
Etc
are
in
place
mainly
for
our
customers,
but
benefiting
the
whole
community
from
a
governance
point
of
view.
Could
you
specify
like
what
what
the
issue
is?
I.
D
Had
the
feeling
that
some
of
the
guys
asking,
for
example,
if
they
open
much
requests
yeah
if,
if
a
pound
will
go
forward
with
them
or
looking
for
for
other
merch
requests
first
for
their
paid
customers,
This
was
something
they
asked
and
from
the
other
hand,
it
was
more
like
from
from
the
communication
perspective
that
upon
will
directly
it.
It
feels
like
that
upbound
directly
deprecated
the
community
provider
and
released
the
official
ones
without
any
communication
in
the
community.
The
communication
was
from
the
community
perspective.
D
H
No
I'm
just
gonna
say
this:
is
you
and
I
Matthias
had
one
had
a
long
discussion
about
exactly
this?
This
is
what
my
concern
was
all
along
and
you
know
nothing
nothing
from
a
technical
perspective
of
a
governance
perspective.
My
concern
was
exactly
this
from
an
impression
standpoint
right.
The
impression
is
that
provider
terraform
is
being
you
know,
absorbed
by
outbound
and
even
though
I'm
still
a
maintainer
and
Yuri's
still
a
maintainer
and
from
a
from
a
functional
perspective
from
a
process
perspective,
nothing
has
really
changed
and
I.
H
Don't
think
there
are
any
plans
to
change.
You
know
it's
the
it's
the
impression
that
matters
to
the
community
and
so
I
mean
I,
know
you
and
I
talked
and
and
I
apologize.
I
can't
remember
exactly
what
you
said,
but
I'll
ask
the
question
here.
Like
I
asked
a
question
before
so
I
can
hear
the
answer
again.
H
You
know
from
upbounds
perspective.
I
understand
completely
the
need
to
have
full
control
over
something
for
their
customers.
You
know
for
customer
support.
Right
I
mean
you
need
to
have
that
level
of
control,
and
then
you
know
on
the
cross
plain
side,
it's
I
think
it's
worked
really
well
and
I
can
always
say
that
from
the
outside,
in
terms
of
upbound,
maintaining
their
own
Fork
of
cross-plane
and
and
supporting
that
for
their
customers
and
I
know,
you
told
me
why
that
wasn't
considered
for
the
Prov
provider
terraform.
H
You
know
as
well
to
just
have
an
internal
Fork
of
Provider
terraform
for
upbound
to
support.
But
you
know
from
a
again
from
an
impression
of
the
community
standpoint
that
might
have
been
a
better
way
to
go,
but
I'll.
Let
you.
I
No
sure
yeah,
and
thanks
for
for
raising
that
so
again,
apologies
if
the
oppression
has
changed.
So
you
know
that
that's
definitely,
you
know
something
we'll
Circle
back
on
and
and
make
sure
it's
communicated
well
and
I'm,
not
like
so
thanks
Bob
for
for
saying,
there's,
no
technical
or
any
governance
problems
there
that
you
see,
but
again,
if
anyone
right
and
Christopher,
please
send
them
along
or
anonymize
those
right.
I
Those
questions,
if
there's
like
specific
governance,
Pro
like
issues
of
saying
okay,
this
is
like
effectively
going
in
the
wrong
direction
in
the
future.
We
want
to
address
this
right.
This
is
not
about,
like
you
know,
taking
taking
ownership
of
something
that
belongs
to
the
community,
but
rather
saying
okay.
This
is
the
one
that
is
Now
supported
by
by
appbount
and
to
your
question
Bob.
I
We
can
definitely-
and
we
should
right
in
the
community,
discuss
if
a
fork
is
something
that
that
you
know
is
is
feasible
in
the
past
the
the
discussions
we
were
having
and
I'm
I
hope
that
I'm,
reflecting
your
your
your
and
yours,
your
start,
if
you
don't
please
please
disagree.
I
A
fork
was
a
an
additional
complexity
that
we
thought
would
be
more
confusing
than
helpful,
because
at
that
point
you
would
have
two
provided
terraforms
that
you
know
effectively
are
not
are
doing
the
same
thing.
Everyone
that
is
working
on
these
two
forks
would
be
able
to
push
releases
Etc
on
these
two
forks.
I
So
the
the
assumption
is
that
a
forking
would
why,
from
a
governance,
point
of
view
make
you
know,
might
be
a
little
bit
more
transparent
of
what
the
intention
is,
but
from
a
practical
point
of
view,
might
be
more
confusing
again
that
that
that
is,
that
is
the
Assumption
and
kind
of
I
try
to
validate
that
on
the
provided
terraform
side.
If
you
folks
think
this
is
different,
and
you
know
we'll
we'll
make
sure
that
we
do
this
with
the
next
a
couple
of
providers,
especially
kubernetes
and
Helm.
I
If
folks
think
this
is
the
wrong
direction,
well,
we'll
definitely
come.
You
know,
look
into
this
and
see
if
other
options
are
available.
Right.
I
just
want
to
be
very
clear
about
this
right.
These
providers
are
still
apache2
licensed
right.
We
don't
intend
to
change
anything
of
like
how
these
are
governed,
it's
more
of
just
make
making
like
being
transparent
about
that
that
you
know
these
are,
you
know,
are
by
upbound
and
there's
a
major
investment
about
and
for
about
customers
that
they
can
rely
on
this.
I
A
Thanks
for
talking
through
a
lot
of
this
and
addressing
you
know
the
questions
and
concerns
here,
two
two
things
that
I
would
just
want
to
add
onto
that
or
reinforce
onto
it.
More
so
is
that
you
know
one.
You
know
these
type.
This
type
of
decision
is,
it
was
and
should
continue
to
be.
If
it
happens
in
the
future,
a
maintainer
team
decision
right,
it
is
not
a
outbound
exclusive
decision,
it
is
amongst
the
maintainer
team
for
a
particular
repository
or
provider.
A
You
know
if
that,
if
that
maintainer
team,
which
includes
you,
know
people
outside
of
of
one
particular
vendor,
then
you
know
that
team
decides
together.
If
it's
a
move
that
they
want
to
make
to
to
make
it
a
a
beneficial
provider,
the
so
yeah
the
messaging
or
you
know
broadcasting,
or
you
know
just
getting
that
out
more
broadly
yeah.
It
can
probably
be
improved
and
would
be
happy
to
take
feedback
on
on
how
to
do
that
better
in
the
future.
A
As
well
should
this
happen,
but
that's
one
thing:
I
would
want
to
make
clear
that
it
is.
It
is
a
maintainer
team
decision
for
but
a
given
repository-
and
you
know
everyone
has
to
say
in
that.
The
other
thing
I
wanted
to
add
on
and
reinforce
as
well.
Is
that
you
know
going
forward.
You
know
it
is
still.
It
is
an
open
source.
You
know
like
there
are
maintainers
outside
of
a
bound
their
contributions
that
are
accepted
from
the
broader
Community
as
well.
A
So
you
know
I,
don't
think
there
should
be
any
conscious
priority
or
you
know,
preference
or
or
one
commit
or
one
merge
request
over
another.
Like
you
know,
I
we
certainly
should
be
considering
all
those
in
the
spirit
of
the
project.
You
know
what
is
that
project's
focus
and
you
know,
like
you,
know,
set
of
functionality
and
then
does
the
merge
request.
You
know
Jive
when
with
that
and
if
it
does,
then
you
know
it
should
be
accepted
if
it's
at
a
quality
level,
so
there
shouldn't
be.
A
If
anybody
feels
like
they're
not
getting
the
attention,
they
need
on
additions
and
contributions
to
it.
That's
certainly
something
we
want
to
hear
feedback
on
as
well,
because
that's
it's
it's.
The
spirit
of
that
project
is
still
to
be
a
community
contribution
to
it,
and
you
know
people
getting
the
things
in
there
that
the
community
wants
to
see.
So
that
should
still
be
what
we
experience.
C
Yeah,
maybe
to
emphasize
the
fact
for
the
groups
at
the
current
set
of
maintainers
is
not
exclusively
about,
so
I
am
from
a
bound
box
from
Nokia,
so
you
already
have
a
mixed
group
of
maintainers,
and
this
decision
was
done
within
this
group
right
and
I
personally
pushed
for
deprecating
cross-plane
country,
one
for
the
pure
technical
reason
to
not
to
maintain
absolutely
identical
providers
in
two
different
places
have
a
different
pipelines,
running,
builds
and
Community
issues
so
just
to
consolidate
a
single
place.
That
was
the
main
motivation.
A
D
That's
fine
for
me:
I
wanted
to
bring
it
up
from
the
community
perspective,
because
I
had
the
messages
that
was
my
mind,
absolutely
anonymize
the
things
and
can
write
with
Matthias
directly.
What
are
the
concerns
about
and
I
will
update
him.
A
Yeah
cool
yeah
and
then,
like
you
know,
if
you
can
convey
also
that
you
know
our
doors
are
very
open
that
you
know
if
people
want
to
reach
out
directly
to
Matthias
or
myself
like
absolutely
welcome
that-
and
you
know
having
you
know,
we're
more
than
happy
to
have
a
direct,
and
you
know
open
conversation
there
with
anybody
who
ever
wants
to
share
their
voice.
Everyone's
voice
can
certainly
be
heard
around
here.
Yep
awesome,
yeah.
Thank
you.
So
much
for
bringing
that
up.
A
I
really
appreciate
the
discussion
here
and
helping
you
know,
drive
like
the
the
right
right,
transparency
and-
and
you
know,
information
sharing
with
everybody
cool.
So
then
Jean
did
you
want
to
then
cover
the
some
of
the
areas
that
your
team's
gonna
focusing
on.
F
Yeah
sure
so
we
already
touched
on
observe
any
resources
and
composition
functions,
so
I'll
just
mention
that
Our
intention
is
to
to
start
looking
at
the
plugable
external
secret
stores,
design
proposal
that
was
merged
quite
a
while
ago.
You
know
we're
interested
in
implementing
this
functionality,
and
you
know
Esky
will
be
leading
the
implementation
of
that
and
putting
up
a
PR
in
the
near
term.
This
is
not
something
that
will
be
done
in
time
for
111,
so
we
don't
expect
it
to
be
near
ready
for
that.
A
Awesome
that
sounds
like
a
very
exciting
feature
as
well
cool,
so
yeah
a
lot
of
a
lot
of
really
good
things
being
worked
on
with
your
team
there,
and
thanks
for
sharing
some
of
that
and
making
it
making
it
well
known
for
for
everybody
and
then,
once
again,
you
know,
folks
are
more
than
welcome
to
add
to
this
section
too,
for
anything
that
you
know
your
teams
are
working
on.
A
We
can
all
share
that
together
here
in
this
section,
all
right,
so
we
got
a
quick
time
check
yeah,
let's
keep
on
moving,
because
I
think
we've
got
a
couple
of
couple
topics
still
left
here,
so
we
got
a
couple
links
to
interesting
contents
that
folks
have
been
creating
and
building
amongst
the
community.
So
there
are
directs
links,
direct
links
for
all
of
those
articles
and
what
you
know,
white
papers
or
videos
Etc
here
so
feel
free
to
click
through
to
those
and
see
all
of
those.
A
You
know
interesting
bits
of
content,
Hassan,
let's
go
ahead
and
I'll.
Let
you
drive
to
talk
through
the
high
level,
summary
of
the
observe,
only
resources,
feature
design
and
some
of
the
key
key
aspects
of
the
experience
that
you
want
to
share
with
this
group
here
and
get
some
feedback
on
so
I'll
stop
sharing.
So
if
you
want
to
share
your
screen,
you
can
drive
that.
J
Okay,
so
let's
get
this
Yeah,
so
basically,
as
as
Jared
mentioned,
this
is
an
open
PR
waiting
for
reviews
and
I
think
it
will
be
open
for
at
least
like
couple
of
days
or
for
the
next
two
weeks.
I
would
say
so.
I
will
go
through
it
quickly,
like
the
proposal-
and
you
know
the
Alternatives-
that
we
have
this
this
discovered
and
or
discussed
in
the
in
the
document.
J
So
first
I
would
like
to
start
with
the
background,
so
like
people
might
already
like
aware
of
often
of
the
need
for
like
such
an
observer
on
your
read-only
mode
for
cross-plane
managed
resources,
and
in
this
first
background,
section
I
try
to
like
group
them
the
use
cases
and
scenarios
I,
try
to
group
them
and
I
I
would
like
to
quickly
go
over
them.
So
first
group
is
basically
like
referencing
existing
resources
without
managing
them.
J
So
assume
you
have
your
existing
resources
in
managed
by
some
other
tool
or
created
by
like
click
jobs,
and
you
just
want
to
want
to
use
that
together
with
the
cross-plane
resources
by
referencing
them.
So
a
very
good
example
of
this
is
like
you
want
to
give
a
reference
to
an
existing
subnet
from
a
cubitis
cluster
that
you
are
creating
with
crossplay.
The
other
group
is
like
other
than
other
than
referencing.
J
You
want
to
fetch
some
data,
not
the
like
I
want
to
use
this
subnet,
but
it's
more
like
I
need,
let's
say,
cidr
range
of
this
subnet
or
I
need
the
oidc
endpoint
of
this
kubernetes
cluster.
So
this
is
another
group
which
is
fetching
data
from
existing
resources
and
another
scenarios
or
use
case
that
actually
I
I
I
become
I,
became
more
aware
of
like
during
the
design,
write-up
and
getting
some
feedback
or
input
from
the
community
is
actually
like:
gradual
migration
of
existing
resources
to
cross-plane.
J
So,
instead
of
just
creating
a
managed
resource
or
an
existing
resource,
existing
Cloud
resource
by
importing
it
into
cross
plane,
you
immediately
start
managing
it
with
cross
plane,
and
it
is,
it
is
the
like.
There
is
a
desire
to
First
do
this
with
a
read-only
mode
or
in
observe
only
mode,
and
then
after
some
experiments
or
after
some
confidence
level.
You
want
to
change
something
and
start
immediately,
managing
that
Source.
J
J
It
will
have
three
different
policy
options,
which
is
full
control,
which
is
default
one,
and
it
will
behave
as
like
how
how
cross
plane
is
behaving
with
deletion
policy
delete
and
the
other
one
is
similar
to
deletion
policy
orphan
we
have
today
and
for
this
one
we
will
like
we
are
proposing
to
have
a
policy
named,
observe,
create
update,
and
if
this
is
set,
then
we
will
not
delete
the
external
resource
rather
orphan
it
when
the
managed
resource
is
deleted
from
kubernetes
and
the
last
one
is
actually
the
observe.
J
So
this
is
just
a
read-only
mode
that
that
we
are
actually
introducing
with
this
proposal
so
related
to
this,
since
management
policy
and
deletion
policy
will
have
some
like
a
very
close
relationship
and
they
are
actually
controlling
the
same
behavior,
which
is
how
the
the
external
resource
should
be
controlled
or
how
should
cross
plane
behave
to
the
external
resource
when
something
happens
in
the
custom
resource
inside
kubernetes
cluster.
J
So
another
proposal
here
is
to
deprecate
deletion
policy
in
favor
of
management
policy,
so
that
we
can
have
a
like
we,
we
will
be
consolidating
the
policy
which
is
like,
which
defines
this
relation
implementation
wise,
since
the
like
X
current
implementation
of
managed
reconciler
requires
implementing
these
four
resources,
which
is
which
are
observed,
create
update
and
delete.
J
We
believe
it
will
be
straightforward
and
we
will
need
very
needle
changes
on
on
like
per
resource
basis,
and
we
could
just
implement
the
the
functionality
in
the
military
consider
site
like
if
the
policy
is
observed.
Only
then,
instead
of
calling
create,
update
or
delete
simply
return
in
the
reconciliation
Loop
so
that
we
just,
we
can
make
sure
that
we
are
just
calling
to
observe
method.
J
The.
Of
course
we
will
introduce
this
with
a
feature
gate.
It
could
be
something
something
like
enable
Alpha
management
policies
and
I
already
mentioned
the
application
of
tuition
policy.
J
There
are
some
details
on
like
some
conflicting
cases
and
how
we
are
proposing
to
handle
that
this
part
is
actually
important,
because
in
the
original
proposal
issue
there
were
two
possible
options
and
one
was
using
the
same
ERD
with
some
like
annotation
or
or
like
or
parameter,
which
is
the
thing
that
we
are
proposing
here
and
the
main
problem
with
that
is
actually.
This
would
mean
using
the
same
schema
and
this
that
that
will
mean
that
we
will
still
need
to
provide
the
required
parameters
to
just
to
observe
the
resources.
J
So
this
is
actually
a
huge
issue
with
the
previous
like
at
that
time
of
of
The
Proposal
issue
created.
But
now
we
have
a
you
know
in
in
Cross
plane
in
kubernetes
1.295.
There
is
a
feature
which
is
now
a
graduated
to
Beta
And.
It
is
being
able
to
do
some
validation
with
common
expression,
language,
and
this
allows
us
to
instead
of
marking
the
marking
a
field
as
required,
no
matter
what
we
can
now
Define
more
Dynamic
policies,
and
we
can
say
that
if
the
policy
is
observed
only
then
this
field
is
optional.
J
Otherwise
this
field
is
required.
So
this
allows
us
to
solve
that.
That's
like
required,
Fields
problem
and
I
believe
this
will
also
help
with
the
current
way
of
importing
resources,
because
the
same
problem
also
already
was
there
so
important
existing
resource.
You
need
to
provide
all
required
parameters
so,
but
the
the
the
the
problem
with
this
solution
is,
of
course
it
requires
kubernetes
1.25
to
get
the
behavior
or
feature
by
default
and,
as
you
know,
usually
we
don't
have
control
like
users.
J
Don't
have
control
over
API
server,
Flags,
so
I
think
it's
it's
fair
to
assume
that
people
get
this
feature
starting
with
kubernetes
1.295.
So
this
is
also
something
that
worth
mentioning.
J
Another
relevant
points
with
observed
only
is
actually
in
also
in
the
original
issue
we
make
some.
We
mentioned
that
like
terraform,
has
data
sources,
concept
and
cross
plane
needs.
Something
like
that
and
being
able
to
like
get.
J
Data
from
existing
resource
is
already
covered
with
the
proposal,
but
still
telephone
data
sources
says
another
capability
which
I
believe
we
will
also
need
very
similar
capabilities
with
cross
plane
is
actually
you
can
do
some
filtering
and
querying
so
instead
of
just
pointing
like
we
are
talking
about
this
exact
external
resource,
you
could
also
do
some
like.
Okay,
give
me
the
risk
most
recent
Ami
or
give
me
the
default.
J
Vpc
like
this
kind
of
querying
and
filtering
is
already
available
with
terraform
and
I
believe
this
is
very
relevant
to
this
design,
and
also
we
will
need
to
support
that
at
some
point.
However,
supporting
this
in
the
exact
like
using
the
exact
same
way
of
how
telephone
doing
does
not
make
sense
with
cross
plane,
because
we
have
a
one-to-one
mapping
between
the
managed
resource
and
the
resource
it
controls.
So
when
you
do
some
querying
and
filtering,
this
is
not
guaranteed
like
based
on
the
filters
you
have
given.
J
There
could
be
more
than
one
matching
resource:
there
could
be
no
matching
resources
or
the
matching
resource
might
change
in
time.
So
this
is
why
we
like
choose
the
to
to
leave
this
as
a
feature,
because
there
are
some
relevant
work
ongoing
in
in
composition,
functions
which
could
be
leveraged
to
be
leveraged
as
a
potential
solution
and
in
the
documents
I
am
giving
two
options
and
the
conclusion
is
for
now.
J
We
want
to
leave
this
open
as
a
feature
until
we
get
composition,
functions,
feature
landed
and
make
it
a
bit.
So
in
the
meantime,
we
can
get
the
policy
implemented
and
we
can
get
support
for
Observer,
only
resources,
and
hopefully
we
can
tackle
this
querying
and
filtering
at
a
later
points,
and
as
I
mentioned,
the
what
the
the
other
alternative
was
having
dedicated
crd
is
similar
to
terraform
data
sources,
and
I
already
mentioned
that
like
this
is
not
fitting.
J
How
cross
plane
is
modeling,
managed
resources,
and
this
should
mean
introducing
another
type
of
resource
other
than
managed
resources,
which
is
similar
to
what
I
propose
here
in
option.
A.
C
A
Yeah,
nice,
and
thanks
for
watching
us,
do
that
I'm
going
to
open
the
floor
for
at
least
a
couple
minutes
here
on.
If
folks
have
some
questions
or
some,
you
know
reactions
or
good
feedback
that
they
want
to
share
about
what
Hassan
just
walked
us
through.
B
I'll
just
mention
that,
obviously
you
know
I
thought
about
this
and
it's
a
it's
a
really
hard
problem
to
solve,
and
I
really
appreciate
that
you
sort
of
you
know
create
the
sing
channel
list
on,
and
you
know,
listen
to
a
lot
of
people
and
synthesized.
B
A
lot
of
the
background
context
into
this
into
this
proposal
definitely
helps
a
lot
while
reviewing
and
weighing
up
the
options,
and
it's
definitely
not
the
the
I
know
that
that
I've
been
on
one
side
of
the
argument
around
like
whether
there
should
be
separate
resources
or
observed
only
resources,
or
they
should
be
the
same,
and
it's
definitely
not
black
and
white.
So
it's
a
it's
a
challenging
one,
I'm
glad
that
you're
leading.
A
I
said:
did
you
do
you
walk
through
in
the
details
here?
Do
you
walk
through
how
you
know
a
potential
migration
or
upgrades
Etc
happen
over
time
to?
If
you
know,
if
you
do
go
forward
with
removing
deletion
policy
and
replacing
that
by
the
you
know,
superset
management
policy
that
also
encompasses
donation
policy,
that
you
walk
through
like
how
the
exactly
that
migration
would
happen
over
time
and
like
impact
to
you
know
folks,
already
running
in
production,
environments
and
stuff,
like
that.
J
Yeah,
maybe
this
section
of
like
the
application
of
deletion
policy,
might
be
relevant
here.
I
I,
try
to
you
know,
list
all
possible
combinations
of
deletion
policy
versus
management
policy
and
try
to
you
know
answer
like:
should
the
resource
observe
should
the
resource
create,
update
and
delete,
and
obviously
there
are
no
issues
with
observed.
Creator
updates,
but
there
are
some
confusing
or
conflicting
cases
with
Delete
and
observe
only
like
with
deletion.
J
I
would
say,
for
example,
if
deletion
policy
is
deletes
and
management
policies
observe
only
this
indicates
that,
like
according
to
deletion
policy,
we
should
delete
the
external
resource,
but
according
to
management
policy,
we
should
only
do
the
observe.
So
this
is
a
conflicting
case
and
like
the
the
proposal
for
conflicting
cases
is
so
to
not
to
delete-
and
this
is
both
to
air
on
the
side
side
of
caution
not
to
like
delete
the
resources.
J
While
the
intention
is
not
that,
but
also
if
we
say
that
like
for
conflicting
cases,
we
will
do
the
non-default
behaviors.
It's
also.
It
turns
out
to
be
also
a
no,
which
means
like
here.
The
non-default
policy
is
observed
only
and
we
will
not
delete,
and
here
the
non-default
policy
is
Orphan
and
we
will
not
delete
Etc,
so
I
I
feel
pretty
good
about
the
you
know,
migration
or
or
you
know,
deprecation
of
deletion
policy
and
I.
J
Don't
expect
you
know
too
much
issues,
but,
of
course
it's
open
open
for
feedback
and
I
would
appreciate.
If
others
put
some
thought-
and
let
me
know
if
I'm
missing
something.
B
This
is.
This
is
less
of
a
concern
about
this
proposal
specifically,
and
why
a
general
observation
that,
as
we
change
things
in
these
resources,
that
we'd
like
to
be
one
beta
one,
we
are
accruing
a
couple
of
fields
like
at
least
three
now
on
on
every
managed
resource
that
are
deprecated
and
that
we
don't
have
an
immediate
plan
to
actually
remove,
because
removing
a
field
would
be
a
breaking
change.
So,
for
instance,
I
hope
this
is
a
really
old
one.
B
But
when
we
added
provider
configures
type
we
actually
used
to
have
a
type
or
provider
for
each
provider.
It
was
different
from
the
package
type
provider
and
it's
actually
still
supported
and
it
exists
there
as
a
field,
and
we
have
to
have
logic
in
cross-plate
so
that
if
someone
who's
been
using
cross
plane
for
100
years
sets
that
field
we
we
honor
it.
B
Similarly,
with
secret
stores
being
added,
we,
you
know
deprecated
what
we
probably
will
deprecate
the
right
connection
secretary
Redfield
and
introduce
a
new
field
there
and
I
think
that
new
field,
in
my
opinion,
is,
is
much
better
I
like
the
design
of
a
new
API,
a
lot
more
there.
You
know
in
this
case,
I
I,
like
the
I
think
I,
like
the
design
more
but
I
I,
don't
love
that
there
would
still
be
a
deletion
policy
there.
B
With
this
new
policy,
we
would
have
to
figure
out
the
relationship
between
the
two
of
them.
I
have
a
bunch
of
code
to
handle
both
of
them,
so
I
I,
I'm,
hesitant
to
add
more
blockers
to
this
proposal,
but
I
am
starting
to
feel
like
I'd
like
to
understand
what
does
it
mean
when
we
deprecate
these
things?
When
are
they
actually
going
to
go
away
so
that
we
don't
have
to
support
them
anymore?
B
You
know
I
can
imagine
they're
not
going
to
go
away
until
we
delete
the
V1
beta1
apis,
effectively,
I,
guess
or
maybe
get
to
a
point
where
we
say
the
field
will
exist.
For
so
that
you
know
you
can
submit
a
document
that
has
it,
but
it
doesn't
do
anything
anymore.
We
don't
actually
honor
its
content
or
whatever.
J
Yeah
I
I'm
I'm,
not
sure
I
I
didn't
put
enough
thought
on
that.
But
do
you
think,
if,
like
having
a
a
conversion,
web
hook
could
be
helpful
here
like
immediately
dropping
to
deletion
policy
and
then
providing
a
conversion
web
hook
so
that
we
can
get
rid
of
the
the
old
policy
or
Old
Fields
sooner
than
later,
I.
B
Don't
know
if
I
think
a
conversion
web
hook
would
require
us
to
introduce
a
new
version
right,
so
the
conversion
web
hook
would
mean,
if
I
understand
correctly,
that
let's
say
a
particular
resource.
When
we
add
this
new
feature
is
ADD
B1
beta1
I
think
that
the
recent
conversion
weapon
would.
D
B
Would
be
we
could
introduce
V1,
beta,
2
or
V1,
or
something
like
that
and
that
could
have
a
management
policy.
V1
beta1
would
not
get
a
managed
policy.
That
feature
would
not
be
enabled
there
and
we
would
translate
deletion
policy
into
the
into
the
management
policy.
That
would
I
think
could
be
better
because
then
the
newest
version
of
the
API
would
only
have
kind
of
a
new
way
of
thinking,
rather
than
having
all
the
old
deprecated
baggage
there.
So
yeah,
that's,
perhaps
just
something
we
could
do.
B
I
personally
want
to
Noodle
on
this
management
policy
field
a
little
bit
at
the
moment.
It's
like
the
like
observe,
create
update,
feels
a
little
less
intuitive
to
me
than
just
like
what
should
I
do
when
you
delete
this
managed
resource.
Maybe
it's
because
I'm
too
close
to
it,
I've
been
using
people
for
a
long
time,
but.
A
Okay,
cool
so
yeah,
so
I
think
so
yeah
Hassan
thanks
very
much
for
walking
us
through
this
and
kind
of
getting
us.
You
know
getting
this
topic
warmed
up
for
us
and
so
yeah.
Obviously
there
will
be
more
feedback
and
discussion
and
we'll
follow
up
basic
on
it,
but
yeah.
Thank
you
very
much
for
for
introducing
it
to
us
today
and
so
yeah.
A
Feedback
from
everybody
is
certainly
welcome
on
that
pull
request
and
there's
a
link
in
the
agenda
doc
directly
to
it
so
I
wanted
to
if
we're
running
out
of
time
here
so
I
wanted
to
maybe
see
if
we
could
quickly
hop
to
Pete,
because
I
know,
Pete
has
a
topic
that
he
wanted
to
bring
up,
and
there
have
been
some
previous
discussion
on
it
as
well
about
moving
the
the
docs
out
of
the
core
crossbane
repo.
A
E
I,
don't
have
anything
to
share
I'll.
Just
talk
a
little
bit
start
talking
all
right,
so
one
of
the
things
that's
been
kicked
around
is
moving
the
docs
so
background.
Just
for
the
fullness
of
things.
E
The
way
documentation
is
generated
today
is
everything
lives
within
the
cross,
plain
repo
cross,
Plain
Cross
plane,
and
then
there
are
automations
that
then
sync,
the
docs
folder
from
crosswind
Crosspoint
to
cross
plain
slash
Docs.
That
docs
repository
is
what
is
actually
posted
on
the
web
and
hosted
so
there's
this
multi-step
process
that
happens
as
a
result.
There's
some
we
lose
some
things
like
the
ability
to
look
at
deploy,
previews,
which
I
mentioned
in
this
issue.
So
you
can't
look
at
a
rendered
version.
E
E
So
what
I'm
thinking
about
doing
is
moving
all
the
documentation
so
that
it's
it's
root,
source
of
truth,
there's
only
one
place
and
that
place
is
the
docs
repo.
So
all
the
docs
level
one
place
you
know
there'll
be
linkage
in
whatever
form
from
cross-playing
Cross
plane
to
that
repository.
So
folks
are
aware
of
it,
but
it
removes
a
lot
of
the
Machinery
that's
required
today.
For
that
publishing
process.
E
A
Pete,
did
you
have
a
sense
of
the
any
major
feedback
or
pushback
that
was
was
given
for
this
was
like
versioning?
You
know
making
sure
that
the
docs
are
versioned
along
with
like
code
releases
smoothly.
Was
that
something
that
was
that
brought
up
and
already
addressed
or.
E
E
So
the
docs
folder
in
Branch
release
1.9
maps
to
the
folder
1.9
inside
of
the
docs
Repository
right.
So
every
every
Branch
ends
up
kind
of
combining
down
to
the
same
place
that
that
doesn't
change.
So
every
version
of
crossblind
that
has
documentation
will
have
its
folder
in
the
docs
repository
like
it
would
like
it
does
today.
C
So,
when
I
create
a
PR
and
like
back
to
our
previous
discussion
on
our
environment,
config
specific
documentation
like-
and
so
we
ask
to
include-
usually
we
ask
to
include
documentation
together
with
the
new
feature
like
we
adding
a
new
patch
type.
We
want
documentation
for
this
new
functionality,
so
how
it
will
look
like
after
this
change
is.
E
Something
to
Jared's
point
I
mean
the
biggest.
The
biggest
concern
that's
been
raised
primarily
by
Nick,
has
been
that
that
process
changes
a
PR
will
be
open
against
the
docs
repository
for
that
documentation,
and
then
it's
up
to
all
to
determine
how
you
want
to
link
to
that.
E
You
know:
do
you
want
to
reference
it
in
the
issue?
Do
you
want
to
reference
at
the
pr?
Do
you
want
to
treat
them
as
asynchronous
things?
I
think
that's
about
the
source
maintainers,
but
the
main
thing
is
around
getting
the
visibility
and
you
know
really
moving
out
of
markdown
based
documentation,
review
and
moving
towards
Rich
rendered
documentation,
review.
C
Thank
you
just
like.
Can
we
keep
like
a
developer
set
of
documentation,
so
it
will
be
like
closely
bound
to
the
PRN
code
functionality
and
then,
like
a
extended
version
of
it,
should
go
to
like
to
separate
triple
I'm
concerned
with,
like
losing
part
of
the
documentation
when
we
totally
split
the
process.
E
I,
don't
have
any
objections
to
that.
You
know
if
there
is
a
desire
to
do
a
sinking
from
cross-plane
Cross
plane,
you
know
to
the
docs
or
you
know,
mirror
back.
That's
fine
with
me
to
me.
The
big
thing
is
the
docs.
H
H
H
E
Yeah
so
part
of
this
is
you
know,
separating
these
out
not
to
make
your
the
lives
of
the
developer
harder,
but
to
kind
of
create
two
fault
domains.
If
you
will
right
because
for
me
to
make
changes
to
documentation
requires
me
making
changes
to
the
crosswind
Repository
and
you
know,
I
would
like
to
not
do
that.
E
H
E
E
It
makes
it
much
more
complicated
to
do
something
like
that,
because
there's
no
branching
within
the
docs
repo
itself
and
one
of
the
things
that
I'm
trying
to
solve
for
is
fixing.
It
is
a
very
common
thing
to
find
something
that
needs
to
be
fixed
in
multiple
versions,
and
it's
it's
a
huge
hassle
to
do.
E
A
Yeah,
so
we're
we're
running
out
of
time
here
that
so
that
this
conversation
will
have
to
you
know
continue
like
so
next
steps
like
what
are
you?
What
are
you
looking
for?
Do
you
want
some
of
this
feedback
to
be
added
to
this
issue
here,
like
we,
we
keep
that
going.
Is
this
the
right
forum
for
the
feedback.
E
Yeah
I
would
say
if
you've
got
additional
comments
or
concerns.
Please
add
them
to
the
issue.
If
we
need
to
have
a
you
know,
I'm
happy
to
jump
on
and
talk
in
depth
with
some
folks.
You
know
I
know
I've
had
a
couple
of
those
conversations
already
happy
to
talk
some
more.
E
A
Yeah
and
I
do
like,
like
you
know,
consolidating
my
preference
would
be
like
if
we,
if
we
do
move
them
like
to
do
the
wholesale,
don't
like
still
keep
some
docs
over
there,
because
that
doesn't
address
this
at
all.
Then
you're
still
kind
of
confused
about
where
do
I
put
docs
so
and
I
like
I,
like
the
benefit
of
having
it
all
in
one
place
and
not
having
you
know,
because
we
see
that
error
happen
all
the
time,
but
people
go
edit.
The
docs.
A
You
got
to
edit
the
other
docs
and
then,
like
preview
stuff
is
really
actually
a
nice
functionality
as
well
so
yeah,
okay.
So
let's
keep
this
conversation
going
in
here
and
try
to
drive
to
a
resolution
of
it
and
thanks
for
thanks
for
driving.
This
still
Pete
really
appreciate
that
man.
Thank
you,
okay,
so
yeah!
So
we're
out
of
time
here.
A
So,
let's,
let's,
let's
maybe
dive
into
this
one-
a
little
bit
further
next
time
but
I
did
want
to
put
out
a
call
to
people
of
you
know
we're
trying
to
there's
there's
some
thinking
going
around
about.
How
can
we
improve
the
overall
experience
like
developing
building
platforms?
A
You
know
kind
of,
like
all
sorts
of
issues
that
people
run
into
with.
You
know
silent
errors
or
you
know
challenging.
You
know
authoring
compositions
whatever
it
is
so
there's
definitely
some
you
know
like
want
to
do
some
crowdsourcing
around
that
to
see
like
what
are
people.
What
are
issues
that
you
guys
are
running
into
with
building
your
own
platforms,
then
we
can
maybe
kind
of
put
that
into
a
single
effort
where
we
squash
a
lot
of
those
bugs
out.
A
So
that's
definitely
open
for
people
to
comment
on
as
well
and
then
with
that
I
guess:
I
think
maybe
you're
gonna
go
ahead
and
go
ahead
and
wrap
it
up
here.
So
quick
note
that
let
next
week
our
next
time
is
canceled
for
the
holidays,
so
we
won't
see
each
other
in
this
forum
until
early
January,
but
we'll
be
online
in
asynchronous
conversations
over
slack
and
hope.
Everyone
has
a
great
wonderful
holiday
season
and
good
to
see.
Everybody
today
take
care.
Everybody
bye-bye
cheers,
but.