►
From YouTube: CNB Weekly Working Group
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
Awesome
any
new
faces.
A
Yeah,
hello,
hello,
so
hey
all
this
is
lux
and
I'm
a
computer
science
student
from
india,
so
yeah
I've
been
learning
about
containers
and
docker
how
dogger
file
works
and
how
we
write
docker
file
to
create
container
images,
and
this
is
where
I
came
across
build
packs
and
I
started
to
learn
more
about
it.
A
A
Awesome
welcome
thanks
for
joining
us
and
yeah.
Hopefully
we
can
find
something
for
you
to
help
out
with
yeah
sure.
B
I
can
speak
for
implementation.
We
don't
currently
have
any
release
happening
right
now,
but
we
do
have
some
feedback
requests
out
for
some
of
the
blockers
for
getting
o14
rc
out
so,
and
I
think
those
people
have
been
paying
so
once
we
have
a
direction
there
that
we
can
hopefully
cut
a
release
of
that.
C
C
Yeah,
I
think
in
in
the
last
the
sub
team
sync,
we,
I
think
sorry
daniel
was
supposed
to
get
back
to
emily,
with
with
the
changes
we've
planned
for
lips
and
bb2,
and
just
get
some
feedback
on
what
that
looks.
Like.
A
Cool
all
right
call
for
votes.
Did
you
put
this
on
here,
joe.
A
Yeah,
I
think
I
emily
took
a
look
at
the
system
bill
pax
one
already.
I
think
I
need
steven
to
look
at
take
a
second
look
at
the
the
positional
argument.
A
Cool,
I
guess,
before
we
jump
into
action,
discussion
stuff.
I
just
wanted
to
kind
of
call
out
the
slack
migration
that's
happening
on
monday,
the
14th
of
this
month.
So
just
be
aware,
we
are
migrating
to
the
cnc
slack
and
should
have
been
email
on
the
mailing
list,
as
well
as
the
announcements
channel
in
slack,
and
then
I
will
also
be
opening
up
a
pr
against
the
docs.
So
we
can
stop
pointing
people
to
the
bill
pack
slack
when
that
date
hits
and
then
we
can
merge
that
on
monday.
A
D
Yeah
during
the
core
team
sync,
when
we
were
sitting
the
agenda,
I
think
sam
suggested.
We
come
back
to
this
demon
removal
topic
that
we
discussed
last
week
like
how
we
would
prioritize
demon
removal,
which
is
something
that
one's
working
on
on
rfc
for
versus
some
of
these
other
rfcs
that
are
introducing
behavior.
That
would
be
sort
of
different
between
the
demon
and
the
registry
and
therefore
is
making
the
demon
removal
seem
more
pressing.
D
Last
week
I
had
sort
of
been
arguing
that
we
should
hold
all
that
stuff
until
we
do
the
demon
removal,
but
I
think
I've
come
around
to
the
other
side
that
we
probably
don't
need
to
hold
these
rfcs,
but
that
sort
of,
as
a
group
of
maintainers
executing
on
this,
we
should
figure
out
how
to
prioritize
the
demon
removal,
because
I
think
a
lot
of
times
the
way
these
discussions
go.
We
don't.
D
C
Separately,
I
just
wanted
to
ask
how
we
want
to
do
this
deprecation.
Should
we
like
the
yesterday,
we
were
discussing
like
the
whole
experimental
life
cycle,
features
thing
that
I
wanted
to
bring
up
in
the
working
group
again
like
how
tied
are
we
to
keeping
the
life
cycle
implementation
exactly
like?
Have
a
one-to-one
map
with
the
spec?
C
Go
back
and
fix
the
rfc
inspect
because,
like
a
lot
of
these
explorations
it
just,
I
think
it
takes
a
lot
of
time
where
someone
spends
a
lot
of
time
at
an
rfc
and
when
we
get
down
to
implementing
these
things.
We're
like.
Oh,
this
doesn't
make
sense.
So
let's
go
back
and
change
things
again
and
then,
by
the
time
the
things
being
implemented.
It's
very
different
from
the
rfc,
like
this
kind
of.
D
I
think
the
reasons
in
the
past
that
and
like
I'm,
not
saying
that
we
shouldn't
do
that,
I'm
I
think
we
need
to
seriously
explore
other
ways
to
make
changes,
but
just
to
sort
of
like
rehash
the
reasons
we
haven't
done
this
in
the
past.
D
It's
like
it
starts
in
some
ways
blurring
the
cleanness
of
what
it
means
to
be
on
a
specific
api
version.
So
it's
like
okay,
if
the
lifecycle
has
an
experimental
feature,
is
that
experimental
feature
enabled
on
every
api
version
of
the
platform
api
like?
Maybe
it
only
makes
sense
with
the
newer
ones
like
and
then
once
you're
tying
it
to
an
api
version
anyways
it
gets
confusing.
So
that's
like
one
reason
and
then
the
second
reason
would
be
people
love
to
create
dependencies
on
things.
D
C
I
mean
that
it's
also
like
it
also
affects
the
velocity
of
the
project.
I
think,
like
one
point,
I'm
interested
in
some
feature
I'll
write
an
rfc
for
it
by
the
time
like
we
actually
get
to
merging
it.
I've
found
a
work
around
no
longer
interested
in
the
rfc
and
then
like
just
sort
of
fades
away
like
there
are
like
small
changes
we
we
could
make
very
like
that
annotation
or
the
history
change.
For
example.
C
We
need
some
way
to
have
extensions
to
the
life
cycle.
I
think
we've
talked
about
it
a
bunch
of
times
in
the
past,
but
like
we
need
a
way
to
prove
out
an
rfc
before
we
actually
merge
it
in
or
like
even
for
small
features
like
this.
We
need
some
way
to
test
the
impact
or,
like
another
example,
was
like
during
the
s
bomb
rfc.
B
You
know,
consensus
for
you
know,
folks
who
say
yes,
it
could
be
an
official
part
of
the
project
that
ships
by
default
and
is
turned
on
you
know,
but
if
the
problem
is
that
the
consensus
mechanism
takes
too
long
right,
it's
you
know
getting
five
people
to
say.
Yes,
this
sounds
good
takes.
You
know
an
inordinate
amount
of
time,
then
that's,
definitely
something
that
I
think
everybody's
acutely
aware
of
has
kind
of
come
up
in
some
core
team
sinks
that
you
know.
B
We
really
do
need
a
different
approach
there
right
and
I
I
think
my
you
know,
I
think
the
ideal
path
forward
is
to
fix
that
problem
and
not
necessarily
to
try
to
circumvent
the
rfc
process
just
just
because
I
don't
see
how
it
would
actually
speed
things
up
or
like.
I
think
it
could
make
part
of
the
problem
you're
talking
about
worse
instead
of
better.
B
I
I
think
I've
always
been
more
on
the
side
of
keeping
this
back
up
more
minimal
description
of
what
things
can
rely
on
and
as
long
as
we're,
not
adding
things
to
the
build
pack,
author
interface,
that
are
on
by
default,
that
you
could
depend
on
they
could
change
later.
Then,
I'm
not
opposed
to
that.
D
Sorry,
as
you
can
see,
that's
one
of
the
reasons
I
flick.
One
of
my
hobby
horses
has
been
sort
of
moving
any
life
cycle
behavior
that
could
be
build
pack
behavior
into
a
build
pattern,
because
I
feel
like
once
you're
giving
build
packs
the
mechanisms
to
be
responsible
for
more.
Then
it's
a
lot
easier
to
iterate
and
prototype
things.
C
C
If
you
could
just
add
that
cosine
stuff,
like
the
life
cycle,
doesn't
have
to
be
aware
of
any
of
this,
and
you
could
get
all
of
this
done
same
for
like
merging
s,
forms
like
if
you
could
just
have
something
at
the
end
of
export
or
rebase.
That
gets
called,
which
we
can
like
back
on
to
the
life
cycle
image
and
the
life
cycle
just
executes
it
at
the
very
end.
C
C
I
don't
know
maybe
some
difference
in
the
export
behavior
so
that
after
the
export,
I
do
some
more
operations
like
call
out
to
let's
say
some
api
or
something
like
it
in
terms
of
back
like
the
api
has
not
changed
at
all.
It's
just
still
calling
everything
with
the
same
arguments
you
can
just
plug
in
the
extensions
to
the
lifecycle
and
pack
remains.
The
same
life
cycle
remains
the
same,
I'm
just
adding
whatever
behavior
I
want
to
inject
at
the
very
end.
B
So
you're
saying
like
because
in
some
cases
pack
is
going
to
execute
all
the
stages
individually
in
some
cases,
it's
going
to
execute
them
together.
If
you
created
a
custom
builder
and
a
custom
life
cycle
image
and
configured
pack
to
use
that
it'd
be
kind
of
weird,
because
you'd
be
like
wrapping
the
exporter
in
some
cases
and
then
it
you
know,
like,
I
think
it's
possible,
but
it
would
be
complex
and
it's
just
a
simple
way
that
was
guaranteed
to
run
the
you
know
hooks
at
the
right
place
would
be.
C
B
What
what
you're
describing-
or
that
seems
a
little
different
from
hooks
for
platforms,
because
that
that's
more
like,
should
we
modularize
the
life
cycle
more
right
and
how
we
organize
the
code,
and
you
know
like
at
one
point
all
the
things
were
separate
binaries
and
now
they're,
it's.
You
know
one
binary
with
sim
links,
but
we
can
organize
the
code
to
make
it
so
that
you
know
we
deal
with
the
complexity
and
you
can
you
know,
isolate
the
phases
into
different.
B
You
know
invocations
of
an
executable.
If
you
want
to
to
me,
that's
a
little
different
than
a
hook
that
wants
a
platform
execute
whatever
it
wants
right.
I
do
think
that
hook
is
aligned,
like,
I
think,
maybe
a
mistake.
B
We've
made
kind
of
philosophically
in
the
past
that
I
I
kind
of
feel
is
that
we've
kind
of
treated
the
life
cycle
like
like
a
platform
itself
right,
like
we've,
made
decisions
about
how
we
want
to
restrict
the
use
of
it
as
a
tool,
because
you
know
it's
often
used
to
implement
platforms
and
we're
imagining
what
those
platform
authors
would
what
restrictions
they
want
to
put
in
place
right.
But
I
definitely
think
we
should
lean
more
towards
the
tool
and
platforms
are
up.
You
know
they
can
do
whatever
they
want.
B
Anyways
right,
we
shouldn't
make
it
harder
or
easier
to
you
know
kind
of
extend
the
tooling
we
just
just
as
long
as
we
publish
a
specification
that
says
here's.
What
a
build
pack
should
expect.
Here's,
what
a
platform
consuming
the
lifecycle
should
expect
right,
and
so
I
did
not
oppose
it
all
to
more
hooks
or
ways
to
make
it
easy
to
plug
for
platforms
to
extend
life
cycle.
Behavior.
C
C
B
I
think,
because
gem
packages
runs
in
the
context
of
both
images
and
then
its
output
is
then
stamped
back
on
the
image
in
a
particular.
You
know
place
like
if
we
could
come
up
with
a
generic
interface
or
something
like
that
right
that
you
know
makes
sense.
Contextually,
then
that's
great.
It
seems
pretty
specific
of
a
feature,
though.
C
D
Can
I
feel
like
first
I'd,
want
to
see
like
a
couple
examples
when
people
want
to
use
it
to
make
it
be
worth
having
the
complexity
and
then
to
sort
of
like
why
you
couldn't
do
it
now?
I
guess
like
especially
if
it
has
the
same
interface
like
you
can
just
sit
in
front
of.
You
can
pretend
to
be
the
life
cycle
right
and
then
just
do
your
hook
and
then
implement
execute
the
life
cycle,
the
one
complexity.
D
That
would
be
what
steven
brought
up
like
if
you're
doing
creator-
and
it's
just
a
builder-
it's
easy-
you
put
on
your
builder.
If
you
also
need
a
life
cycle
image,
then
you
need
it
on
the
life
cycle
image
as
well,
but,
like
I
don't
think
we'd
want
to.
C
D
C
It's
just
difficult
to
extend
or
like
what
I
was
thinking
about
is
more
like
good
tooling,
to
make
such
extensions
possible
like
if,
even
if
you
wanted
to
do
something
like
this
take
in
a
trusted,
life
cycle
image
have
a
way
to
track
the
modifications
you
made
to
that
life
cycle
image
and
then
use
it
in
a
platform
like
not
just
arbitrary,
generating
a
binary
that
you
you,
you
don't
know
where
it
came
from
and
then
just
swapping
out
the
actual
lifecycle.
One
binaries
with
your
own
custom
ones,.
D
Yeah,
I
don't
know,
I
don't
know
if
I
feel
like
it's
worth
building
all
of
that
out,
maybe
on
the
pack
side
like
a
way
to
replace
the
life
cycle
with
a
flag,
not
like
the
life
cycle,
image
and
the
builder.
But
specific
phases
be
like
this
is
kind
of
unsafe,
but
cracks
not
going
to
stop.
You
might
allow
folks,
at
least
to
develop
things
like
this
right
locally
and
then
adding
it
to
your
own
platform
is
sort
of
like
your
own
platform's
business.
At
the
end
of
the.
D
I
think
what
makes
it
hard
is.
You
have
to
update
your
builder,
the
custom
life
cycle
and
your
life
cycle
image
with
the
custom
life
cycle
and
then
like
have
you
replaced
all
the
faces
if
you
place
one
face
like
if
you
could
just
copy
in
a
binary
over
things
to
be
a
lot
less
preamble
in
order
to
play
with.
A
When
we
talk
about
this
experimentation,
are
we
talking
about?
We
want
to
distribute
these
features
publicly.
Is
that
like
versus
you
just
doing
it
and
kind
of
hacking
up
on
your
own
platform.
C
A
Could
we
leverage
something
I
mean
I
guess
you
would
need
like
probably
a
different
config
or
something
somewhere
but,
like
I
feel
like
was
it
emily
yesterday
suggested
experimental,
and
then
we
kind
of
published
that
discussion,
because
it
was
off
agenda
but
some
type
of
like
feature
fat,
flag,
experimental
thing
that
would
just
turn
certain
things
off,
but
on,
but
by
default
or
off.
E
I
I
ask
about
that:
experimental
flash
flag
on
life
cycle
before
I
believe
is
useful
for
doing
some
stuff
like
the
interactive
mode
impact,
for
example.
It's
something
that
was
able
to
be
released
based
on
an
experimental
flag
on
back
and
it's
there
and
people
can
use
it
and
get
feedback.
I
believe
that's
quite
useful,
but
now
thinking
on
what
some
mentioned
I
was,
I
was
going
to
ask
this
crazy
idea,
at
least
to
see
if
I
understood
what
sam
was
talking
about.
E
It's
like,
I
don't
know
if,
if
we
think
on
tournettis
and
the
crd
model,
where
people
can
actually
inject
behaviors
and
do
things
into
kubernetes
without
touching
the
core
of
kubernetes
per
se,
but
extending
them
based
on
that,
I
don't
know.
If,
if
that's
more
or
less
the
idea,
we
would
like
to
do
somehow
with
the
life
cycle.
E
You
know
exposing
some
way
where
people
can
actually
do
something,
implement
something
and
then
give
it
that
to
the
life
cycle
and
the
life
cycle
will
treat
it
and
do
it
not
sure
if
the
extensions
or
the
hooks
or
maybe
it's
something
similar
that
I
that's
my
question.
It's
more
or
less
that's
what
we
would
like
to
to
do
with
the
life
cycle.
Offering
this
way.
Okay,
you
want
to
add
something
to
the
life
cycle.
You
don't
need
to
wait
for
me.
Do
it
in
this
way
and
everything
you
do.
E
We
will
try
to
execute
in
some
way
that
it's
going
to
be
understood
by
the
by
the
system.
D
I
feel
like
what's
kind
of
ironic
about
this.
Is
this
is
sort
of
the
point
of
the
build
packs
in
a
way
it's
like
the
life
cycle
executes
a
bunch
of
arbitrary,
build
logic,
and
its
role
is
basically
just
to
make
sure
that
those
pieces
do
not
produce
results.
That
conflict
with
each
other,
like
that,
the
results
of
each
of
those
can
be
turned
into
a
single
image,
and
then
it's
like
in
the
build
packs
themselves,
where
you'd
be
developing.
Some
of
that
logic
right,
I
feel
like
if
we're.
E
E
E
We
depend
on
that
and
nobody
can
change
it
unless
you
go
to
the
library
and
then
change
the
code
and
then
inject
the
dependency
into
the
life
cycle
and
create
a
new
version.
So
maybe
thinking
on
the
component,
the
core
components
we
have
in
the
same
way
as
the
build
packs
and
trying
to
offer
some
way
to
expose
that.
I
don't
know
if
that's
going
to
affect
security
or
whatever,
but
that's
maybe
the
kind
of
things
we
are
missing
and
if
we
check
the
whole
core
concepts
we
have
in
our.
E
The
other
thing
is
that
depends
on
the
current
implementation.
We
have,
if
you
throw
away
the
current
implementation
and
think
on
the
life
cycle
in
a
different
way.
Without
that
kind
of
things,
maybe
the
implementation
will
be
different,
and
so
it's
it's
kind
of
thinking
from
specification
perspective
and
without
being
attached
to
the
current
implementation.
B
Is
there
any
disadvantage
like
we
didn't
call
extensions
hooks,
so
that
name
is
available
now
is?
Is
there
any
disadvantage
to
just
like
as
a
as
a
straw
man?
So
I
understand
the
like
downside:
is
there
any
disadvantage
to
making
a
cnb
hooks.d
directory,
and
if
you
put
exporter,
dash,
pre
dot,
sh
or
something
in
there,
then
it
executes
before
the
exporter
right
like
just
open
it
up
completely,
have
life
cycle.
D
We're
expanding
our
interface
when
we
would
like
to
be
shrinking
it.
Maybe
one
downside
second
downside
is
like
who
is
shipping
those
do
they?
You
know
if
it's
coming
on
a
builder
like
what,
if
we
change
the
interface
to
the
exporter,
are
we
opening
up
more
opportunities
for
things
to
break
because
of
api
version,
incompatibilities.
B
I
mean
no
arguments
just
directly
invokes
you
know,
executable
with
a
specific
name.
D
You're
asking
me
I'm
not
saying
I'm
opposed
to
it.
I
just
want
to
see
it
written
out
and
then
also
like
compared
to
other
things
we're
working
on.
I
don't
know,
I
don't
know
if
I
would
be
like
this
is
the
thing
right
now,
but
yeah.
B
C
I
think
for
me,
like
we
can
try
and
list
out
what
kind
of
things
we
would
like
beyond
what
the
buildback
api
currency
offers,
but
things
that
would
be
shared
across
platforms,
and
then
we
can.
We
can
see
if
there
are
any
common
interfaces
that
come
up.
I
think
the
other
thing
is
like
with
with
buildbacks
the
reason
they're
so
successful.
Is
that
there's
a
common
api
and
anyone
can
easily
implement
it
and
there's
like
tooling,
provided
by
the
project
to
make
creation
distribution
easy.
C
C
D
We
just
need
to
be
able
to
make
buildbacks
do
some
of
these
things
like
if
our
solution
to
annotations
ended
up
being
a
life
cycle
hook
that
sets
specific
annotations
instead
of
something
that
allows
build
packs
to
set
annotations.
That
would
feel
sad
to
me,
because
that
feels
like
we're
adding
complexity
to
do
a
stop
gap,
because
we
can't
figure
out
how
to
make
the
change.
We
know
we
want
to
make
to
the
build
pack
api.
D
Something
like
cosine's
a
little
bit
different
because
you're
creating
a
whole
different
image
or
signing
the
image
output
right,
but
I
feel
like
that
really
could
just
come
totally
after
export
in
its
own
way
too,
like
that,
doesn't
even
need
to
be
part
of
the
life
cycle,
so
I'm
struggling
for
the
killer
example
that
I'm
like
yeah.
This
one
makes
me
feel
like
this
is
really
necessary.
B
I
think
we've
been
resistant
to
certain
kinds
of
extensions
that
would
break
rebase
right,
but
something
like
signing
based
on
image
metadata
doesn't
bring
rebase
because
it
doesn't
need
access
to
the
container,
and
so
maybe
we're
missing
a
kind
of
build
pack
or
extension
that
is
safe
because
it
doesn't
have
access
to
the
inside.
It
can't
write
into
the
inside
of
the
container,
but
it's
still
a
modular
user
providable
feature
and
I
think
it'd
be
great
to
see
an
rfc
if
people
have
use
cases
for
that.
C
The
the
issue
with
the
cosine
thing
is
that
it's
definitely
possible
to
do
it
afterwards.
There
have
been,
like
reasons
brought
up,
not
to
do
it
like.
There
are
examples
like
if
you,
if
you've
got
the
s11
disk
waiting
for
something
in
the
middle
and
then
executing
like
event
signing
someone
could
have
modified
it
in
the
middle
and
then
like
and
then
you're
like
signing
it
with
it
with
a
trusted
key
and
putting
it
out
there.
C
So,
like
that's
like
one
of
the
reasons
that
I
saw
floating
around
and
like
moving
bomb
generation
tools
closer
to
the
build
process
like
that's,
why,
like
things
like
core,
like
other
package
managers
like
there's
a
huge
push
in
trying
to
get
the
package
managers
themselves
to
generate
the
bomb,
as
opposed
to
anything
else
same
for
like
signatures
like
just
trying
to
get
it
closer
to
where
the
stuff
actually
happens,
so
there's
less
room
for
some
actor
in
the
middle
to
modify
things,
and
it's
also
easy
from
an
interface
perspective
like
right
now,
if
you
have
your
bomb
in
the
output
image
in
some
layer
just
referenced
by
a
label
that
life
cycle
knows
like
you
to
first
find
the
image
decode.
C
A
I
just
I
just
want
to
call
out
time:
did
you
want
to
touch
on
the
hotel
stuff?
Sam?
Because
I
know
that
was
awesome
topics.
I
just
wanted
to
make
sure
we
got
like
a
little
over
10
minutes.
C
So
this
this
was
an
idea.
We've
been
discussing
the
debug
team
for
a
while
now,
like
structured
logging,
integrations
for
buildbacks
and
also
for
the
rest
of
the
project
and
life
cycle,
and
not
just
structured
logging,
but
like
they've,
also
been
use.
Cases
where,
like
people
want
to
monitor
different
parts
of
the
creation
process
like
how
much
time
did
analyze
take.
C
How
much
time
did
a
specific
buildback
execution
take
and
being
able
to
like
send
all
of
this
data
to
some
external
store
that
can
be
analyzed
separately
from
a
build
process
and
also
like
if
all
of
this
data
is
is,
if
logs
are
the
only
source
of
information
for
debugging,
a
buildback
that
becomes
difficult
like
if,
if
your
detect
fails,
for
example,
that's
the
most
common
example
you
you
literally
have
to
like
rerun
the
whole
thing
with
a
few
more
arguments,
hope
for
the
best
that
you
can
find
something.
C
C
Buildbacks
can
log
things
with
like
some
structure,
but
you
could
define
a
config
file
at
a
builder
level
that
maps
the
structured
logs
to
some
pretty
printed
output,
so
based
on
certain
attributes
of
your
structured
log.
Let's
say
the
log
level
or
any
other
attribute
that
you
define
you'd,
be
able
to
map
that
to
like
some
format,
string
with
the
ansi
sequences.
If
you
want
like
colors
or
whatever.
B
You're
talking
about
structured
logging
for
build
pack
output
for
everything,
so
so
a
problem,
structured
login
for
build
pack
output
has
come
up
several
times
in
the
past.
I
think
the
really
big
problem
is
that
it
makes
writing
a
build
pack
really
hard
because
most
build
packs,
execute
external
tools
which
execute
external
tools
which
execute
external
tools,
and
none
of
them
use
structured
logging,
and
so,
if
you're
a
build
pack,
it
means
every
time
you
run
npm,
install
or
whatever
right.
You
have
to.
B
You
know,
line
split
that
in
a
streaming
way
and
then
add
structure
json
to
it
and
then
output
that
it
just
it
makes
the
build
pack
interface
go
from
like
you
know,
this
could
be
theoretically
easier
than
a
docker
file
if
it
were
really
simple
right,
because
you
know
it's
just
a
just
executable,
you
write
in
any
language
to,
like
you,
know,
you're
doing
the
management
of
all
the
data
coming
out
of
a
lot
of
other
tools.
C
I
mean
that
can
be
solved
if
the
life
cycle
is
aware
of
structure
logging
right,
like
the
buildback,
can
set
certain
things
like
at
this
point
onwards,
like
I'm
executing
some
tool
or
something
I'll,
just
print
everything
to
stand
it
out.
The
life
cycle
can
take
all
of
that
and
put
it
in
a
structured
log
so
that
it
says
lower
level
whatever.
Here
was
the
message,
which
is
the
entirety
of
your
like
output,
and
so
I
was
thinking
more
along
that
line
so
like,
even
if
we
wanted
to
preserve
backwards.
C
D
And
like
even
on
the
life
cycle,
level
like
it'd,
be
cool
that
if
we
were
in
a
situation
where
we
had
a
tty,
you
know
like
do
when
it's
streaming
to
the
registry.
Like
you
know,
we
do
sort
of
docker
push
style,
progress
bar
stuff
like
that,
like
it's
nice
to
have
those
options
open
in
places
where
we
want
those
options,
and
I
wouldn't
want
to
foreclose
them
just
because
we
have
a
need
for
telemetry
type
information
as
well.
C
I
mean
there
are
completely
different
concerns.
We
can.
We
can
have
telemetry
integration
without
structure
logging.
I
think
the
reason
we
just
brought
it
up
was
like,
I
think,
when
we
were
discussing
structure
logging
in
the
past.
Some
people
like
I
want
to
log
a
line
that
says
started
my
execution
here,
rendered
it
here
and
then
want
to
ship
it
somewhere
so
like,
rather
than
doing
that,
what
you
really
want
is
like
some
telemetry
integration
yeah.
I
don't
think
the.
D
Logs
should
be
like
an
api
for
really
specific
things
like
this,
because
then
we're
also
going
to
grow
our
api,
whereas
we
change
things
it's
like.
Oh
everyone's
integrations
are
going
to
break
on
different
platforms
like
it
seems
like
a
can
of
worms,
or
maybe
we
just
want
to
do
a
totally
separate
sort
of
telemetry
output
situation.
For
these
cases,.
B
C
C
B
C
C
A
I
think
the
difficulty
is
the
people
who
are
the
customer
are
bill
pack,
authors
that
like
because
come
from
bat
right,
but
by
that
nature
there
not
necessarily
have
the
like
at
least
immediate,
like
it's
a
tall
order
to
be
like
okay.
Well,
let
me
on
board
onto
at
least
enough
of
life
cycle
that
implement
the
future,
whereas
I
think
the
people
who
potentially
have
the
skill
set
to
do
it
are
less.
I
think,
excited
about
this
feature
because
it
doesn't
solve
a
problem.
They
have
so.
A
It
makes
me
think
of,
like
all
the
people
like
in
ruby,
for
instance,
that
want
features
in
the
ruby
language,
but
it's
written
in
c,
but
they're
rubious.
So
like
there's
like
a
skill,
mismatch
there
and
it's
not
like
a
lack
of
potential
interest
to
drive
it
it
just
they
probably
actually
without
sniff
and
effort
cannot
drive
it
like
implementation-wise.
B
B
You
know
implement
it,
but
but
I
think,
if
maybe
the
challenge
here
is
presenting
evidence
that
we
have
a
lot
of
users
that
need
the
feature
right
and
you
know
convincing
folks
who
work
on
the
life
cycle,
that
this
is
something
that
you
know
should
be
implemented.
I
think.
B
The
direction
the
project
goes
right
is
a
a
governance
decision
right
and
people
on
the
core
team
have
to
think
about.
What's,
what's
really
right
for
the
project
in
the
long
run,
and
you
know
which
prs
get
looked
at
first
right,
that's
governance!
It
has
to
be
done
fairly
based
on
the
order
they
come
in
and
the
road
map,
but
who
actually
does
the
work
to
implement
the
features?
A
Yeah
to
the
latter
part,
I
totally
agree
with
the
you
know
kind
of
going
through
the
process
of
you
know
the
political
part
of
it
to
some
extent,
but
then
to
get
actual,
I
guess,
let's
say
help
on
the
implementation
side
of
things
I
do
want
to
throw
in
that.
We
do
have
the
opportunity
to
leverage
mentorship
programs
right
where
they
could
do
some
other
work
depending
on
the
complexity,
so
that
might
be
another
avenue
to
take
advantage
of.
B
B
A
C
B
I
mean
the
rfc,
doesn't
you
can
start
an
rfc?
That's
just
really
bad
right.
That
just
says
we
should
have
structured
logging
and
then
here's
what
I
think
it
should
look
like.
It
doesn't
make
any
sense.
And
then
you
know
the
people
will
respond
to
the
rfc
and
help
you
work
it
towards
a.
You
know,
a
thing
that.
C
B
A
No,
I
think
we're
over
time,
so
I'm
gonna
call
it.
We
do
have
the
office
hours
later.
If
we
want
to
kind
of
carry
on
with
more
of
these.
Both
of
these
topics.