►
From YouTube: Kubernetes SIG CLI 20190327
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
Okay
good
morning
to
know
anyone
where
you
are
welcome
to
another
six
CLI
meeting
its
March
27th.
My
name
is
Matty
and
I'll,
be
your
host
today,
so
I'm
gonna
start
with
the
announcements
our
6cl.
I
got
two
slots
during
cube
upcoming,
cube
con
europe.
In
barcelona
we
will
be
doing
a
sick,
intro
and
sick
deep
dive.
Most
probably,
the
intro
will
be
devoted
to.
A
Introduction
to
code
of
cube
CTO,
because
I've
been
approached
several
times
by
a
lot
of
people
that
I
would
like
to
have
some
kind
of
introduction.
So,
instead
of
introducing
the
sake,
we'll
actually
go
and
introduce
the
code
behind
the
sick.
I
hope
that
the
recording
from
that
session
will
be
helpful
to
to
all
the
newcomers
to
the
sexy
li.
A
As
for
the
deep
dive
salon,
I
agreed
that
we
would
like
to
cover
customized,
especially
that
we
landed
customized
as
part
of
pube
CTL,
and
there
appears
to
be
tons
and
tons
of
questions
with
regards
how
to
use
customized
and
I'm
pretty
sure
that
that
that
will
be
helpful
for
others
as
well.
There's
also
one
question
that
I
have
to
the
majority
of
the
folks.
There
is
an
option
to
have
face
to
face
meeting
during
contributors
summit
during
cube
con
and
I'm
wondering
whether
we
are
interested
in
having
such
a
face
to
face.
B
A
Okay,
oh
sure,
to
sign
us
up
for
that
one.
In
that
case,
okay,
moving
on
to
the
another
announcements,
master
is
open
for
1:15,
since
we
release
114
just
yesterday,
so
congratulation
to
all
of
us
for
releasing
such
an
amazing
114
release.
We've
had
lots
of
accomplishments,
including
customized,
including
plugins,
in
unstable
and
tons
and
tons
of
fixes
and
improvement
to
the
QC.
Do
one
last
final
announcement
is
the
API
review
process
is
being
currently
updated.
A
I've
linked
the
the
document
describing
the
new
process
in
the
agenda,
make
sure
that
you
note
and
follow
the
process
whenever
you
will
be
introducing
any
kind
of
API
changes
for
cube
CTL.
That
includes
both
new
commands
old
commands,
deprecation
of
commands,
as
well
as
flags
so
we'll
have.
We
have
to
follow
the
that
particular
process
in
in.
B
A
We
should
be,
and
we
will
be
trying
to
review
those
I'm,
pretty
sure
that,
both
though
and
I,
we
were
very,
very
good
at
respecting
the
guidelines
that
are
for
for
moving
and
deprecating
commands
and
flags
and
we've
haven't
had
complaints
other
than
why
you
are
removing
a
flag.
But
nobody
complained
about
the
process
itself.
A
So
I
I'm
pretty
sure
that
we're
in
a
safe
position
for
that
one
at
least
we
just
need
to
ensure
that
we
do
follow
the
the
rules
for
deprecating
the
clacks,
because
that's
usually
the
biggest
tension
points
for
when
you
are
dropping
supports
for
whatever
kind
of
even
almost
barely
used
feature
or
whatever
how
it
doesn't
matter
how
broken
it
will
be.
There
always
will
be
people
complaining
that
you
are
removing
the
future,
even
at
the
point
when
you
just
start
deprecating
it.
A
C
A
A
We
need
to
ensure
that
keeps
detail
works
only
with
the
external
api's,
which
conflicts
with
what
revert
to
us
and
survive
has
a
problem.
We
will
turn
convert
into
a
plug-in,
even
though
we
deprecated
it.
We
will
just
ensure
that
it
is
packaged
together
until
1:17
and
whatnot
and
then
at
some
point
in
time
we
will
just
when
the
deprecation
passes,
we
will
cut
it
and
then
people
will
will
still
be
able
to
use
convert,
but
convert
then
will
be
just
a
plugin
like
any
other.
Oh
think.
A
A
A
B
B
That's
contentious
the
the
bigger
question
I
think
is
just
like:
how
do
we
going
forward
do
plugins
that
are
even
executables
or
go
plugins
or
whatever
it
is,
but
it's
like
invoking
arbitrary
code
in
some
form
or
another-
that's
not
restricted
to
like
something
we
know
is
safe.
How
do
we
enable
this
in
a
declarative
fashion,
while
ensuring
that
users
who
run
in
untrusted
could
customize
build
the
customized
build
some
untrusted
source
because
they
don't
expect
it
to
do
anything
and
they
just
kind
of
want
to
see
like
what
would
happen?
B
What
would
it
output
don't?
Donut
I'm
intentionally
end
up
running
having
it
run,
commands
on
their
system,
and
so
the
ways
to
address
this
are
two.
The
first
is
by
default.
It's
secure,
there's,
no,
there's
nothing
that
the
plug-in
mechanism
can
exec.
A
user
has
to
actually
link
to
a
plug-in
or
define
a
path
to
plugins
that
can
be
invoked,
and
this
means
like
in
the
naive
case,
it's
impossible
to
exploit
user,
has
to
set
up
their
environment
in
a
way.
That's
exploitable.
B
You
have
to
provide
a
flag
to
basically
enable
these
things,
and
if
you
run
it
without
the
flag,
it
will
just
spit
out
the
commands.
It
was
going
to
run
and
then
exit
with
a
failure,
and
then
that
way
it
allows
organizations
basically
just
set
this
flag
for
their
CI
CD
systems
by
users
can,
if
they
just
run
the
command
without
providing
the
flag,
will
see
exactly
what
it's
gonna
do
and
they
can
go
out
those
things
and
if
there's
no
plugins,
it
will
just
see
some.
B
B
A
B
A
So
I
read
to
the
cap
earlier
today:
sorry
for
being
late,
my
only
concerns
is
around
the
enable
plugins,
but
because
of
hurt,
there
are
two
actually
concerns.
One
is
with
regards
to
the
environment.
Variable
I
would
strongly
discourage
using
environment
variable
because
it's
very
easy
to
ensure
that
user
has
the
environment
variables
set,
and
that
will
also
hide
the
fact
that
you
are
running
the
the
plugins
with
the
plugins
enabled
and
they
wanna
the
other
one
was
like.
A
It
is
also
like
moderately
simple
to
have
the
enable
plugins
being
part
of
analogous
to
customize
or
cube
CTO,
and
then
I
will
basically
means
that
whenever
I'm
running
customizer
keep
CTL,
the
enable
plugins
will
be
always
there
and
I
will
not
get
the
error.
But
if
you
are
requiring
both
enable
plugins
and
plugin
path
to
met
to
be
on
and
the
plugin
path
actually
has
to
match
the
the
plugins
which
I
probably
missed
from
reading
the
cat,
then
I
think
I'm
I'm.
Okay,
with
that
approach,
there's.
B
A
plugin
path
or
a
default-
something
that's
empty
right
by
default,
so
usually
doesn't
have
to
specify
the
path
and
enable
like
they
just
have
to
drop
the
plugins
into
like
slash
user,
local
custom,
I
use
our
local
customized,
plugins
key
value
sources,
or
something
like
that.
There's
another
one
that
uses
a
Linux
environment
variable
for
where
configuration
to
search
for
configuration
of
this.
A
B
That's
the
one
so
I
think
like
I,
do
think
having
both
where,
like
we're
trying
to
optimize
here
for
like
the
individual,
who
accidentally
runs
a
command
against
an
untrusted
source
right.
They
know
it's
untrusted
and
they
accidentally
run
the
command
against
it
or
are
unaware
that
they
have
plugins
installed.
B
That
are
exploitable,
so
I
think
just
telling
users.
You
know
if
you've
read
the
documentation
enough
to
know
that
you
have
to
specify
the
flag,
or
rather
the
air-condition
should
say
before
you
specify
the
flag,
if
you
don't
specify
a
flag,
like
only
do
this
for
trusted
sources
and
spit
it
out,
so
I
think
the
bar
we're
trying
to
make
harder
than
is
convincing.
B
The
euros
are
to
curl
and
abash
and
I
think
this
is
significantly
harder
than
convince
me
user
to
curl
into
bash
because
they
have
to
like
download
and
install
or
symbolic
link
files
on
their
local
file
system
and
then
specify
this
flag,
and
it's
audible
like
curling
in
the
bash.
You
can't
really
awed
it,
but
this
should
like
just
have
a
list
of
things.
It's
gonna
execute
the
environment
variables
of
Farpoint
I,
put
that
under
in
graduation
current
areas.
Things
to
consider
so
I
mean
remove
that
I.
A
A
Why
not
having
that
and
the
cube
CTO
version
of
customize
also
maybe
as
a
follow-up
questions
that
I
want,
is
how
far
they
wanna
diverge
custom
the
default
customized
from
the
one
supported
and
keeps
video,
because
I
know
we
we
are
diverging.
Some
functionality
are
we:
where
do
we
diverge
so
far?
I
think
where
we
have
a
limited
of
I,
maybe
not
the
core
functionality,
but
we
don't
support
there.
The
full
support
is
not
there.
I
think
you
had
you
can
have.
You
can
do
much
more
with
customized
default
than
the
one.
A
B
C
A
B
Thing
I
can
remove
the
thing
about
the
environment.
Variable
I
think
a
lot
of
this
stuff
like
if
we
just
leave
it
out
like
the
environment,
various
stuff
like
users,
will
either
ask
for
it
and
have
a
good
reason
for
it
or
they
won't
or
will
talk
to.
You
know
people
at
conferences
and
find
out
more
about
that.
A
A
Probably
the
probably,
via
the
environment,
variable
the
fact
that
it
is
always
off
it's.
A
trout
is
definitely
a
good
approach
versus
to
what
we
had
before
head
and
that
will
also
address
the
problem
of
go
plugins
that
it
was
introduced
for
a
secret
generation.
Some
time
ago,
also
I'm
wondering
whether
we
are
going
to
support
both
the
plan
is
to
support.
B
A
B
The
end
no
plugins
have
nice
properties
you're
doing
get
offs
and
building
this
into
a
container
I
think
the
major
concerns
about
Co
plugins
were
one
like.
Oh
my
gosh
like
if
I
develop
a
bargain
marketplace
and
build
the
plugin
over
here
and
try
and
use
it
with
this
one.
It's
not
going
to
work
and
that's
not
the
intended
use
case.
Then
the
hinted
use
cases
for
organizations
to
build
distributions
of
customized.
B
They
build
in
containers
and
one
as
part
of
it
adopts
without
forking
it
and
there's
like
an
actual
real
organization
that
wants
to
do
exactly
this
isn't
as
contributing
the
feature.
So
that
seems
proof
enough
to
me
that
it's
about
and
they're
willing
to
maintain
it.
The
other
one
was
oh,
my
gosh.
This
doesn't
work
on
Windows
I.
Think
the
same
comment
applies
here
like
this
is
for
organizations
building
platforms
with
customizing
their
own
distributions,
which
we're
seeing
more
and
more
of
like
air
B&B.
B
Just
did
this
long
thing
about
have
to
have
to
build
a
platform
like
it
seems,
like
every
big
organization
actually
ends
up
needing
to
build
a
platform,
and
so
the
ability
to
support
the
point
to
integrate
our
tools
in
the
platform's
is
actually
I.
Think
a
first-class
problem
that
we
need
to
be
considering
so
yeah
this.
This
will
address
the
concerns
with
go.
Plugins
I
think
we
still
went
to
support,
go
plugins
as
an
alpha
feature
with
the
I
think
it's
guarded
with
a
flag
of
like
oh,
my
god.
You.
A
B
Right
this
is
significantly
more
ambitious
than
the
secret
general
plugins,
but
relies
on
a
lot
of
the
conventions
around
plugins
in
general,
from
a
secret.
Everyone's
I
think
this
is
I.
Just
talked
about
like
allowing
people
to
build
platforms
as
kind
of
something
we're
seeing
more
and
more
demand
and
I
talked
to.
It
seems
like
every
week
I'm
talking
to
someone
who's.
Forked
could
control
code
to
build
their
own
platform
because
it
didn't
quite
do
exactly
what
they
needed,
but
like
the
core
logic,
was
there
right
and
knowing
people
are
gonna?
Do
this,
like?
B
Oh,
like
I,
don't
think
like
we
were
thinking
about
plugins
in
an
imperative
way
of
how
do
we
allow
marketplaces
to
develop
around
people
building
CRTs,
and
this
sort
of
thing
is
like
the
extension
first-class
case
unless
thinking
about
like
more
advanced
folks
who
are
like
going
to
build
their
holistic
suite
their
paths.
If
you
will
problem,
you
know
the
kubernetes
raw
genetic
material.
B
B
What
it
does
is
it
reads
in
some
customization
file,
which
is
what
I'm
calling
a
virtual
resource.
It's
not
a
real
resource
like
it's
applied
to
the
cluster,
but
it
defines
or
it's
a
meta
resource.
If
you
will,
it
defines
how
other
resources
are
cut,
generated
or
transformed,
and
so
we
generalize
this
and
say:
ok,
essentially
generator
functions
that
taking
some
other
some
virtual
resource
and
generate
an
actual
resource
format
or
multiple
resources
from
that
virtual
resource.
B
But
when
you
look
at
a
lot
of
the
stuff
in
the
ecosystem,
they
there's
a
lot
of
interesting
tools
out
there.
That
could
also
serve
as
generation
sourcing
right.
So
a
helmet
art
could
be
a
generator,
for
instance,
wearing
take
a
row
home
chart
or
you
find
a
kubernetes
api
that
has
a
path
to
a
helmet.
Art
has
some
values
of
path
to
values,
file
or
values,
embedded
in
it
and
could
generate
resources
from
a
helmet
art.
B
This
would
be
using
the
same
mechanics
that
customized
uses
generate
secrets
just
with
an
API
defined
by
the
organization
right,
and
this
is
inspired
by
stuff
like
I.
Think
here
being
these
I
mean
where
they
said,
we
need
higher
level
abstractions
and
they're,
defining
their
own
in-house
tooling,
for
generating
those
abstractions
helm
parts
as
proof
that
there's
need
for
higher
level.
Abstractions
Jason
nets,
proof
for
this
for
her
little
attractions.
So
we
know
the
ecosystem
wants
these
higher
level.
B
Abstractions
know
that
our
tools,
work
resource
can
think
only
and
we
know
we're
not
going
to
find
our
own
high
level
abstractions
like
that
is
not
we're.
Not
gonna
go
to
find
a
language,
that's
kind
of
what
the
ecosystem
is
doing.
How
do
we
make
it
so
the
ecosystem
can
work
better
with
the
tools
we're
building
right.
B
The
people
who
are
solving
this
problem
and
why
we've
said
oh
well,
you
can
pipe
them
together
right,
but
we
know
that,
like
piping,
isn't
the
best
solution
for
a
number
of
reasons
it
doesn't
have
great
UX
were
comparatively
if
you
can't
just
drop
UML
config
and
update
a
number
of
resource
files
and
then
have
it
just
work.
You
need
to
like
update
your
build
and
releasing
the
boisterous
which
might
live
in
a
different.
You
know
and
that
sort
of
stuff
auditing
doesn't
work
the
same
way
on
it.
B
You
want
to
build
your
developing
tools
around
lending
and
auditing
config,
and
now
you
have
this
imperative
stuff.
That's
trapped
the
config
in
there
and
you
can't
really
access
it.
So,
for
these
reasons,
I
think
generators
make
a
lot
of
sense,
o
allowing
the
abstraction
layers,
or
rather
the
tools
for
helping
abstractions
and
this
sort
of
stuff
developed
by
the
ecosystem
to
be
plugged
in
declaratively
warmers.
B
Similarly,
have
natural
next
step
for
this,
where,
if
it's
generating
resources
that
have
names
that
are
changing,
that
the
names
themselves
are
generated,
so
you
can't
know
ahead
of
time
what
the
name
is,
because
it's
based
off
the
resource
that
gets
generated.
You
need
a
way
of
referencing
those
potentially
like
we
do
with
secrets.
How
do
we
then
make
sure
those
references
get
updated?
Well,
those
are
where
the
transformers
come
in.
B
Another
thing
that
be
useful
for
transformers
right
is
sto,
for
instance,
has
to
inject
sidecars
and
I.
Think
they're
used
server-side
web
hooks
for
this
now,
which
is
a
decent
solution.
We've
heard
I
think
lyft
uses
customized
for
this
purpose.
I
think
there's
a
lot
of
good
reasons
for
doing
or
doing
any
customized
one
is
that
it's
a
lot
easier
to
review
and
it's
a
lot
easier
to
audit,
and
the
second
is
when
review
in
customized
is
actually
more
centralized
for
certain
platforms.
B
Right,
you
think
about
a
multi
cluster
world
means
that
maybe
you're
deploying
to
six
different
clusters
right
and
each
one
of
the
six
different
clusters
has
to
have
those
web
hooks
installed,
and
they
all
have
to
be
installed
exactly
the
same,
and
if
one
is
installed
a
little
differently,
then
you
don't
actually
have
consistency
between
clusters.
Where
is
it
it's
in
a
centralized
place
with
the
customization
it
gets
deployed
to
all
these
involve
plus
they're
exactly
the
same,
this
is
kind
of
inverting,
the
actual
impact
of
like
client.
B
If
you
will
and
server
where
the
client
is
now
running,
the
server
as
a
get
ops,
a
part
of
a
platform,
and
so
it's
now
in
the
server
and
the
different
clusters
themselves
are
there's
now
many
of
them
right.
So
you
can't
just
have
a
centralized
server
completely
well,
but
those
are
kind
of
the
thoughts
that
gone
into
this
again.
It's
a
lot
more
ambitious.
For
those
reasons,
it's
intentionally
restricted
a
lot
in
terms
of
what
it
does
there's
a
lot
of
comments
about.
Why
are
we
being
too
restrictive
here?
B
A
B
Yeah
he's
talking
to
Jeff-
and
it's
like
this-
is
like
a
week-long
project
for
customized.
Write
in
terms
of
code
like
it
is
customized,
is
always
structure
already
structured
in
the
way
like
this.
All
your
mechanism
is
literally
just
wiring
the
plug-in
mechanism
into
the
crystal
structure
customized.
So
we
were
fortunate
in
that.
That's
about
that's
cool
are.
B
Like
I
plan
on
implementing
a
helmet
art
plugin
that
allows
you
to
plug
in
helm,
charts
directly
into
control
in
a
declarative
way
and
plan
on
implementing
an
sto
one
that
allows
you
to
inject
sidecar
containers
in
declarative
way.
Where
are
there
viewable
and
gifts
at
a
time
inaudible
during
the
review
process?
Has
they
commuted
to
use
cases
I'm.
B
That's
true,
I
think
well,
helm
is
like
a
lot
of
so
helm
is
a
platform
right
and,
and
specifically
the
generating
abstractions
piece
is
kind
of
the
piece
I'm
more
interested
in
I'm,
less
interested
in
the
rest
of
the
platform
of
helm,
you're
right,
it
will
not
be
a
complete
embedding
of
helm
in
the
control.
I,
don't
think
that's
in
scope
or
anything
we
want
to
pursue
I
can
imagine
I.
Think
it'd
be
interesting
to
me
to
see
like
lifecycle,
hooks
and
abstractions
as
charts
as
separate
layers
that
are
composable
right.
B
You
can
imagine,
like
you,
can
imagine
wanting
lifecycle
hooks
without
having
to
write
a
Helmut
art,
because
you
are
you
just
want
to
have
lifecycle
hooks
for
your
declarative,
configure.
You
can
imagine
Helmut
charts
without
lifecycle,
hooks,
so
I
think
it'd
be
interesting.
I
think
this
is
also
step
and
maybe
making
it
possible
to
have
all
the
current
options
for
those.
D
One
of
the
things
I'm
finding
challenging
is
is,
when
you
make
one
change
that
many
things
depend
on
so
like
scaling.
A
stateful
set
I've
got
to
change
the
pod
disruption
budget,
better
change
the
stateful
set
I
may
have
to
change
other
things.
So
that's
something
where
I
can
do
like.
Could
customize
become
composable
where
there's
a
meta
object,
I
can
change,
and
then
the
transformer
can
produce
new
objects
that
in
ingests,
which
have
those
sort
of
in
number
yeah.
B
Both
of
those,
so
this
would
allow
you
to
do
that
in
two
ways
and
I
mean
like
we
are
gonna,
learn
a
lot
about
what
works
in
terms
of
usability
like
there's
power,
and
we
can
do
like
give
you
raw
power
to
do
like
the
most
insane
things
possible
like
we
can
give
you
go
twos
and
then
there's
like.
What's
understandable,
the
two
ways,
I
can
imagine
doing
what
you
just
described.
The
first
is
you
define
a
new
virtual
API
resource
right
and
it
defines
a
high-level
abstraction
of
whatever
it
is
you're
trying
to
generate.
B
B
That
would
be
introducing
an
abstraction
layer
which
would
potentially
reduce
visibility
into
you
know
what
the
authoring
aspects,
however,
would
maybe
provide
better
code,
reuse
and
those
would
be
visible
with
the
diff.
The
alternative
is
to
do
a
transformer
right
where
you
say
this
field
you
we
sent
one
of
those
fields
right.
So
an
example
of
something
I
could
imagine
I
I'm,
not
that
familiar
with
your
specific
use
case,
but
I
think
something
similar
would
be
like.
B
Java
keep
like
memory
for
heap
and
perm
Djinn
and
resource
allocations
right
each
one
of
those
things
impacts
one
another,
or
rather
those
things
have
to
be.
You
can
configure
those
collectively
in
a
bad
way
right
and
you
might
want
to
generate
the
resource
allocation
by
just
summing
to
keep
the
the
memory
resource
allocation
for
the
container
by
something
to
keep
in
the
perm
Djinn
and
adding
some
extra
in
there.
B
Whatever
your
formula
is:
that's
an
a
single
resource,
a
transformer
then
they'd
be
like
multi
resource
transformers
right
where
you
want
to
set
there's
some
relationship
between
services
and
the
things
they
select
and
their
labels,
and
you
want
to
add
labels
to
a
selectors
for
some
reason:
I,
don't
know
and
I'm
kind
of
making
things
up
here.
But
yes,
I
can
imagine
you
looking
at
somebody
sent
in
the
service
and
then
updating
upon
template.
B
D
Like
I've
I
just
recently
finished
putting
a
lot
of
stuff
and
customized
like
10,000
lines
of
the
ammo,
and
some
of
those
things
were
pretty
repetitive
and
I.
Think
that
you
know
the
disruption
budget
was
stateful
set
is
a
good
example.
The
Java
config
one
is
another
great
example
where
there's
a
right
answer:
I'd
like
to
have
configured
one
thing
to
generate
that,
rather
than
go
and
change
it
a
hundred
times
in
ten
different
overlays,
so
I
can
I
can
share
some
of
those
things
explosively.
We
need
totally.
B
You
can
do
it
with
like
dependency
graphs,
a
cyclic
dependency
graphs,
cyclic
like
DAGs,
you
can
do
it
with
different
cases.
Look
at
defining
these.
We
could
just
have
a
strict
ordering
and
absolute
ordering
of
functions.
You
could
implement
reentrant
functions
where
you
have
to
do
them
multiple
times,
because
you
do
this
one.
Then
you
do
that
one
then
you
first
one
again
to
make
sure
it's
stuck,
but
if
we
had
that
I
could
imagine
like
you
just
specify
the
resource
and
you
annotate
or
you
just
specify
deployment
and
you
annotate.
B
The
deployment
was
saying,
create
services
for
me,
please
right
and
then
the
Transformers
would
go
along
and
like
create
services
that,
like
that,
send
traffic
to
the
things
that
are
annotated
like
I,
can
imagine
doing
something
like
that.
The
way
you'd
have
to
do
that
today
is
just
to
a
generator
that
creates
both
the
deployment
and
the
service
and
call
it
like
that
service
service
deployment,
generator
or
something
I
think.
D
One
thing
you
have
to
watch
out
for
is
you
know
we
had
those
earlier
discussion
about
ordering
of
resources
because
of
the
validating,
webhook
and
so
on,
and
we
had
a
proposal
around
annotations
and
you
know
be
nice
not
to
have
to
do
that,
but
it
seemed
like
a
necessary
evil.
Here
you
might
have
the
same
problem
where,
if
we're
using
mass
to
do
things
than
changing
one
thing
in
one
spot
changes
the
order
of
the
map,
but
you
might
get
a
different
result.
B
It's
just
a
matter
of
like
what's
the
explicit
way
right
like
if
we
just
do
a
straight
ordering,
like
is
a
dag
better
than
a
straight
or
does
the
already
need
to
be
absolute?
Does
it
need
to
include
the
built-ins
as
part
of
the
order
or
like
should
it
be
phases
where
one
phase
before
built-ins
another
after
some
of
the
Transformers
are
implicit
like
generators
are
implicitly
transformers
because
they
may
generate
names
that
need
that
have
to
be
wired
into
places?
Where
do
those
come
in?
B
Do
those
need
to
be
explicitly
ordered,
like
I,
totally
agree,
I,
think
I
think
there's
just
so
many
decisions
about
that
that
are
dependent
on
what
the
actual
requirements
for
the
solution
are
that
I'm
not
sure
we
want
to
make
them
upfront
but
I'd,
be
I'd,
be
I'd,
be
excited
to
read
proposals
about
what
the
best
way
of
doing
this
is,
and
maybe
a
straight-up
little
ordering
is
the
right
way
to
do
it,
or
maybe
the
thing
that,
when
kind
of
leaning
is
to
say,
let's
just
respect
the
ordering
that's
in
there
and
make
it
like
will
run
the
Transformers
in
the
order.
B
That's
listed,
that's
kind
of
an
alpha
supported
feature
and
as
soon
as
we
determine
that
that
is
insufficient
and
we're
gonna
have
to
do
something
different,
because
because
there's
two
phases
right
or
we
have
to
include
built-ins
someway
or
something
like
that
and
including
built-ins-
doesn't
work
with
the
current
way.
We
express
things,
then,
we'll
probably
just
do
a
release.
Note
saying
this
is
being
removed
without
like
some
long
deprecation
process
or
something
like
that.
I
can
imagine
something
like
that.
I
know,
thoughts.
D
If
they
become
popular,
then
there's
going
to
be
a
lot
of
them
and
then,
if
you
ever
compose
things
together
and
knowing
the
order,
it's
going
to
be
difficult
to
do,
making
it
explicit
sort
of
just
hands
the
problem
off
to
the
user,
which
is
an
late
great
solution.
There's
no
dry
run.
That
shows
me
what
would
apply
in
what
order.
D
B
B
We
could
just
I
think
we
have
audit
for
plugins
anyway,
we
could
probably
say
well,
we
don't
even
need
to
do
the
dry
run,
probably
if,
if
we
just
respect
the
order,
that's
in
that
list
and
do
it
that
way-
and
we
don't
commit
to
doing
it
that
way
in
the
future,
but
we
won't
change
it
like
we
could.
Probably
you
could
probably
just
do
that,
but
not
make
it
part
of
the
API.
B
A
D
B
B
But
add
to
the
dock,
I
think
it's
actually
in
there,
like
in
the
proposal
under
G,
a
graduation
criteria
for
G
a
there's,
a
consider
these
things
list
and
one
of
the
things
to
consider
is
introducing
ordering
which
is
which
is
suggesting.
So
that
is
something
we
want
to
consider
and
the
second
is
lifting
all
restrictions
around
adding
or
removing
resources.
As
another
thing
we
want
to
consider
and
if
that
should
be
done
as
a
separate
field,
perhaps
where
it's
like
unsafe
or
unpredictable
transformations.
D
B
A
Something
new
yeah
Oh,
actually
there's
not
nothing
any
anything
else
other
than
the
stand-ups
and
we're
almost
close
to
the
I
think
we're
we're
book
for
15
minutes
or
50
minutes
or
so
so
I.
Don't
let
people
go
on
time.
So
if
you
have,
if
you
have
any
stand-ups,
they
want
to
share
with
the
group
that
would
be.
That
is
the
time
to
do
it.
Right
now,
oh
and
thanks
for
getting
us
through
both
of
the
caps
for
customized
yeah.
E
So
so
the
coop
cuttle
independence
is
us
getting
coop
cuddle
out
of
core
and
into
its
own
repository.
We've
got
15
remaining
imports
that
we
have
to
remove,
which
is
not
really
that
many
we
actually
have
I
have
to
pee
ours
out
to
remove
half
of
those
seven
of
them
which,
and
they
were
relatively
straightforward,
PRS
there.
E
I
think
Juan
had
started
down
and
actually
that's
you
know
that
that
may
end
up
being
the
most
difficult
one
and
then
there's
finally
printers
one
that
that
I'm
working
on
right
now
so
we're.
Actually
we
have
so
so
we're,
basically
that
we
see
some
light
at
the
end
of
the
tunnel.
Now
I
there
may
even
be
some
PRS
in
the
near
future
to
move
some
of
our
package
coop
cuddle
code
into
staging.
We
may
do
that
in.
E
In
fact,
it
may
be
much
easier
and
much
safer
to
do
it
in
in
multiple
PRS,
so
we
can
move
different
parts
of
it
into
staging
and
and
and
we
may
be
able
to
to
get
so
we're
you
know,
we've
we're
making
progress
and
it
looks
like
we're
getting
close
to
the
end.
I
guess
is
the
story.
Is
there
any
questions.
E
B
This
is
something
has
literally
been
working
on
for
years.
Leaders
we've
been
working
on
this
and
it's
gonna
be
huge.
It's
really
an
open
up
a
lot
of
stuff
and
it's
gonna
make
our
ability
to
release
crew
control
much
much
better.
So
thank
you
for
everyone
involved.
There's
a
lot
of
people
have
been
involved
in
this
in
two
years
as
a
tendency
to
burn
people
out,
it
was
pretty
killer
effort,
so,
like
Jeff
started
on
it
Quan
and
watch
him
work
on
it.
David
EADS
has
worked
on
it.
A
Awesome
great
news
that
they
want
to
have:
does
anyone
else
have
anything
that
they
want
to
share
with
us
with
regards
to
their
stand
up,
so
what
they
are
working
have
been
working
for
the
past
few
weeks
going
once
going
twice?
Okay,
with
that
I'm
gonna
close
the
calls
for
today.
Thank
you
for.
Thank
you
all
very
much
for
your
time
and
see
you
in
two
weeks
file.