►
From YouTube: 2020-10-27 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).
C
C
D
D
D
Okay,
good
morning,
folks,
I
have
a
few
items:
the
top
of
the
list.
First
off
the
status
of
the
issues,
we're
tracking
towards
ga.
We
had
a
productive
issue,
scrub
session,
a
spec
issue,
scrub
session.
On
friday
we
went
over
spec
issues
or
types
of
issues,
proto
issues.
There
were
some
that
I
missed
for
that.
I
think
we
should
take
some
time
to
triage
this
morning
and
it
is
because
they
changed
state,
so
there
were
kind
of
older
ones.
F
Ga,
but
I
think
it
should
be
allowed
for
ga,
mainly
because
I
made
up
a
request
to
solve
it,
but
also
because
I
think
it
should
be
a
non-breaking
change
or
anywhere
change
to
semantic
conventions.
F
F
And
this
is,
I
think,
the
only
semantic
convention
that
can
have
either
of
two
types,
every
other
semantic
convention
has
a
certain
type.
So
this
is
a
bit
odd
and
also
not
supported
by
the
generator
tool.
D
D
H
G
F
F
C
F
All
right
there's
that
one,
this
one
is
related
to
that.
The
problem
here
is
that
we
have
the
process
that
runtime
attributes
and
the
process
attributes
in
the
same
resource
and
the
pit
is
required.
So
now,
if
you
want
to
report
the
jvm
version,
you
have
to
set
the
pit,
and
this
is
kind
of
a
spec
defect.
In
my
opinion,
I
don't
know
a
critical
one.
D
D
K
K
C
No
I'm
just
asking
if
anybody
on
this
call
has
a
problem
with
that.
I
don't
have
a
problem
with
that.
Personally,
I
I
think
it's
it's
even
better
than
it
is
now.
I
And
if
the
result
is
it
becomes
the
recommended
approach
like
we
ask
all
the
instrumentation
library
to
follow
this,
then
it
will
be
a
big
change
and
probably
not
allowed
for
you.
D
I
The
on
the
outcome,
if
this
one
is
saying
like
it,
is
okay
to
put
this,
but
the
events,
the
existing
implementation
library,
to
put
this
as
a
span
name,
then
I
I
think
the
change
should
be
reasonable
to
be
part
of
ga.
If
they
ask
this
is
a
mandatory
thing,
all
the
instrumentation
library,
for
example
the
python
like
a
db
wrapper,
it
should
put
select
as
a
span
name.
Then
I
think.
B
D
C
F
D
H
All
right,
I
think,
that's
fine.
There
is
a.
J
G
F
D
H
G
Maybe,
except
we
only
scrub
this
issue
every
week,
this
repo
every
week,
so
I
think
it's
important
to
see
it
when
we
go
through
here.
We've
we've
had
a
meta
discussion
about
how
it'd
be
nice.
If
we
had
a
like
a
metrics
project
where
we
could
just
go
through
all
the
metric
issues,
but
that's
spread
across
three
or
four
repos.
D
D
Required
to
clear
freeze,
let's
change
them:
okay,
we're
good
everything's,
been
scrubbed,
we're
up
to
date
related
to
this
issue,
but
related
to
these
triages
sessions.
D
On
the
friday,
so
that
way,
it's
just
clumped
with
regulation
of
all
issues
in
general,
as
opposed
to
just
triaging
in
the
metric
stick.
So
that
way
we
have
the
prioritizations
ready
for
the
metric
six
when
we
meet
for
that.
But
I
also
notice
the
sub
sig
metric
stick
was
is
split
off
from
this
spec
sig,
even
though
it
touches
on
points
related
to
spec.
So
I
just
want
to
plant
the
scene
in
people's
minds
that
when
would
there
be
appropriate
time
if
it's
helpful
or
desirable
to
bring
the
metric
sick.
D
I
D
Okay,
we'll
need
coordination,
of
course
across
for
the
people
on
the
metric
sick,
to
make
sure
that,
like
that
works,
so
I
can
work
towards
looking
for
the
inflection
point
or
the
timing
of
when
that
would
be
appropriate
in
the
coming
weeks,
if
that's
desirable
across
the
two
different
groups-
okay,
so
I
just
wanna
hit
that
point
so
overall
p1
issues
before
we
did
the
triage.
This
needs
to
be
updated
now,
but
at
least
as
of
this
morning,
before
the
meeting
we
had
eight
to
do's,
all
of
them
are
like
metrics
related.
D
I
believe
they'll
call
the
metrics
tab
on
them.
Yes,
because
we've
been
rolling
on
these
three
issues,
that's
in
progress,
one
of
them
has
got
a
metrics
and
one
of
them
spec
and
the
other
one's
miscellaneous.
D
D
I
think
carlos
might
put
this
after
an
upcoming
item.
Open
sampling
part.
Yes,
yes,
he
did
okay,
okay,
so
I'm
done
with
that
topic
item
and
we
can
talk
more
detail
later
on
in
this
below
for
this
next
item.
D
I
kind
of
needed
bogdan
on
the
call
for
this
to
finish
the
scrubbing,
so
all
the
maintainers
may
be
able
to
start
categorizing
where
they
are
in
terms
of
the
implementation
of
every
one
of
the
items
in
the
trace
table
and
also
the
context
propagation
table.
I
brought
this
up
to
maintainers
meeting,
but
this
still
carries
forth
that
I
think
we
still
need
some
more
information
in
here
java
javascript
python
had
a
good
number
filled
out
go
also,
but
needs
some
love
in
the
context.
D
D
D
This
was
a
google
doc
that
was
created
like
a
month
ago
in
order
to
track
the
overall
high
level
issues
related
to
ga
outside
of
just
the
spec
documentation,
performance,
testing,
integration
testing
and
they
cut
across
all
the
different
language
sticks
with
owners,
and
I
I
had
a
scrub
of
this
spreadsheet
in
order
to
get
the
latest
update
of
where
statuses
are
and
who
the
current
owners
are.
D
I'd
like
to
be
able
to
track
this
in
in
issues
in
github,
so
I
can
apply
the
same
tracking
techniques
with
a
project
and
labels
and
whether
they're
in
progress
or
not.
So
this
is
what
I
propose
and
I
need
someone
to
help
me
because
I
don't
have
the
github
permissions
to
do
it
to
create
a
github
project,
called
open,
telemetry,
ga
high
level
items
and
then
also
create
a
new
label
called
area.
Ga
tracking,
and
with
that
I
can
attach
issue
tracking.
D
I
can
track
issues
that
represent
these
items,
so
we're
tracking
github
instead
of
instead
of
here
and
then
we
can
have.
D
D
Okay,
all
right
thanks
sergey.
So
specifically,
this
is
in
the
spec
repo
that
I'll
need
these
applied
thanks
very
much.
D
B
B
Yes,
so
one
thing
I've
been
going
around
doing
is
running
some
workshops
to
get
people
involved
in
the
beta,
and
so
I've
been
playing
a
lot
more
with
open,
telemetry
and
there's.
Definitely,
you
know
bumps
and
wiggles,
and
things
going
on
as
we're
still
in
beta
and
one
way
it
would
be
great
to
sort
of
test
drive
all
of
this
stuff,
one
from
the
perspective
of
spec
compliance.
Does
this
feel
the
same
in
this
language
as
my
language
and
the
other
from
maybe
just
does
it
work?
B
B
So
one
thing
I'm
looking
for
is
is
volunteers,
first
and
foremost,
people
who
think
that
have
the
cycles
to
just
pick
one
other
language
other
than
the
one
you've
been
working
on
and
to
give
it
a
test,
drive
see
if
you
can
run
the
examples,
get
started
with
it
and
otherwise
go
through
the
list
of
things
that
are
in
the
compliance
matrix
and
try
them
out
in
that
language.
B
So,
first
and
foremost,
would
be
great
if
people
are
interested
in
doing
this,
if
you
could
just
sign
up
in
the
doc
there's
a
section
in
the
spec
doc
right
now,
you
can
see
me
carlos
tristan
and
daniel,
have
signed
up.
So
that
would
be
a
great
way
to
start
it.
B
If
we,
if
we
don't
get
enough
people
doing
it
on
a
volunteer
basis,
then
we
might
start
requesting
a
little
more
firmly
that
that
maintainers
or
or
approvers
or
other
senior
people
do
some
kind
of
like
rotate
one
language
to
the
left.
Try
that
language,
so,
first
and
foremost,
if
there
are
volunteers,
we
like
to
start
it
that
way,
and
I
think
actually
is
bogdan
on
the
call
because
bogdan,
I
think,
also
had
some
thoughts
on
this.
B
B
So
so
that
that's
what
I
like
to
start
initial
little
coalition
of
the
willing-
and
if
not,
if
that,
doesn't
end
up
getting
enough
beta
testing
going
on,
then
I
would
be
open
to
proposals
for
how
we
can.
We
can
do
this
beta
testing
effectively
without
totally
snowballing
people's
busy
schedules,
which
they
have
to
do
because
they're
not
seeing
anyone
sign
up.
B
In
this
just
in
our
document
right
here,
so
if
you
look
where
andrew,
if
you
want
to
highlight
it,
maybe.
B
So
I
think
that's
the
the
next
question
here.
It's
a
good
question
is
we
only
want
to
do
this
for
a
language
if
that
that
language
feels
like
it's
ready,
if
a
language
like
say
ruby
feels
like
you
know,
we're
just
we're
not
there
yet
or
we're
there
yet
on
tracing,
but
but
not
on
metrics.
B
That
is
a
thing
we'd
like
to
to
clarify.
So
I
think
the
reversal
of
this
is
if
maintainers
could
list
whether
they're
they
think
their
project
would
like
something
like
this
right
now.
So
I
don't
have
andrew,
would
you
mind,
maybe
adding
a
section
for
that?
Just
real
quick,
so
I
kind
of
you
know
certainly
go
java.
Javascript
and
python
are
languages
that
we're
thinking.
Are
there
already,
I'm
not
sure.
If
c
sharp
is
in
in
a
state
where
you'd
like
this
kind
of
feedback.
L
B
That
that's
awesome
and
I
do
want
to
stress
it:
it's
not
certainly
not
limited
to
to
people
who
work
directly
on
the
project.
The
main
interest
would
be
one
of
the
main
reasons
we'd
be
interested
in
maintainers
and
other
people
closer
to
the
project.
In
addition
to
end
users
is,
is
the
spec
compliance
side?
I
don't
think
that
an
end
user
might
not
be
able
to
notice
that,
but
I
do
think
end.
Users
are
going
to
tell
us
how
confusing
it
is
to
get
started
and
that's
that's
going
to
be
good
feedback.
B
Okay,
cool
yeah,
so
maybe
that's
a
shout
out.
Does
anyone
else
here
think
they
could
rally?
Maybe
some
help
at
work
or
some
interns
or
otherwise?
You
could
add
yourself
to
that
list
and
just
mention.
B
B
And
last
but
not
least,
if
anyone
wants
to
help
running
this
kind
of
user
study,
I'm
always
looking
for
help
on
that
front.
We
don't
have
a
super
concrete
plan
at
this
point,
so
if
someone's
run
one
of
these
in
the
past
and
has
ideas
for
what
an
effective
way
to
organize
it
might
be,
I
would
love
that.
C
C
B
And
there's
certainly
a
lot
of
flux
going
on
right
now.
You
know,
for
example,
using
java
today
you
know
it
doesn't
seem
like
baggage
is
working
quite
yet
stuff
like
that.
I
think
a
lot
of
this
is
in
the
spec
compliance
matrix,
but
that's
the
stuff
we
wanna,
we
wanna
double
check
cool,
all
right
that
looked
like
a
good
list
of
volunteers
to
get
started
with.
Thank
you
so
much
again.
If
people
want
to
volunteer,
you
can
get
a
hold
of
me
or
andrew.
N
I
have
a
quick
question,
actually
rolling
back,
just
something
I
realized
when
you
were
saying
baggage
wasn't
working
in
java.
It
is
working
currently
on
the
main
branch.
It's
not
working
on
a
published
release.
Yes,
so
my
question,
though,
is
what
should
we
be
filling
in
to
the
compliance
matrix?
O
I
think
what
is
in
the
main
branch?
That's
like
looking
forward
right,
I
mean
given
the
fact
that
we
are
we
more
or
less
relatively
often
releases.
You
know.
B
Yeah,
I
I
would
agree
with
with
that
that
maybe
the
compliance
matrix
should
be-
I
don't
know
I
could.
I
could
go
both
ways,
maybe
updating
that
compliance
matrix
should
be
part
of
doing
a
release.
Maybe
that's
a
scene
or
way
to
do
it.
K
I
think
the
whole
point
of
the
compliance
matrix
is
to
look
and
see
what
work
still
needs
to
be
done.
We're
not
going
to
release
until
it's
fully
filled
in
like
we're,
not
ga
until
it's
fully
filled
in
anyway.
So
we
don't
expect
customers
to
go
look
there.
So
I
think
it's
if,
if
the
work
still
needs
to
be
done,
it's
not
in
the
matrix,
I
think
you
follow
master.
B
B
Yeah,
that's
that's
the
problem,
especially
if
you're
not
super
familiar
with
the
language
and
that's
maybe
sort
of
what
we're
going
for
trying.
You
know
if
you're
gonna
be
trying
a
language.
That's
not
not
your
forte
you're
sort
of
simulating
being
someone
who's
who's,
not
like
an
expert
user
trying
to
get
started.
We
do
want
to
make
sure
that
those
people
can
can
at
least
get
started
with
with
open
telemetry
right.
K
You
should
have,
I
think,
a
minor
feature
missing
from
the
matrix
that
is
implemented
in
master,
but
not
yet
released
is
not
that
big
of
a
deal
for
this
use
case
because
we're
looking
for
like
globally.
How
easy
is
this
to
use
in
general
and
all
of
those
big
sweeping
things,
hopefully
should
have
been
done
a
long
time
ago.
K
B
I
don't
know
baggage
is
a
good
example
of
something.
That's
you
know
a
pretty
core
component.
That's
that's
there
now
in
master,
but
not,
but
I
agree
with
you
as
time
goes
on.
This
is
gonna
shrink,
but
I
know:
would
it
be
too
much
work
to
just
do
follow
christian's
suggestion
of
maybe
not
going
to
have
to
go
back
in
time
and
listen
that
will
find
exactly
the
release
something
was
put
in,
but
but
at
least
mentioned
going
forward
that
something's
in
a
release
or
on.
K
B
Anyways,
I
don't
want
to
over
complicate
it,
that's
maybe
a
more
minor
thing,
though
we
will
potentially
get
feedback
from
end
users,
saying
hey.
K
B
B
Cool
okay,
so
we'll
we'll
try
to
to
get
some
organization
behind
this.
I
know
bogdan
had
some
ideas
about
this
as
well,
so
I'm
going
to
poke
him
and
again
reach
out.
If
you
have
ideas
would
like
to
help
run
some
user
research
on
open,
telemetry.
D
Okay,
I
we've
got
some
items
for
carlos
and
yes
would
you
like
me
to
continue
sharing
to
help.
O
Please
yeah
thanks
so
much
yeah
yeah.
Basically,
we
have
a
few
items
that
are
important
enough.
I
think
for
us
to
pay
attention
well,
this
one
is
a
marching
field
is
in
and
this
is
about
providing
guidelines
for
pluralization
in
attributes.
There's
some
discussion
going
on,
so
please
pay
attention
to
that.
My
impression
by
the
way
is
that
this,
since
this
is
more
like
a
suggestion
and
a
guy
or
a
guidelines,
this
should
be
marked
well,
they
should
know
the
pr
or
maybe
both
as
allow
for
ga
instead
of
required.
O
I
don't
know
what
other
people
think
about
this
yeah.
Maybe
you
can
yeah.
This
yeah
currently
is
required
for
ga.
So
my
gut
feeling,
as
I
said,
is
that
this
should
be
required
allowed.
P
Yeah,
I'm
fine
with
making
this
allowed
for
ga.
I
think
that
we're
essentially
following
this,
because
this
is
essentially
a
generalization
on
what
we've
been
discussing
during
the
beginning
of
the
call
like
this
thing
for
process
command
line
and
providing
arguments
and
etc.
So
it's
it's
a
guideline
at
the
end
of
the
day,
and
it
seems
that
we
have
only
one
attribute
currently
this
that
is
going
to
be
associated
with
a
guideline,
namely
this
process
command
line.
Arguments.
G
Yeah
there
were
some
questions
in
this
kubernetes
processor
pr
about
when
you
might
see
more
than
one
container
name,
and
I
asked
for
some
clarification.
I
think
what
we
should
put
in
the
guideline
is
that
we
think
of
these
as
single
entities.
G
So
if
there
are
potentially
multiple
values,
you
should
think
of
it
as
a
single
list
and
the
only
other
one
that
I
know
of
is
for
tracing.
We
have
http
headers
right
that
might
have
multiple
string
values
and
that's
why
we
first
introduced
lists,
so
we
should
think
of
it
if,
if
necessary,
to
use
http
headers
of
a
attribute,
we
can
think
of
it
as
a
singular
value,
which
is
a
list
of
strings.
I
think,
and
I
wrote.
G
O
Okay,
yes,
oh
go
ahead:
carlos
yeah!
Sorry,
no!
It's
just
like
a
court
that
somebody
was
about
to
say
something,
but
I
guess
not
in
any
in
any
case
yeah,
since
it
seems
that
there's
stuff
to
discuss.
Please
do
that
there,
but
we
really
need,
as
I
said,
reviews
you
know.
So,
please
please
help
us.
There.
G
So
so
I
think
we
should
accept
christian's
pr
to
expand
the
representation
of
command
line
to
resolve
the
central
issue.
Here
there
is
an
open
question
about
kubernetes,
processor
and
container
names
and
what
they
might
be
plural,
but
that's
that's
independent
of
this
particular
issue.
I
think
we
can
close
these
if
shane
agrees.
P
Yes,
so
for
kubernetes,
specifically
the
discussion
that
triggered
this
issue.
Essentially,
it
was
leading
towards
not
having
multiple
values
for
that
container
name
attribute.
So
it's
no
longer
an
issue
for
kubernetes.
So
this
is
just
like
a
helpful.
O
Okay,
so
shall
we
mark
it
for
the
starters,
allow
for
ga
and
then
marching
christian
and
j
magni
can
iterate
this?
Does
that
make
sense.
F
M
G
And
the
same
was
said
of
christian's
pr,
so
we
should
do
this
here
and
but
I
think
this
will
be
easy
to
resolve.
We
just
have
to
go
far
follow
1167
in
the
contributor,
which
is
independent,
yeah
yeah.
G
F
I'm
not
sure
if
this
pr,
so
this
pr
renames
the
so
solves
this
issue
with
process
dot
command
line,
but
it
does
not
add
prioritization
guidelines,
so
that
would
be
separate
pr.
If,
if
that's
what
you
mean,
oh
there
is
already
apis.
O
D
O
Sweet,
so
that's
one
one
of
the
issues.
The
next
one
is
about
hotel
trade
sampler.
I
fill
this
in
it's
something
very
simple
already
I
mean
provided
some
initial
feedback.
O
As
I
said,
it's
super
simpler
and
we
need
this
one
to
resolve
another
issue
that
trusts
field,
because
basically
we
want
to
avoid
having
different
language
implementations,
having
different
hotels,
something
priority
formats
or
values
so
yeah.
This
is
super.
Simply
super
minimalistic,
john
and
jim
mcd
already
reviewed
this,
but
I
need
people
who
are
heavy
users,
or
at
least
they
are
very
familiar
with
sampling
and
with
the
current
samplers
that
this
is.
You
know
it's
like
simple,
but
correct.
O
Yeah.
Okay,
so
I
guess
that
that
that's
it
that's
the
one,
as
I
said
simply
enough,
so
I
will
probably
merge
it
by
tomorrow
or
day
after
tomorrow.
There's
no
other
feedback,
simple
enough
yeah.
Just
please
take
a
look.
D
O
Well,
actually,
we
need
it
because
it's
so
yeah
the
small
detail
is
that
the
other
issue
that
is
related
to
this,
which
is
auto
sampling
priority,
is
that
that
one
is
required
for
gi.
So
this
one
is
needed
to
solve
that.
It's
not
the
actual
fix,
but
it's
a
related
change.
D
If
we
can't
fix
this
one,
we
can't
fix
the
p1.
Yes,
in
any
case,
how
about
I
leave
the
labels
of
area
and
spec
perfect,
make
sense
yeah,
and
this.
O
One
is
blocking
on
yeah.
Actually,
you
can
probably
go
to
the
yeah
there.
You
are
that's
the
one
and
actually
that's
the
next
item
on
the
agenda.
This
is
something
the
trask
field,
and
the
thing
is
that
we
have
different
formats
and
values
for
different
implementations.
O
Yeah
yeah
yeah
yeah
yeah.
If
you
go
to
the
other
one,
you
will
see
that
there's
a
comment
john.
He
suggested
that
we
don't
even
have
a
way
to
define
a
sampler,
so
we
don't
want
to.
You
know
just
do
magic.
You
know,
like
you,
have
this
other
variable
and
you
are
not
specifying
what
sampler
you
are
using.
D
O
C
O
O
F
Yeah,
this
is
also
about
sampling.
I
think
we
have
no
spec
for
when
to
if
a
new
id
should
be
generated.
Also
if
the
span
is
dropped
or
not
sampled-
and
I
was
wondering
if
this
should
actually
be
required
for
ga
to
solve
this.
F
Because
I
think
there
is
mainly
the
decision
between
if
you
have
a
parent
span
and
the
child
span
is
not
sample,
is
dropped
or
not
recorded
especially
dropped.
Do
you
reuse
the
parent
span
id
or
do
you
generate
a
new
span
id?
I
think
this
is.
This
is
the
main
decision
to
make
here
and
in
any
case,
if
we
decide
not
to
to
always
generate
the
new
span
id,
we
should
write
it
down
in
the
spec,
because
I'm
not
sure
if
or
6
or
language
6
aligned
here
how
do
here
how
they
behave.
F
F
O
Yeah,
I
think
we
need
people
who
are
into
sampling
here
I,
but
for
the
record.
I
took
a
brief
look,
and
I,
if
I
remember
correctly
from
by
that
from
that
time,
is
that
yeah
different
languages
have
slightly
different
details.
So.
G
F
I
think
performance
is
not
the
main
concern.
I
think
the
main
concern
is
it's
a
difference
in
behavior
right.
If
you
have,
especially
if
a
child
span
is
then
sampled
again
of
the
unsampled
parent,
which
might
happen
in
some
with
some
samplers.
For
example,
if
you
have
an
always-on
sampler
in
a
in
a
child
spin,
and
if
you
reuse
the
parent
span
id,
you
will
have
the
last
span.
That
was
sampled
as
parents
and
if
you
have,
if
you
always
generate
the
new
spanish,
you
will
have
the
unsampled
spanish
parent.
F
That
will
never
arrive
at
the
back
end,
so
we
will
have
a
disconnected
trace.
Probably
yeah
performance
would
also
be
a
bit
better
if
you
reuse
the
parent
spanish,
but
that's
not
what
we
should
be
most
concerned
about
here.
G
G
F
What
is
mortis
is
not
only
this
might
I
mean
it
might
change
how
most
six
do
it
today,
but
it's
also
something
that
is
not
specified
at
all
today.
I
think
so,
even
if
we
say
generate
the
new
span
id
always,
this
is
also
something
that
we
should
put
in
the
spec.
G
G
O
O
F
O
I
could
be
fine
with
that
yeah
yeah
mcd,
what
or
anybody
else
you
guys
have
opinion
on
this.
O
J
B
D
D
This
is
the
associated
issue.
Yes,
it
is
I'm
going
to
take
off
these
labels,
stale
hello
and
leave
this
yeah.
O
M
Yeah,
so
I
just
have
I
had
some
questions
around
otlp
stability
like
right
now,
if
you
look
at
say
the
proto
definitions,
they're
all
labeled
as
v1,
there
are
releases
of
the
collector
with
this
v1
right
and
from
what
I
understand.
M
Only
some
pieces
are
considered
stable
and
some
pieces
are
not
considered
stable,
and
so
my
my
concern
here
is
that
I
think
people
will
look
at
the
whole
thing
as
a
protocol,
not
pieces
of
it,
and
I
I
I
think
the
cat's
out
of
the
bag
in
some
sense
of
there's
already
hey,
go
use
the
collector
right.
What
what
are
our
expectations
like?
What
do
we
want
to
be
communicating
to
the
community
about
this
like?
If
you
look
at
this
maturity
level?
M
You
know
logs
is
not
mentioned
at
all
in
the
maturity
level,
but
there
is
a
v1
logs
proto
in
the
proto
definition
right,
and
so
I
think,
there's
a
mixed
message
going
to
people
where
we
label
something
as
v1
and
then
in
here
we
try
to
say
it's
stable
or
alpha,
and
I
don't
think
the
the
communication
is
crystal
clear.
I
guess
is
what
I'm
saying.
Q
Q
Q
M
M
Okay,
so
so
two
things
one
is
the
blog
articles
and
like
how
to
get
started
with
open
telemetry.
They
don't
necessarily
include
the
warnings
and
I
think
that's
that's.
The
primary
issue
is
there's
all
these
blog
articles
saying
hey,
go
use
this
go
use.
This
go
use
this
and
then
there's
this
big
section
of
it.
That's
like
danger,
don't
use
this
right
so
that
that
I
think,
is
a
problem.
M
M
Q
Yeah,
I
don't
think
we
want
to
do
that,
especially
right
now.
That's
that's
a
lot
of
work
to
us
to
start
supporting
two
versions
of
the
incompatible,
possibly
potentially
incompatible
protocols
out
of
the
box,
make
sure
that
two
versions
inter-operate
properly
on
the
network.
That's
that's
a
lot
of
work
and
I
think
it's.
This
is
exactly
the
wrong
time
to
try
to
do
that,
because
we're
in
on
the
defense
of
realism.
M
Q
M
Okay,
yeah,
I
I
don't
see
that
with
people
I've
talked
to,
I
think
they
they
think
they
can
start
relying
on
things
even
like
the
logs
api,
which
isn't
even
mentioned
right
and
they've.
Read
this
so
yeah
the
message,
I
don't
think,
there's
a
consistent
message
coming
out
and-
and
I
just
wanted
to
kind
of
get
clarity
from
the
sig-
what
the
expectation
is
going
forward
and
make
sure
that
we
kind
of
correct
our
communication.
J
D
Cool-
it's
I'm
just
hearing
this
from
observing
this
conversation
is
it
said
that
perhaps
there
needs
to
be
another
row
for
logs
here
this
table
to.
Q
Q
That
is
the
reason
that
it's
not
listed
even
here,
so
it's
kind
of
not
even
documented
that
it
exists.
If
you
look
at
the
login
capabilities
in
the
collector,
the
vast
majority
of
the
functionality,
there
is
also
either
either
disabled,
hidden
or
not
documented
there.
It's
that's,
that's
a
deliberate
right.
We
intentionally
did
not
advertise
logs
because
we
don't
think
it's
it's
ready
for
any
sort
of
thing.
C
And
I
just
wanted
to
say
thank
you,
george,
for
bringing
it
up.
I
don't
think
I
mean
I
clearly
see
the
issue
of
people
making
wrong
assumption
and
whenever
you
see
the
incense
and
it's
not
super
clear,
please
feel
free
to
contribute.
We,
I
I
think
it's
not
done
from
a
good
place.
We
just
don't
have
enough
resources
to
cover
all
this,
like
double
versioning
and
contribution
in
both
versions
and
having
incompatible
versions
and
like
transition
customers
so
going
forward.
M
Is
there
a
way
we
can
avoid
releasing
the
protos
that
say
they're
v1
that
aren't
considered
stable?
Yet
when
you
like,
when
we
bundle
say
stuff
I
mean,
is
there?
Is
there
anything
we
can
do
technologically
to
reinforce
these
points
right
to
like
force
people
to
use
github
master
to
get
the
stuff
when
it's
not
ready?
You
know
that
sort
of
thing
basically
make
it
feel
dirty
to
use
something
that
we're
not
hopefully
using.
C
E
Okay
guys,
so
I
just
want
to
kind
of
sorry
carlos.
You
want
to
kind
of
follow
on
this
one
with
josh
kind
of
brings
up
a
really
good
point,
because
we
are
going
into
kubecon
coming
up.
We
released
that
blog
post
and
I
think,
he's
kind
of
pointing
out
some
like
really
important
things
about
communication
and
how
we
go
forward.
I
know
specifically
even
on
this
call
we've.
E
You
know
just
kind
of
off
the
cuff
assumed
that
everyone
is
going
to
understand
that
the
sdk
may
still
have
some
changes
after
the
fax
from
the
api
and
that
may
not
essentially
be
communicated
either.
So
I
think
that
maybe
this
should
be
thought
of
more
of
like
a
retrospective
of
maybe
some
of
the
failings
and
the
communication
side
of
things,
and
we
should
try
to,
I
think,
holistically,
look
at
a
way.
We
can
do
better
going
forward.
O
Yeah,
that's
why
I
suggest
within
an
issue,
so
we
don't
forget
because
I'm
afraid
that
you
know
this.
This
is
very
interesting
and
we
need
to
take
this
into
the
ground,
but
I'm
afraid
that
we
will
be
too
busy
with
other
stuff,
and
we
will
forget
about
this
and
yeah
as
far
as
said
going
forward
with
qcon.
We
need
to
make
this
super
clear.
So,
let's
I
will
create
an
issue
for
that
and
let's
try
to
reiterate
on
that.
I'm
thinking
about
what
we
can
do
to
make
things
clearer.
O
Thanks
sergey,
okay,
I
have
one
more
issue,
but
we
don't
have
time
just
verify.
Just
please.
If
you
have
time
or
review
that
it's
b3
clarifications,
I
will
probably
merge
once
it's
updated
with
the
latest
hoodies
and
that's
it.
Thank
you,
everybody.
It
was
an
interesting
call
and
see
you
next.