►
From YouTube: 2023-02-08 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
B
D
B
Should
we
update
the
is
that
something
someone
does
or
anybody.
E
Does
anyone
can
do
it?
So,
let's
do
it.
B
Yeah
Emory
you're
are
you
here
for
the
for
the
cast
Center
exporter
and
then
we're
here
for.
B
B
E
A
G
A
Sorry
I'm
I
was
reading
Alex
comment
about
the
new
name
of
the
collector
distribution.
F
E
F
Can
we
can
share
it
with
everybody
else
at
the
as
part
of
this
discussion
there
we
go
thanks.
Park
then.
F
E
I
guess
yeah
yeah
sure,
so
this
whole
this
discussion
started
more
recently
like
today,
but
it
is
an
older
discussion
and
I
think
we
discussed
before
that.
Contrib
is
not
really
meant
for
people
to
use
in
production
because
there
are
so
many
components
and
people
are
not
going
to
use
all
of
those
components.
So
it's
just
creating
a
potential
security
risk
or
posing
a
security
risk
for
for
the
users
of
contrib,
even
though
we
don't
know
of
any
specific
issues
right
now.
E
We
are
my
my
comment
back
then,
and
still
is
the
same.
Is
that
we're
we're
just
one
cve
away
of
a
big
problem
here
right
and
so
that's
that
was
originally
the
idea
behind
the
country.
Sorry,
the
for
the
Builder,
so
the
Builder
was
supposed
to
allow
us
to
decentralize
and
to
eventually
deprecate
on
trip
or
the
country
repository
back
then
on
on
in
the
name
of
a
decentralized
option.
E
So
people-
wouldn't
we
even
thought
about
back,
then
to
have
a
web
UI
where
people
could
pick
and
choose
which
components
they
want
and
they
download
like
The,
the
binary
or
or
the
Manifest
the
Builder
manifest
for
that
and
people
can
then
compile
or
use
that
on
their
CIS
and
so
on
to
build
their
their
collectors.
E
So
this
is
the
context
for
the
discussion
here
and
we
just
had
a
discussion
about
you
know
not
security
related
discussion,
but
a
a
dependency
Health
discussion
based
on
what
Alex
is
currently
facing
in
during
the
release
of
071,
and
one
thing
that
we
are
discussing
is
perhaps
you
know
we
should.
We
should
consider
not
releasing
the
trip
or.
E
I'm
making
a
leap
year,
but
my
idea
is,
you
know,
eventually
deprecated
construct
and
given
that
we
thought
about
that
like
six
months
ago
and
two
years
ago,
when,
when
Builders
started,
I
guess
would
be
beneficial.
You
know
in
order
to
actually
make
this
move,
I
think
it
would
be
beneficial
to
discuss
what
would
be
the
criteria
that
we
would
like
to
achieve
so
that
we
can
deprecate
control.
So
why
do
we
still
have
contrib
and
what
conditions
do
we
have
to
have
in
order
for
contribute
to
go.
A
So
contrib
itself,
I,
don't
think
jurassi
is
a
problem.
The
problem
is
build
like
bringing
all
these
together
like
we,
we
split
contribute
into
small
modules
that
you
can
separate
them
in
different
repositories
or
whatever
you
want.
I
think
these
small
artifacts
they
are
not
that
hard
to
maintain
the
biggest
problem
is
when
you
have
to
bring
all
of
them
together
back
and
that's
that's
where
the
dependency
hell
starts,
because
some
components
depend
on
some
versions.
Some
components
depend
on
other
version,
so.
A
I,
don't
know
how
to
solve
this,
but
to
answer
your
thing
without
having
this
I
think
people
will
not
be
able
to
build
different
combinations
of
components,
they
will
be
on
different
versions
and
stuff
and
they
will
hit
these
dependency
held
when
they
will
try
to
combine
different
components
together
and
they
will
not
be
able
to
do
it.
E
A
E
It
does
yeah
so.
E
A
Okay,
for
example,
the
thing
that
we
have
right
now
in
so
we
can
remove
the
release
in
the
release
report.
We
can
remove
the
contribute
and
we
are
fine
because,
because
in
the
contributable
we
build
this
binary,
even
though
we
don't
really
see
it,
but
that
guarantees
that
everything
matched
together,
but
still
this
does
not
remove
the
dependency
health
problem.
So
what
I'm
trying
to
say
is
the
dependency
health
problem
comes
with
a
nice
benefit,
which
is
for
the
Final
End
user.
A
They
don't
have
any
trouble
combining
any
components
they
want
and
they
will
just
work
if
we
don't
go
through
this
dependency
hell.
Unfortunately,
that
guarantee
will
disappear
for
the
user
and
they
will
hit
this
problem
that
Alex
hit
today
they
will
try
to
put
promptail
plus
something
else
plus.
Something
else
will
not
work
together
and
they
will
come
to
us
and
say
hey.
This
combination
doesn't
work
for
me.
What
the
heck
are
you
doing
here,
guys
so
I,
don't
know
how
to
solve
it.
I'm
just
explaining
the
situation.
A
E
E
It
just
so
happens
that
we
as
a
contribute
Community,
we
would
find.
We
would
find
this
issue
before
angels
are
used
to
correctly
I,
see
value
in
that
and
I
guess.
That's
good
and.
E
A
One
more
thing
we
we
are
more
much
I
mean
it
will
be
harder
for
a
customer
to
come
and
say
Hey
promptail.
You
are
the
fault,
it's
much
easier
for
us
to
say
that.
So
so
it's
it's
another
small
benefit,
because
in
the
community
we
owning
this
we
can
blame
much
easier.
We
can
blame
different
components
than
than
an
external
customer.
E
Yeah
I
mean
I
I
agree
with
that
I
would
I
would
I
would
follow
that,
but
I'm
also
seeing
like
two
steps
ahead
like
if
people
are,
if
we
end
up
building
the
vision
that
we
had
two
years
ago
in
that
the
registry
is
a
source
of
Truth
for
components
that
we
know
about,
and
then
people
go
to
a
UI
and
select
the
components
and
some
of
those
components
might
be
part
of
their
registry,
but
they
are
not
part
of
contribute.
Then
users
are
still
going
to
have
the
same
issue.
A
Unless,
unless
we
we
run
this,
when
we
allow
people
to
put
them
into
the
registry,
we
we
kind
of
behind
the
scene,
build
this
huge
binary
and
confirm
that
we
can
build
it.
And
if
we
cannot,
we
then
flag
different
components.
So
so
that
website
that
you
are
mentioning,
somebody
has
to
check
that
everything
works
together,
correct
and
you
can
do
that
behind
the
scenes
to
the
user.
F
A
E
A
E
My
point
yeah
and
I-
guess:
I
guess
when
I
think
about
this
problem,
the
way
the
one
way
that
I
can
see
solving
that
is
by
us
establishing,
instead
of
hoarding
all
of
the
components
ourselves,
we
publish
a
set
of
guidelines.
So
first
it
requires
us
to
have
a
1.0
API.
That's
clear,
and
the
second
is:
what
are
the
guidelines
that
we
that
we
require
people
to
follow
and
which
ones
are
the
ones
that
we
suggest
like
requires?
E
You
Dosh
out
now
should
not
depend
on
Prometheus
right,
because
so
many
things
depend
on
Prometheus
and
you
should
just
perhaps
depend
on
something
from
us
like
a
a
bomb
like
a
bill
of
materials
dependency
and
we
bring
our
version
of
Prometheus
training
through
that
dependency.
You
know
so
perhaps
we
should
provide
some
sort
of
guidelines
for
that.
So,
instead
of
instead
of
us
pulling
their
dependencies,
they
pull
all
the
dependencies
that
we
allow
basically
plus
live
dependencies.
They
may
have
yeah.
A
That's
the
the
controlling
that
way,
I
think
is
going
to
work
like
us,
enforcing
which
dependencies
you
can
have
and
US
controlling
like
hey.
If
you
want
to
be
a
component
register
or
whatever
blessed
component
here
are
the
requirements
and
you
you
may
depend
on
these
things.
If
you
depend
on
extra
things,
you
are
not
accepted
and
we
don't
accept
you
well.
G
E
A
A
Ahead
and
try
to
limit,
like
even
I,
know
and
I'm,
blaming
myself
like
I
I.
We
need
to
push
a
bit
more
towards,
like
even
Jagger,
to
help
us,
because
we
right
now
depend
on
the
entire
agar
just
because
we
need
their
model.
So,
for
example,
that's
that's
a
bad
dependency
and
I'm
part
of
the
reason
for
adding
the
dependency.
But
it's
it's
something
that
I
think
we
should
start.
We
should
start
is
forcing
more
like
hey
if
we
need
just
a
model
from
a
from
a
repo.
A
E
So
we
were
able
to
get
that
done
for
Loki,
I
think
very
successfully,
so
we
we
were
able
to
convince
the
lucky
team
that
you
know
there
is
an
outside
road
that
depends
on
them,
that
that
would
benefit
in
having
a
profile
or
the
protocol
a
buff
scene
in
a
specific
module.
So
Benedict
is
here
so
Benedict
can
work
on
the
younger
side
of
things.
So
that's
nice
he's
also
owner
of
all
of
your
our
Jaeger.
E
A
E
Yeah
and
so
I
guess
before
giving
voice
to
Antoine
I
guess
for
my
summary
of
the
situation
is
or
I
guess
it's
it's
a
couple
of
questions
that
I
have
so
do
we
want
to
eventually
get
rid
of
the
of
the
contrib
binary
images
and
so
on
that
we
released.
So
that's,
let's
say,
plus
one
I
think.
F
G
E
F
Yeah
I'm
I'm
in
favor,
of
having
something
that
includes
all
the
components
and,
to
be
honest,
it's
never
like
the
the
release
process
of
publishing
an
image
has
never
been
the
real
problem
here.
The
real
problem
is
getting
the
components
in
a
place
where
they
are
they
can
get
to
that
last.
That
last
point,
so
you
know
to
me:
that's
that's
not
the
big
barrier
for
contributors
and
maintainers
and
approvers,
and
it
makes
it
easier
for
users
right
like
that's.
That's
the
one
thing
that
I
always
think
about
with
contrib
Ute.
D
I
think
the
same
and
like
it,
it
helps
to
try
dry
collector
out
for
the
users
that
first
come
here
and
they're
like
give
me
some
binary
I
want
to
try
this
out.
This
is
like
an
ideal
distribution
binary
for
that,
and
also
you
just
you
mentioned
that
we
are
going
to
be
introduced
to
some
vulnerabilities,
but
even
if
we
don't
build
it,
we
still
have
vulnerability
in
our
code
based
on
the
country,
so
it
might
be
quicker
for
us
to
for
users
or
for
us
to
find
this
out.
If
we
have
that
built.
F
D
F
I
guess
the
the
thing
is:
if
we
keep
the
component
in
a
contributo
and
we
publish
tags,
I
mean
we're
still
publishing
a
tag
for
a
component
that
may
contain
a
vulnerability.
So
it's
we're
making
it
a
little
bit
easier
for
harder
for
users
to
use
those
components,
but
we're
still
officially
you
know,
tagging
it
as
a
thing
that
we
will
support
so.
F
H
H
Yeah
two:
please
do
not
use
I,
think
another
thing
that
to
me
would
be
important
if
we
ever
want
to
get
rid
of
the
contributes
that
we
make.
It
super
easy
to
build
things,
and
that
means
having
a
1.0
version
of
the
Builder
on
releasing.
H
E
So
what
is
the
success
criteria
then,
for
you,
can
you
can
you
repeat
the
points
there
so
view
one
of
the
Builder.
H
So
yeah
be
one
of
the
builder
then
releasing
the
Builder
on,
for
example,
we're
not
releasing
it
on
Docker
now
I
think
that
would
be
important
yeah
having
I
guess
it's
part
of
V1
like
making
sure
that
the
user
experiences
as
simple
as
possible
on
sorry
and
so
on.
I'll.
Let
you
speak
now.
B
No,
no
problem
actually
I
think
the
my
point
is
a
little
tangential,
so
I.
My
question
would
be.
It
looks
like
we're
hitting
this
issue
at
release.
Time
kind
of
we're
about
to
press
the
release
button
and
all
of
a
sudden
Alex
has
to
contend
with
quite
a
bit
of
a
nightmare,
and
unfortunately
it
falls
on
Alex
at
the
very
last
Mile
right.
Could
we
change
that
relationship
like
even
if
we,
even
if
you
move
this
down
to
another
repo
or
you
change
the
the
things
around
this?
B
It
looks
like
if
it
was
to
contend
with
this.
It
looks
like
we
should
have
a
nightly
build
or
something
that
tells
us
way
before.
We
try
to
cut
a
release
that
we're
about
to
run
in
trouble
and
the
processes
that
you
outline
here.
They
seem
to
be
helpful,
but
it
doesn't
seem
like
there
would
be
a
good
signal
to
dispatch
back
to
the
teams
before
it's
release
time
so
I
don't
think
we're
fixing
the
the
issue
long
term
for
Alex,
for
example,.
A
F
So
the
so
the
the
underlying
issue
was
there
was
an
update
to
Hotel
go,
which
we
depend
on
which
then
required
updates
to
some
of
our
dependencies,
which
then
required.
Their
dependencies
on
Hotel
go
to
be
updated,
which
then
required
a
bunch
of
other
dependencies
to
be
updated
and
then,
along
the
way,
I
decided
I'm
going
to
take
on
adding
the
other
list
of
dependent
pod
dependencies
updates,
which
then
ran
into
a
dependency
problem
with
jaeger,
a
dependency
problem
with
hdb
and
dependency
problem
with
Prometheus,
which.
J
J
A
Yeah
in
the
the
answer
is
any
any
dependency
update.
Anton
is
is
causing
this,
it's
not
about
releasing
things,
and
it
happens
almost
every
Monday,
which
happens
to
be
the
release
day
as
well,
because
the
depend
about
we
set
it
weekly
and
it
happens
to
be
Monday.
So
it's
a
it's
a
bit
of
a
coincidence
that
is
released
with
this.
It's
it's
more
or
less
dependency
in
general,
update.
F
Okay,
let's
actually,
let's
just
bring
up
a
good
point
of
with
to
depend
about
PR
as
I
get
open
because
they
don't
actually
run
the
checks
because
they
can't
run
the
checks.
It's
really
hard
to
pinpoint
which
dependencies
are
going
to
cause
problems.
Until
we
get
that
Mega
PR.
That
then
combines
all
of
the
all
of
the
PRS,
which
is
not
great,
because
then
we
run
into
like
multiple
problems
at
the
same
time
and
it's
hard
to
get
to
the
bottom
of
all
of
them
and.
I
Why
depend
about?
Prs
cannot
run
the
tracks.
A
F
E
Is
there
any
problem,
that's
gonna
so
be
solved
by
by
the
bomb
that
we
just
talked
about
as
well,
because
the
bomb
wouldn't
be
probably
another
repository,
even
with
only
the
go
mod
file
and
then
a
a
main
file
that
Imports
blank
blank
reports
for
everything
so
depending
on
board
within
just
issue
updates
to
that
repository
and
then
contrib
and
everything
else
just
depends
on
the
bomb.
A
So
yeah
that
may
solve
the
problem,
but
I
I
don't
know
if
I've
never
seen
this
working
so
far.
It's.
A
H
A
Maybe
maybe
the
workspaces
go
workspaces
work
better
with
with
the
depend
about
I,
don't
know,
if
that's
the
case,
Alex.
F
E
I
think
I
think
we're
very
close,
and
then
we
found
out
that
Dependable
did
not
work
with
go
work
yet.
G
A
Anyway,
that
that
may
be
the
solution
for
the
I,
don't
know,
but
yes,
we
should
look
into
Alternatives.
We
should
look
into
workspaces
if
it
works.
Something
that
helps
with
DCS
would
be
would
be
reasonable.
A
E
There
are
a
couple
of
other
issues,
so
a
couple
of
them
from
Pablo.
No
sorry,
one
from
Pablo,
one
from
from
E
coli
and
one
from
Dimitri.
C
Yeah
mine
is
pretty
short,
so
maybe
I
can
just
get
a
little
RF
right.
So
I
got
this
PR
it's
at.
It
adds
a
new
flag.
We
have
very
few
flags
and
it's
meant
to
control
whether
we're
doing
sounds
fit,
watches,
essentially
whether
whether
we're
paying
attention
to
unfit
providers
sending
us
notifications
that
the
config
has
changed
and
the
reason
or
the
reason
I'm
adding.
C
That
is
because
it's
cool
right
now
we're
we're
watching
everything
by
default
and
that
prevents
a
certain
kind
of
nice
changes
that
could
happen
because
then
they
become
breaking
changes
or
changes
in
behavior
and
basically
it's
already
reviewed
and
improved
by
urachi
and
and
Anthony
and
I'm,
basically
kind
of
bringing
adapter
as
attention,
because.
C
A
C
Well,
basically
lets
you
control
whether
you're,
like
reloading
configuration
from
places
like
you,
have
a
config
provider,
for
example.
It's
a
file
on
disk
right.
It
might
change
under
you
for
some
reason,
because
the
user
changed
it
and
right
now,
this
like
we
just
have
infrastructure
for
this
and.
A
E
G
H
You
don't
like
the
times
that
I
proposed
for
the
new
meetings.
Please
say
something
on
the
issue
and
process
that.
D
D
And
that
was
the
issue
originally
posted
by
a
book
then,
like
we
discussed
that
a
few
six
ago,
and
the
problem
was
that
even
if
component
marks
itself
as
a
mutable,
it
is
not
mutated
and
date
and
immutable.
It
can
mutate
the
data
and
like
cause
very
subtle,
bugs
that
super
super
hard
to
develop
so
I'm
I've
been
working
on
like
prototype.
D
That
does
prevent
that
in
compile
time
so
provide
different
interface
for
p
data
that
doesn't
allow
you
to
mutate
the
data,
if
you
don't
want
to
do
that,
so
let
me
show
how
it
looks
like
capability.
Yes,
currently
we
specify
ignore
bash
processor,
it's
not
the
best,
not
the
best
example,
but
anyway
just
any
processor.
So
we
specify
capabilities
here
and
we
and
under
the
hood,
all
the
data
being
if
needed.
D
The
data
is
copied-
and
you
get
the
copy
here
if
like
if
there
is
some
some
other
components
of
the
pipeline,
that
gets
the
same
data,
but
with
like
with
the
suggested
approach.
We
will
not
need
this
anymore
and
instead
of
this,
we
will
have
something
like
this
and
just
click
function
for
to
consume
traces.
All
right
it
will
not.
He
will
not
be
able
to
change
anything
in
the
like
regular
immutable
API.
D
You
can
only
have
ad
here
Etc,
but
if
you
want
to
change,
you
just
need
to
change
change
the
this
particular
call
to
mutable
resource
response
and
under
the
hood
it
will
decide
whether
to
later
under
one
day
there
must
be
copied
or
you
can
get
full
access
to
it
and
then
all
the
other
API
enabled,
and
then
you
send
this
data
further
the
pipeline
to
the
next
Consumer.
So
that's
essentially
probably
the
only
change
here
that
will
that
will
be
required.
A
Essentially,
we
can
Implement
copy
on
right,
correct
with
with
this
approach,
because
we
we're
just
gonna
copy
the
data.
Whenever
user
really
writes
it,
I
mean
close
this
immutable
part.
Yes,.
D
This
this
thing
under
the
hood
does
all
the
magic
if
it
tracks
all
the
stairs
of
the
data
States
from
the
pipeline
and
if
it's
needed,
the
data
will
be
cooperative.
Not
it's
not
will
not
be
confident.
D
Then
one
problem
here
and
if
that,
for
example,
you
you
have
you
do
some
stuff
here,
you
like
iterate
over
the
date,
you
don't
mutate
it
and
you
don't
know
whether
you
want
to
mutate
it
or
not,
and
then
you
decide
hey,
yes,
I
need
to
mutate
the
data
here
and
if
you
mutate
this
one
this
guy,
maybe
all
the
changes
might
make
here
will
be
maybe
reflected
here
or
maybe
not
so
that
with
tricky,
but
we'll
probably
state
it
out.
D
Clearly
in
the
description
of
the
method:
hey,
if
you
have
other
pointers
to
the
resource
plans,
please
don't
use
them
anymore
after
you
call
this
thing
because
they
may
not
reflect
the
changes
that
you
get
here.
So
that's.
The
idea
in
general
looks
like
let
me
know
if
you
have
any
feedback
to
that
or
any
questions
and
I'm
just
not
going
to
the
implementation
that
I
just
want
to
get
some
feedback
about
the
interface
as
we
provide
here.
K
I
just
have
a
quick
question.
This
looks
really
nice.
How
are
you
handling
like
if
you
drill
down
our,
do
you
have
to
use
mutable
all
the
way
down,
and
if
so,
are
you
making
copies
all
the
way
down
multiple
times,
then.
K
So,
like
you're
getting
the
resource
spans,
so
then
do
you
have
to
get
a
mutable
scope
like
mutable
scope,
spins
and
then
mutable
spans
or
whatever
it's
at
the
bottom
level.
D
A
No,
no
I
think
the
question
is
different.
If
you
go
back
to
your
example,
Dimitri
here
after
a
pandem,
let's
say
append
empty
Dot:
here
you
have,
you
will
have
a
mutable,
you
should
have
a
mutable
resource
somewhere.
No,
no
all.
D
The
API
here
naming
is
the
same,
but
yes
like
everything
will
be
mutable
now
so
resource
will
be
mutable,
so
different,
different
results,
but
the
API
like.
A
The
only
API
change
to
answer
your
question,
then
the
only
API
change
is
this
mutable
resource
plan
or
resource
plan.
Everything
else
stays
the
same
in
terms
of
function.
Names,
yes,.
A
In
the
the,
if
you
don't
do
the
mutable
thing
you,
you
will
miss
some
of
the
functions,
but
they
are
the
same
name.
So
if
essentially,
if
you
do
that
at
zero,
then
then
Dimitri
you
can
show
him
that
you
have
that
something.
You
see
you
have
only
four
methods
or
any
four
things
there
and
then,
if
you
on
the
other
one,
you
have
like
seven
or
eight,
because
then.
G
A
D
For
example,
because
like
in
in
the
tests,
oh
I,
I
have
I
have
some
example
here.
So
you
you
have
your
immutable
immutable
processor,
for
example,
but
in
the
tests
you
need
to
do
this
thing
and
this
thing
will
always
provide
you.
Mutable
map
right
and.
A
So
so
you
provided
a
two
immutable
instead
of
instead
of
okay
makes.
D
Sense,
yeah,
because
you
have
this
method,
that
being
used
in
production
right
in
production
code,
and
you
want
to
test
it,
so
you
need
to
provide
mutable
mutable
object
here.
Immutable
object
here
and
the
only
way
to
make
it
in
test
is
actually
from
mutable,
because
otherwise
you
cannot
I
want
to
change
it.
Okay,.
D
A
D
Cool
yeah
and
gear
is
there
if
you
want
to
take
a
look
and
and
the
implementation
details
please
check
and
review
if
you
want
to,
and
also
it
went
through
several
iterations,
when
you
try
different
approaches
and
this
current
PR,
it
has
at
least
additional
amount
of
code.
A
Quick
things
here
is
going
to
be
a
breaking
change
and
a
bit
a
bit
of
a
big
one.
If
we
adopt
this
so.
A
Are
but
we'll
make
it
to
deprecation,
but
it
will
be
a
lot
of
coaching.
Let's
put
this
way,
we'll
have
to
to
do
some
kind
of
code
change
in
a
lot
of
components,
which
may
mean
that
we
may
ask
the
community
to
help
us
in
the
in
the
country,
because
we
may
not
scale
to
to
do
all
of
the
work
between
me
and
Dimitri.
D
Yeah,
essentially,
all
the
changes
will
be
removing
capabilities
and
in
the
processors
that
the
mutate
data
change
resource
plans
to
multiple
response.
I
believe
those
should
be
the
only
changes
and
in
some
tests,
maybe
change.
G
A
Exporters
and
and
mostly
tests,
as
you
said
in
this
there
anyway,
but
there
will
be
significa
I
mean
there
will
be
lots
of
changes
and
that's
that's
the
whole
thing.
Yes,
you
can
make
it
Dimitri,
as
you
pointed
you
can
make
it
backwards
compatible,
but
not
backwards.
We
can
go
through
the
application
process
that
we
have
to
to
to
not
break
everything.
But
again
we
have
some
couple
of
third
party
depending
on
us,
like
data
dog
like
influx
DB
and
stuff.
A
So
we
need
kind
of
some
support,
because
it's
a
pretty
big
change,
though
it's
only
a
couple
of
apis
changing,
but
it's
it's
significant
change.
So
if
we
commit
to
this,
we
need
the
we.
We
need
some
strong
commitment
from
the
community
and
thanks
Pablo
for
for
for
doing
this,
but
yeah
make
sure
everyone
reads
the
pr
leave
comment.
A
D
J
D
No,
it's
not
resource,
it's
like
the
top
level
from
traces
you
you
have
the
only
method
to
to
get
down
right,
resource
plans
or
like
resource
metrics,
and
you
have
another
method
for
for
getting
mutable
and
then
no
data,
essentially
the
the
only
one.
But
if
you
want
to
create
something
new
you
you
have
all
those
the
same
method
like
new
metrics
or
sorry,
new
log
record,
or
something
like
that,
and
that
those
things
will
give
you
mutable
instances.
D
H
E
So
we
left
I
asked
what
would
be
the
success
criteria
or
deprecating
the
contrib,
and
let
me
make
it
clear
here
in
a
good
trip,
distribution.
E
So
in
the
meantime,
I
I
added
a
couple
of
items,
so
the
view
one
for
the
collector
API
is
a
big
is
a
big
dependency
on
that.
Let
me
just.
E
And
another
thing
is
we:
we
talked
about
guidelines
for
component
developments
so
that
they're
part
of
this
room
like
we
need
to
produce
a
bomb
and
see
if
that
actually
works
and
I
can
work
on
that.
A
I
think
we
should
start
a
process
of
validating
components
and
what
I
mean
here?
Is
we
right
now
one
of
the
things
that
we
do
in
this
country
thing?
We
have
that
components
file
that
we
test
Acro
against
some
of
the
things
like
that
a
component
can
be
started,
restarted
and
stuff,
like
that,
all
these
things
I
would
like
to
to
have
a
way
to
as
part
of
the
validation
or
whatever
enforce
this
somehow
does
it
make
sense
to
you
like
right
now
we
enforce
it
by
having
this
mono
Apple.
E
So
we
think
we
have
the
test
bed.
That
provides
something
for
that.
Something
like
that
right.
So
it
we
can
specify
what
is
the
input
for
your
processor
technological
P
input
and
then
we
validate
well,
we
can't
validate
the
outside.
A
So
so
we
need
a
an
input.
We
need
a
config
for
that
and
an
output,
for
example,
and
that's
one
thing
that
we
can
test,
but
it's
not
only
that,
for
example.
The
other
thing
is
that
we
test
right
now
is
that
the
config
follows
the
the
map
structure,
tags
and
all
the
things
that
we
have,
for
example,
but
this
is
more
or
less
to
help
the
conf,
the
the
component
as
well
so
I,
don't
know.
J
What
do
you
think
for
the
the
test?
Bed,
like
tck,
sort
of
thing
we've
got
the
golden
data
sets
there
right,
so
we
should
have
an
expectation
that
new
components
come
with
whatever
they
need
to
add
to
that
test
pad
to
use
the
golden
data
sets
to
validate
like
they
need
to
bring
a
config
and
validation
of
the
output
of
their
component.
A
J
The
testbed
has
a
mechanism
for
Mark
pack
ends
yeah,
there's
there's
already
one
for
AWS
x-ray
in
there
right.
A
E
F
E
E
This
decentralization
aspect
of
it
because
you
know
it's
it's
much
easier
to
manage
the
CI
for
one
and
second:
is
it
forces
us
to
provide
all
of
those
guidelines
all
of
those
documentations
to
you
to
other
folks?
E
It
doesn't
depend
on
our
current
triple
travel
knowledge
here
that
so
we
know
how
to
create
a
component.
We
know
to
which
places
to
add
references
to
this
new
component.
It
shouldn't.
F
A
What
what
does
it
bring
to
us?
That's
that's
my.
My
question
is
yes,
we
do
that
and
we
have
no
clue
if
the
dependencies
are
aligned
and
when,
when
you
try
to
combine
them,
you'll
hit
the
the
wall.
F
With
yeah
I
mean
it
does,
it
does
make
the
ability
to
to
give
people
like
code
ownership
over
their
repository.
So
you
know
we
could,
instead
of
having
whatever
it
is
now
like
12
people,
who
are
the
only
people
who
can
manage
the
process
of
updating
the
dependencies
and
getting
getting
that
component
to
a
state
where
it's
compatible
with
all
the
versions.
It
does
give
us
the
ability
to
do
that
with
maybe
a
greater
subset
of
contributors.
Yeah.
D
F
And
then
the
the
CI
story
that
jurassi
was
talking
about
would
also
be
simplified
right.
If
you
only
have
to
run
CI
for
your
own
component,
then
at
least
you
have
a
limited
scope
of
what
could
go
wrong.
D
I
think
go
ahead,
I
believe
they
can
diverge.
Significant
land
would
be
a
mess
because,
like
we
have
all
the
consistency
here,
we
we
have
some
in
journal
internal
tooling,
that's
been
reused
in
general
libraries
Etc
and
we
kind
of
having
100.
We
encourage
the
same
style
at
the
same
same
way
like
how
how
like
what
being
written
so
I,
don't
think
I,
I
I,
don't
think
we
should
split
it.
E
Bring
us
I
mean:
why
do
we
care
about
how
good
component
tax
is
written,
or
how
close
it
follows
our
guidelines
as
long
as
it
follows
the
ones
that
we
require
I
mean
at
the
end
of
the
day,
we
are
just
going
to
produce
a
binary
that
is
based
on
a
manifest
that
makes
reference
to
that
repository.
We're
not
even
looking
at
that
code.
E
We
don't
have
to
change
their
codes,
so
if
we
make
backwards,
compatible
changes
to
apis
they're,
not
going
to
break
them
on
N
plus
one,
but
we
can
still
automate
creating
issues
on
their
ripples
telling
them.
You
should
migrate
to
the
new
API
and
let
them
do
the
work
and
if
it,
if
it
breaks
the.
E
If
it
cannot
be
integrated
into
a
release-
and
actually
it's
not
going
to
be
part
of
your
release,
right
we're
not
going
to
have
a
contribute
so
but
I
mean
if
we
have
a
a
continuous
and
likely
distribution
that
is
built
with
everything
it
breaks,
then
it's
on
the
component
that
broke
the
the
the
responsibility
to
fix
it,
which
is
different
than
today
today
is
whoever
is
releasing
or
whoever
cares
about
the
tree.
D
E
H
E
So
it
is
all
theoretical
right
now,
but
if
we
produce
a
bomb
and
after
each
release,
we
require
the
component
like
the
components
that
we
want
to
add
to
a
registry
or
the
components
we
want
to
add
to
whatever.
If
we
require
all
of
them
to
bump
their
their
bond
versions
after
a
release,
then
then
we
we
fix
this
problem,
but.
D
E
D
C
A
D
A
Other
direction
is
to
not
have
it
in
our
org
and
just
throw
it
away
to
everyone
every
company
to
deal
with
this
separately.
How.
E
About
how
about
we,
we
do
an
experiment.
We
have
a
few
new
components
coming
in
that
we
as
a
group.
We
want
to
maintain
like
the
connectors
right,
so
we
have
a
bunch
of
connectors
that
are
being
converted
from
processors
and
and
exporters,
and
so
on.
So
what
about?
We
create
new
repositories
for
those,
and
then
we
try
this
idea
out.
If
that
doesn't
work,
we
bring
them
to
contribute
and
if
it
works,
we
start
splitting
and
and.
A
E
It
contrib
is
not
a
it's,
not
an
official
part
of
the
project,
so
a
contribute
is,
is
officially
not
supported
by
open
cloudry.
Everything
that
is
Dash
contrib
is
not
expected
to
be
on
the
same
level.
That's
that's
my
understanding
of
all
trips.
A
But
who,
who
is
the
maintainer
and
approval
for
that,
like
we
have
these
rules
in
open
Telemetry
that
we
for
every
repo
we
have
to
have
maintainers
and
approvals
with
roles
and
stuff?
Who
are
those
people?
Are
we
artificially
make
new
maintainers
there?
We
can
do
that,
but
but
there
are
rules
in
the
in
the
it
comes
with
a
burden
of
maintaining
all
these
sigs.
Essentially.
Is
that
a
separate
seed
we.
E
Can
have
that
discussion,
I
think
at
the
GC
I'm,
not
part
of
the
GC,
so
I
cannot
bring
it
to
the
TC,
but
I
think
it
is
a
broader
discussion.
I
think
we
did
talk
at
least
at
the
GC
level.
We
talk
about
having
a
open
Trend
Organization
for
that,
because
there
is
such
a
confusion
right
now
right.
So
there
is
people
think
that
there
is
an
expectation
of
contrib
being
supported
as
part
of
open
photometry
in
general,
and
there
is
not
so
Perhaps
Perhaps.
E
I
E
Your
specific
question
I
would
say
that
the
current
code
owners
would
be
the
maintainers
for
the
new
modules.
That's
what
I
have
in
mind
if
they're
part
of
the
same
organization
or
different
organizations,
I
I
personally,
don't
care.
G
D
What
the
exporter
existence
so
I
can
see
the
list
I
can
go
through
one
repository
and
if
it's,
if
it's
like
split
it
across
different
repository
tools,
just
like
it'll
be
hard
for
the
end
users
to
discover
what
they
have,
what
receivers
like
they
can
have,
they
can
use
Etc.
Maybe
we
can
provide
some
weight,
catalog
or
something
but
I
I
I
feel
like
if
we
are
not
that
level.
Yet
when
maybe
maybe
we
can
start
splitting
something
that
is
completely
like
out
of
our
responsibilities,
maybe
yeah,
but
splitting
it.
E
K
I
have
to
say,
I
I
really
wouldn't
like
to
see
us
split.
This
all
up,
I
think
that
the
administrative
overhead
is
huge
and
even
just
maintaining,
like
the
tooling,
that
we
currently
have
available
for
all
the
components.
K
G
J
J
I
think
if
we
move
to
a
separate
repo
hold
into
a
distribution
through
the
Builder,
you
probably
still
have
similar
problems,
but
it
might
be
less
apparent
because
we
won't
know
until
we
go
to
pull
them
all
in
that
there's
something
that
hasn't
updated
and
then
what
do
we
do?
I,
don't
think
we
can
just
add
and
remove
components
from
distributions
at
each
release
just
because
they
didn't
make
the
cut.
You
know
somebody's
going
to
be
using
the
component
on
a
priorities
and
expect
it
to
be
there
in
the
next
release.
I
I
L
The
issue
is
the
shared
dependencies
like
Prometheus,
then.
Doesn't
the
current
like
internal
model
for
AWS
and
kubernetes
utils,
where
you
shim
the
helpers
Provide
support
to
that
so,
like
all
the
components
that
use
Prometheus
features
directly,
would
use
that
shim
and
that
one's
locked?
And
then,
when
you
want
to
update
that
that
Prometheus
version
it
would
the
shame
would
be
updated.
But
the
consumers
would
not
have
to
update
their
code.
L
The
shared
ones
I
mean
that's
like
the
point
of
the
shared
internal
helper
right.
E
L
Well,
you
you'd
see
how
they're
actually
used
and
if
it's
all
transitive,
then
you
can
just
have
a
replace
directive
in
their
respective
mods
and
then,
if,
if
they
are
directly
using
it,
then
they
are
supposed
to
be
sharing
that
but
either
way
you're
locking
it
to
the
one
Prometheus
version
or
the
one
shared
dependency
version.
A
I
think
we
should
not.
We
should
not
have
dependencies
to
be
honest,
I'm
still
thinking
that
the
bomb
is
the
solution
like
we
should
not
have
Prometheus
dependency.
Prometheus
is
not
intended
to
be
a
dependency,
they
break
the
apis.
They
do
all
the
things
because
they,
they
clearly
told
us
that
they
are
not
intended
to
be
used
as
a
library
and
I
think
we
should
fix
this
kind
of
things
like
we
should
use
only
artifacts
that
are
built
to
be
used
as
library
that
guarantee
API
compatibility
and
stuff
like
that.
A
L
Or
at
least
Harden,
the
like
the
surface
area
or
the
contract
that
the
components
are
relying
on
just
being
very
explicit
in
what
the
dependency
is
and
not
having
it
just
kind
of
background.
Yeah.
F
Foreign
but
I
think
this
is
a
good
discussion
to
have
I
do
think.
I
agree
with
Antoine
that
the
bomb
idea
is
probably
going
to
solve
most
of
the
issues
we
were
seeing
here
and
kind
of
force
us
into
limiting
the
number
of
new
dependencies
that
we
take
on
I
mean
we
kind
of
have
a
known
official
bomb
right
now,
which
is
just
a
go
mod
and
the
repository,
but
I
think
we've
been
kind
of
ignoring
it
a
little
bit
too
much
so
anyways
I'll
try
and
wrap
up
the
release
today.
So.
E
F
E
So
is
there
an
action
item
for
me
here,
Alex,
perhaps.
F
Maybe
we
can
just
open
issues
around
the
the
discussion
points
around
anything.
That's
not
already
covered
by
an
issue
and
in
the
repo
I
think,
I.
Think
some
of
those
already
have
like
the
docker
image
for
the
Builder,
for
example,
I
think,
is
an
issue,
but
anything
like
creating
the
bomb.
I
think
is
a
good
good
one
to
capture
in
a
new
issue.
All.