►
From YouTube: 2020-12-08 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
B
B
C
I
don't
think
we've
met.
I
recently
joined
google
and
I'm
going
to
be
the
I'm
going
to
be
a
a
manager
on
the
open,
telemetry
team.
So
I
know
that
you
were
there.
You
know
that
you
were
at
google
earlier
and
you
know
I'd
love
to
meet
up
at
some
point.
If
you
have,
if
you
have
some
time.
E
Just
a
reminder
for
everyone,
please
sign
in
to
the
attendance
part
and
note
this
is
the
12
8
meeting,
not
the
12
10
metrics
sig
meeting.
E
Yes,
yes,
it
is
I'm
on
the
road
and
my
partner's
sleeping
inside
our
airbnb,
so
I'm
doing
her
a
solid
and
taking
this
meeting
outside
but
yeah.
This
is
this
is
what
I
do
for
open
telemetry
I
freeze,
let's
get
started,
we've
got
a
pretty
big
packed
agenda.
E
I
would
like
to
jump
the
line
and
talk
about
this
versioning
dock,
because
last
time
I
left
it
to
the
end,
and
then
I
had
to
leave
early.
So
I'd
like
to
to
go
over
this.
First
and
foremost,
let
me
share
my
screen,
real
quick,
just
to
show
people
what
we're
talking
about.
E
So
if
people
haven't
been
following,
we
are
trying
to
figure
out
versioning
and
stability
for
open
telemetry,
specifically
for
the
open,
telemetry
clients
and
everything
that
would
go
along
with
them.
So
that's
api,
sdk
semantic
conventions
and
contrib
I've
put
together
an
otep
here,
that's
getting
some
good
comments
and
we
want
to
get
this
solid
by
end
of
week,
so
we're
on
a
very
tight
timeline.
E
Please
check
this
out
and
my
next
request,
specifically
for
maintainers,
though
anyone
working
on
a
sig
can
help
their
maintainer
do.
This
is
to
come
up
with
an
example
of
how
this
versioning
dock
works
in
your
language.
So
this
is
across
language,
versioning
and
stability
proposal,
but
every
language
has
very
specific
things
around
what
it
means
to
be
backwards
compatible
and
how
artifacts
are
shift
shift
and
things
of
that
nature.
E
So
reading
through
this
document,
I
added
some
more
pretty
graphs
people,
people
like
the
the
infographics,
but
but
please
look
through
this
and
produce
a
language
specific
example
of
based
on
this,
how
you
would
version
tracing
from
experimental
to
stable
and
then,
after
that
version,
metrics
from
experimental
to
stable
and
identify
any
language,
specific
details
that
that
would
need
to
be
added
so
that
a
version
of
this
can
go
into
your
language
repository
that
speaks
directly
to
how
things
would
work
in
that
language.
E
And
I'm
asking
that
in
this
tracking
issue,
so
I
posted
a
link
to
this
tracking
issue,
but
this
has
the
details
here
and
I'd
like
to
give
a
shout
out
to
john
watson
added
a
great
example
of
this
right
here
to
java.
So
I
would
say
please
have
a
look
at
what
john
did
here,
because
I
think
this
is
like
a
perfect
example
of
what
I
was
requesting
from
people,
and
you
can
see
it's
already
created
some
some
comment,
some
discussion
within
the
java
community
about
this.
E
So
that's
my
big
pitch.
My
hope
is
to
see
these
things
tomorrow.
So
this
is
like
super
short
deadline.
So
please,
if
you
are
interested
in
this
work
on
it
today,
because
we
want
to
get
this
sorted
out
by
friday
and
I
need
feedback
tomorrow
if
we're
gonna
hit
that
so
big
shout
out
to
john
for
making
this
happen
for
java.
E
So
that's
my
spiel.
Hopefully,
people
have
heard
it
before,
and
I'd
like
to
take
some
time
now
to
to
synchronously
deal
with
any
questions.
People
have
that
have
been
coming
up.
It
seems
like
from
the
java
java
camp.
There
have
been
questions
around
the
api
stability
stuff
seems
to
be
a
little
more
straightforward,
but
for
the
sdk
stability
is
bringing
up
questions.
H
E
H
Yeah
so
there's
a
few
things
that
came
up
and
I
actually
think
there
is
some
question
on
the
api
side
as
well.
Yeah
honorable
had
an
interesting
point
and
I
don't
know
how
much
this
applies
only
to
java
or
it
does
also
applies
to
other
languages.
But
the
the
issue
is
here.
So
if
we've
got,
let's
say,
we've
got
a
library,
that's
instrumented,
with
open
geometry.
1.0.0
with
the
api
is
from
open,
telemetry,
1.0.0
and
an
operator
installs
sdk
version
1.5.
D
H
H
Definitely
less
of
an
issue
on
the
agent
side
since
it
installed
his
own
sdk
and
kind
of
manages
that
whole
thing
itself
now.
This
is
more
like.
I
think
the
question
for
monorail
is:
can
we
actually
mandate
that
the
the
sdk
has
to
line
up
with
the
api
version
at
runtime
and
that
obviously
needs
to
support
older
api
versions
that
are
installed
in
libraries,
but
can
it
be?
Can
it
be
something
that
we
can
mandate
in
order
to
achieve
the
abi
compatibility
guarantees.
D
This
is
one
thing
that
we
did
in
open
sensors
for
java,
where
we
had
a
separation
between
api
and
sdk.
We
also
we
encourage
people
to
to
have
the
latest
sdk
or
the
newest
sdk
possible
and
enforce
that
they
also
take
a
dependency,
a
specific
dependency
on
the
api
in
their
thing,
because
by
default,
the
building
tools
results
that
the
the
the
top
one
is
using.
So
yes,
we
we
do
that,
and
I
think
it's
a
reasonable
thing.
D
E
Expectation
is
that
in
most
languages
it
would
work
like
this.
You
have
to
presume
the
sdk
is
relying
on
something
that
was
in
the
latest
version
of
the
api,
and
if
people
are
relying
on
prior
versions
of
the
api,
that's
why
those
have
to
work
with
the
latest
one
people
and
one
of
the
design
goals.
We're
trying
to
get
into
here
is
the
idea
that
if
we
can
set
this
up
properly
so
that
we
can
help
ensure
smooth
updates
of
the
sdk,
then
we
can.
E
H
E
H
The
other
thing
that
this
highlighted
was
honorable,
I
think
rightly,
is
saying
that
people
are
going
to
depend
on
the
sdk
some
sdk
classes
as
a
transitive
dependency
like
if
they
are
building
their
own
spam
processors
and
shipping,
that
in
as
a
part
of
some
library
or
other,
and
that
we
may
we
may
need
to
be
also
requiring
abi
compatibility
for
some
set
of
the
the
sdk
interfaces
and
what
the
real
question
is.
E
Yeah
so
yeah,
I
would
agree
with
you
to
sum
up,
for
other
people,
we've
clearly
separated
out
the
api
from
the
sdk
so
that
we
can
clearly
see
what
interfaces
need
to
have
this
kind
of
strong
compatibility
for
instrumentation
packages.
We
didn't
do
that
for
the
sdk
and
the
question
is,
it
seems
to
me
we
at
minimum
at
least
need
to
identify
within
the
sdk
what
we
consider
to
be
a
public
interface
that
should
remain
stable.
E
We
haven't
done
that,
but
we
should
at
least
mark
that
out
in
the
spec.
I
think
the
next
question
is
for
different
languages.
Does
it
make
sense
to
pull
those
things
out
into
their
own
package?
E
We
were
doing
that
for
instrumentation
in
order
to
avoid
a
dependency
chain
right
people
who
depend
on
the
instrumentation.
We
don't
want
them
to
end
up
with
a
transitive
dependency
on
some
sdk
package,
because
that
was
that
would
have
created
transitive
dependency
conflicts.
We
want
to
avoid,
but
it
seems
like
that's,
not
an
issue
with
people
who
are
just
writing
spam
processors
and
stuff
against
the
sdk.
D
No,
I
think
I
think
it
will
complicate
a
lot
if
we
extract
the
apis
out
of
that
artifact,
but
identifying
and
and
marking
them
is,
is
reasonable.
D
What
I'm?
What
I'm
saying
is,
I
don't
think
we
need
yet
another
artifact,
but
I
think
we
can
clearly
state
that
these
are
and
and
by
doing
that,
we
we
can
simply
do
by
by
by
controlling
whatever
is
public
and
what
is
not
public.
I
think
we
should
be
very
aggressive
in
languages
like
java
to
not
make
anything
public
that
does
not
need
to
be.
H
H
I
think
we're
really
going
to
be
limiting
the
the
kinds
of
things
that
we
can
do
with
our
with
the
sdk
yeah.
That's
my
bigger
that's!
My
bigger
concern
is
that
I
don't.
I
don't
feel
like
those
interfaces
are
mature
enough
right
now
to
want
to
publish
and
say
we're
going
to
support
them
forever
and
if
we're
required
to
I'm
kind
of
in
a
tough
spot.
E
So
to
to
jump
in
here,
I
I
totally
agree
and
just
to
back
up
a
bit.
My
experience
with
frameworks
in
general
is
that
those
internal
apis,
those
lifecycle,
apis
and
plug-in
apis.
Those
tend
to
to
version
far
more
frequently
in
frameworks
than
the
public
api.
For
this
very
reason
it
for
whatever
reason
like
more
and
more
as
the
sdk
evolves,
you
want
more
and
more
features.
More
ways
to
plug
in
people
realize
the
options
that
they
have
work
or
don't
work.
E
If
you
try
to
give
every
form
of
flexibility
to
everyone,
then
you
lose
efficiency
generally.
So
there's
like
way
more
trade-offs
that
have
to
get
made
when
you're
thinking
about
all
of
that
internal
stuff,
and
I
think
we
should
reserve
the
right
to.
I
don't
think
we
should
break
that
stuff
unnecessarily,
but
we
should
definitely
be
making
new
versions
of
these
things
and
we
may
have
to
aggressively
retire
old
interfaces
in
order
to
to
avoid
losing
efficiency.
E
That's
just
something
I
predict
if
we
try
to
keep
all
the
old
exporter
interfaces
and
old
spam
processors
and
then
add
new,
better
ones
that
that
will
box
us
in
pretty
quick.
E
E
We
can
mitigate
that
by
maintaining
as
many
of
the
core
plug-ins
that
we
think
are
necessary,
but
as
the
an
ecosystem
grows,
that's
just
gonna
be
an
issue
most
frameworks
just
say
like
that's
life,
though
that's
that's.
How
most
frameworks
deal
with
this
problem
and
they
just
try
to
encourage
plug-in
authors
to
stay
up
to
date.
E
My
assumption
was,
we
would
probably
go
with
a
model
like
that,
since
that's
what
frameworks
end
up
kind
of
having
to
do.
I
Yeah
one
of
the
things
that's
in
this
rfc
that
kind
of
worries
me
is
the
idea
that
a
breaking
change
to
the
sdk
could
be
a
minor
version
bump
and
that's
not
going
to
work
for
go
at
the
very
least
because
the
the
package
management
system
depends
on
semver
having
meaning
beyond
1.0.
I
So
we're
not
going
to
be
able
to
adhere
to
that,
and
I
think
we
should
keep
that
flexibility
to
have
the
sdk
outpace.
The
apis.
E
Yeah,
if,
if
that
becomes
a
requirement,
just
to
be
clear,
I'm
for
it,
I've
been
trying
to
encourage
us
to
stick
to
as
few
floating
version
numbers
as
possible,
but
it
does
seem
like
the
sdk
will,
has
the
potential
to
make
breaking
changes
much
faster
than
the
api.
So
maybe
we
just
need
to
give
up
the
ghost
on
keeping
those
versions
in
sync
with
each
other.
E
It'll
make
certain
things
harder
to
communicate
like
what
you
were
asking
for
talking
about
before
john
around
requiring
people
stay
up
to
date
with
the
latest
version
of
the
api.
But
maybe
that's
that's
just
something
that
that
people
will
have
to
to
know
what
the
latest
version
of
the
api
is,
that
their
version
of
the
sdk
works
with.
J
E
We
shouldn't
break
things
unnecessarily
in
the
sdk.
I
really
wanna
sit
here
towards
deprecating
old
interfaces,
but
keeping
them
around
rather
than
just
changing
and
breaking
interfaces.
E
So
if
this
seems
reasonable,
I
could
try
to
to
bake
some
of
this
into
this
versioning
document
and
say
api
and
sdks
conversion
separately
from
each
other.
E
D
Not
to
let's
put
this
way,
let's,
let's,
let's
understand
better,
what
are
the
the
problems,
and
maybe
maybe
john
one
thing
that
I
would
like
to
to
do
is
let
us
know
what
were
the
the
complaints
about
the
the
framework
that
we
have
and
maybe
try
to
fix
that
to
avoid
imminent
breaking
so
because,
based
on
your
comment,
it
seems
that
there
is
a
imminent
breaking
change
coming
very
soon.
Can
we
fix
that
earlier.
H
Yeah
nikita
and
I
chad
have
been
chatting
about
this
quite
a
bit,
and
I've
heard
it
from
some
other
people
too.
Just
that
we
want
to
be
able
people
really
want
to
be
able
to
chain
spam
processors
in
a
consistent
and
configurable
way
and
the
current
apis.
Let
you
do
it,
maybe
implicitly,
but
it's
kind
of
you
kind
of
hack
it
together
via
config,
rather
than
having
it,
be
something
that's
baked
in
anyway.
E
Okay,
I
don't.
I
don't
want
to
take
up
this
entire
meeting
with
this
discussion,
even
though
I
really
want
to
stress
it's
important.
It
sounds
like
figuring
out.
Sdk
versioning
is
is
like
the
core
trick.
I
would
still
like
to
see
maintainers
produce
their
version
of
this
document,
because
I
think
that's
a
good
exercise
to
get
your
head
wrapped
around
it,
so
we
can
have
more
involvement
before
we
sign
off
on
this
thing,
but
but
that's
really
helpful
feedback.
E
It
sounds
like
where
we're
landing
is
we're
not
going
to
try
yet
to
create
specific
sdk
packages
that
are
interface
only
and
separate,
but
we
do
need
to
demarcate
what
is
a
public
api
and
figure
out
a
way
to
to
handle
sdk
breakages
that
are
different
from
api
breakages?
Is
that
does
that
seem
reasonable?
John.
E
Great
yeah
any
other
comments
or
questions
on
this
versioning
subject
before
we
move.
E
On
okay,
well,
I
appreciate
you
all
in
advance
for
for
pulling
hard
on
this
one
and
making
it
happen
this
week
so
appreciate
it.
Okay,
moving
on
with
the
meeting
agenda
andrew,
you
want
to
go
over
the
the
spec
backlog.
K
This
should
be
the
one
all
right,
so
I've
got
some
staining
agenda
items,
we've
got
triage
I'll,
go
over
status
as
well,
and
then
we
also
have
some
time
box
for
metrics
issues.
If
we
want
to
talk
about
any
of
them,
I
see
that
there
are
some
issues
that
need
to
be
triaged
from
the
spec
repo,
not
a
huge
amount,
but
we
it's
like
about
five
or
six.
K
L
I
I
found
it,
but
you
could
have
said
this
to
me.
I've
been
trying
to
list
out
issues
that
haven't
been
tightly
resolved
for
metrics
in
general
and
may
come
up
with
more
of
these
okay.
L
H
L
H
G
F
I
feel
this
is
required,
allow
for
gl.
Yes,.
J
Yeah
this
needs
to
be
better
addressed
because
you
know
we're
running
into
these
issues
with
javascript,
specifically
and
there's
another
issue
which
is
related,
which
is
open,
but
it
is
again
clearly
defining
you
know
what
number
handles,
especially
for
error,
values
and
error
codes.
A
L
K
L
L
Sorry
this
is
the
same
roughly
the
same
topic
as
we
just
saw
a
minute
ago.
You
can
sign
this
to
me.
It
is
a
protocol
issue,
I
think,
but
it's
it's
also
semantic
convention
right
and
it's
definitely
not
required.
L
J
M
M
This
one
is
essentially
about
an
edge
case
for
browsers
that
might
have
a
clock,
not
synchronized,
so
the
idea
is
to
add
a
property
that
would
describe
the
time
stamp
when
the
package
was
exported
to
somehow
leave
the
possibility
of
adjusting
the
the
time
for
the
back
end.
There
was
some
discussion
with
christian
if
this
should
be
an
attribute,
or
maybe
extension
to
the
protocol.
D
How
would
you
resolve
the
export
timestamp
without
having
other
information
such
as
received
time,
because,
yes
likely,
you
need
a
receive
time
and
an
export
time
and
try
to
correlate
there?
Something
and
precisely
so,
and
I
also
don't
think
this
is
a
resource
information,
it's
more
an
extension
to
the
protocol.
If
any.
L
L
Yeah,
it's
a
it's
it's
kind
of
a
protocol
issue
as
well.
I
think
you
end
up
needing
an
extra
field
to
do
something
here.
K
K
Okay,
I
think
we
are
set
on
that
for
the
specs,
I'm
just
double
checking
the
assignees
of
p1
great
all
the
p1s
are
assigned,
which
is
what
we
need
for
the
highest
priority
of
issues.
J
J
And
this
really
is
to
ask
for
you
know
and
convention,
for
supporting
non-core
components
which
can
enable
first
of
all
growth
in
the
pool
of
maintainers
and
also
specialized
areas
such
as
building
out
the
prometheus
and
ensuring
the
prometheus
components
are
maintained
to
be
considered
to
be
put
into
contribute
or
or
any
other
repo
again.
That
was
an
example.
H
I
feel
like,
given
the
versioning,
you
know
discussion
about
things
like
I
mean
sdk
components,
and
this
we
need
to
have
an
answer
to
this,
about
whether
we're
going
to
be
releasing
exporters,
propagators,
etc
under
the
same
versioning
and
release
requirements
that
the
rest
of
the
sdk
is
going
with.
So
I
think
this
is
actually
really
important
to
get
done
before
we
before
we
do
ga.
J
Yeah,
and
and
and
also
you
know,
given
I
mean
we've
had
discussions
with
bogdan
with
josh
with
others
on
the
you
know,
improving
the
prometheus
components,
especially
the
receivers
and
and
and
the
exporters
both
push
and
pull
we'd
like
to
see
it
being
stable,
being
available
being
in
an
area
which
can
be
maintained
and
consistent,
obviously
with
the
spec
and
protocol.
So
we
need
to
figure
out
how
to
decouple
these
components.
E
Yeah,
just
to
chime
in
here
I
think
stuff
just
to
clarify,
I
think
things
that
live
and
contrib
don't
have
to
follow
the
same
versioning
as
the
stuff
that
lives
in
core
looks
like
we
might
not
even
be
able
to
have.
The
api
at
sdk
have
the
same
version,
but
definitely
anything
I
can
trim.
I
think
all
of
those
packages
should
version
independently
of
each
other.
E
H
J
I
mean
john,
we
were
looking
at
again.
These
are
specialized
communities
also
and
and
to
actually
get
more
deeper
involvement
from
other
engineers
and
groups,
but
it
has
the
same
qualifications
right
if
you
were
to
look
at
your
jaeger
or
if
you
were
to
look
at
other
components
that
that
have
to
be
at
least
according
to
our
mandate
should
be
fully
interoperable.
J
H
E
Yeah,
I
I
think
we
should
certainly
be
shipping
a
set
of
core
propagators,
w3c
and
b3
minimal.
H
So
why
is
b3
different
than
jaeger?
Why
is
like?
Why
is
why
are
we
elevating
b3
above
some
other
propagator
format
like
I
understand,
there'll,
be
a
little
bit
as
being
you
know,
something
that
we're
closely
aligned
to,
but
I'm
just
trying
to
understand
how
we're
how
the
lines
are
being
drawn.
Then.
J
E
V3
is
just
a
de
facto
standard.
That's
that's!
Why
I'm
bringing
it
up!
We
see
far
far
far
more
b3
out
there
in
production
than
just
about
any
other
context.
Propagation
header
today,
including
w3c
headers,
so.
L
I'm
asking
because
like
say
in
go
we
have
that
prometheus
exporter
the
pull
based
exporter,
but
it's
its
own
module
file.
So
if
you
don't
use
it,
it
won't
actually
get
linked
into
your
code,
but
it's
still
part
of
the
official
repo
and
it
would
be
nice
if
and
if
I
mean
that
that'll
create
limits
on
growth
for
us
like
we
don't
have
a
way
to
like
just
dynamically
choose
your
exporter,
because
you'll
have
to
link
them
all
in
and
that's
a
different
problem.
L
N
E
Yeah,
I
I
just
have
one
more
comment
before
we
go
on
to
address
what
josh
says,
because
I
think
it's
relevant
for
people
looking
at
this.
I
think
a
lot
of
this
is
less
about
binary
size
and
more
about
the
ability
to
push
and
review
pull
requests
right,
everything's
in
cores,
and
that
means
the
core
maintainers
have
to
be
in
charge
of
that.
E
So,
if
we,
I
think
part
of
this
request
is
figuring
out
a
way
for
people
like
if
there's
a
prometheus
community
that
wants
to
own
the
prometheus
exporters,
how
how
can
they
be
in
charge
of
that
in
a
way
that
doesn't
require
everyone
to
be
a
maintainer?
B
D
I
don't
think
the
location
is
a
problem.
I
think
it's
a
matter
of
who
is
owning
his
community
like,
or
is
the
maintainers
of
core
and
open
telemetry
stamps
on
it?
So
in
terms
of
prometheus
exporter,
should
this
be
something
because
when,
when
somebody
sees
that
this
is
a
complete
project,
they
will
probably
not
feel
as
comfortable
as
they
see.
This
is
a
core
project,
so.
E
Right
so
yeah
we
we
should
make
people
feel
confident
in
our
contrib
stuff,
like
our
contrib
stuff,
I
consider
part
of
poor
in
the
sense
of
like
open
telemetry
doesn't
function
unless
that
stuff
is
really
good
right,
like
it
doesn't
matter.
If
you
have
a
great
sdk,
if
all
the
plugins
suck
so
they're
critical,
we
should
make
sure
people
feel
like
the
stuff.
That's
coming
from
open,
telemetry
can
trip.
Maybe
we
can
rename
it
are
things
we're
committed
to
maintaining
it's
just
a
question
of
like
who's.
E
E
E
K
K
D
I
think
this
is
the
george,
should
this
be
closed,
based
on
your.
L
D
Okay,
I
will
take
care
of
these
very
close.
L
This
this
actually
came
up
in
relation
to
some
other
stuff
about
aggregation,
temporality,
which
I
don't
want
to
talk
about
here.
We'll
talk
on
thursday,
I
think,
like
some
nuances,
have
come
out
of
light
steps.
Analysis.
H
K
Just
a
few
more
quick
things
in
order
to
clean
up
josh,
I
noticed
this
was
moved
from
allowed
from
required
to
ga
to
allow
to
ga.
Does
that
mean
a
bump
low
on
priority
p1
to
p2?
Would
that
be
suitable.
L
K
All
right,
lovely!
Thank
you
very
much.
We
have
completed
triage
current
status
at
the
beginning
this
morning
to
do
for
the
p1
across
spec
proto
oteps.
We
have
19
issues
that
were
in
to
do
it's
increased
three
from
last
week.
16
are
spec
related,
which
is
why
we
have
a
time
box
for
metrics
topics.
If
we
need
to
discuss
any
of
them
in
progress,
we
got
five.
That
means
the
lynx
pr
and
53
done
no
movement
from
last
week.
K
I
just
want
to
make
one
last
point,
for
we
also
have
a
separate
issue
triage
meeting
on
fridays.
It's
a
half
hour
at
8
30
a.m.
Pacific
time
I
need
at
least
one
member
from
tc
to
show
up
in
order
to
be
able
to
make
progress
on
that,
although
it's
not
a
huge
amount,
I'm
happy
to
cancel
if
we
don't
have
any
and
we
want
to
have
it,
but
that
just
gives
us
two
instances
of
triage
per
week.
So
that
way
we
can
make
sure
we
keep
on
top
of
things.
D
J
K
D
J
D
Answer
the
specs,
I
think,
by
the
way,
pr.
The
next
item
can
you
still
present
andrew
for
a
second
sure
the
pr
is
blocking
for
aws
devs.
I
usually
encourage
whoever
wrote
this
to
to
join
the
sigs
for
the
goal
or
for
python
and
put
them
there
instead
of
in
the
specs
but
yeah
I
don't
know
what
should
we
recommend
just
if
there
is
any
gold
maintainer
approval,
please
review
them
and
python
as
well.
So.
O
Yeah,
I
want
to
recommend
here
either
I
later,
because
the
go
issues
were
brought
up
in
the
last
cig,
and
I
gave
a
recommendation
that
we're
actively
working
towards
it.
I
can't
make
any
further
speed
other
than
what
the
community
is
able
to
do
so
getting
re-pinged
on
this
multiple
times
is
not
really
helpful.
J
Yeah,
I
think
I
think
again,
yeah
tyler,
appreciate
it
and
and
bogdan
just
your
answer
to
your
question.
All
our
engineers
are
covering
or
in
the
six
they
do
participate.
It's
just
that
I
think.
Sometimes
what
is
happening
is
that
they're
ending
up
you
know
waiting
at
least
two
or
three
weeks.
So
just
having
an
understanding
of
when
to
expect
reviews
is,
would
be
helpful.
D
J
The
other
thing
that
again
is
worth
bringing
up
and
again
this
highlights
to
the
larger
point
I
was
making
earlier
in
the
otep
that
I
filed
is
just
maintainers
right
number
of
maintainers
being
available,
because
python,
for
example,
only
has
two
maintainers
c
plus
plus
only
has
literally
one
rally
is
on
break
right
now,
so
it
does
stretch,
the
maintainer
is
very
thin.
Sometimes.
J
D
But
I
think
I
think
there
is
a
misunderstanding
of
maintainers
versus
approvers.
I
I
encourage
the
provers
to
review
as
well.
The
maintainers
will
just
press
a
button.
D
If
that's
the
key
so
yep
everyone
in
the
community
review
and,
for
example,
in
the
collector
world,
we
have
like
seven
or
eight
approvals,
but
not
all
of
them
are
active.
That's
that's
separate
issue
and
stuff,
so
I
don't
think
we
should
just
blame.
The
number
of
maintainers
maintainers
are
a
bit
different
than
they
have
just
the
power
of
pressing
one
extra
button,
but
in
general
the
approvals
should
should
review
the
the
things
as
well.
E
Yeah
that
that's
also
a
great
way
for
people
to
advance
yeah.
H
E
To
do
a
shout
out
on
this
topic,
I
want
to
take
too
much
time
on
it,
but
maintainers
as
end
of
year.
Please
review
your
roles
and
if
there
are
people
who
could
be
have
been
contributing,
who
could
be
made,
triagers,
approvers,
etc?
Now
is
a
good
time
to
do
it
so
I'll
ping,
I'll
ping,
other
people
about
that.
But
I
think
that's
that's
an
issue
that
we
should
have
a
look
at
is
just
expanding.
The
number
of
people
involved.
G
D
G
A
A
If
the
vendor
chooses
so
discovering
more
valuable
information
in
the
service
maps
or
runtime
application
architectures
or
correlating
certain
upgrades
of
such
such
engines,
with
with
availability
or
performance
issues,
and
I'm
here
with
a
specific
topic,
because
I
kind
of
kind
of
new
to
the
to
the
open
telemetry
world
and
trying
to
figure
out
whether
at
the
current
shape,
it's
even
possible
to
change
semantic
conventions.
D
D
Okay,
thanks
you
all
so
as
an
action
item.
Everyone
if
you
are
interested,
read
the
document
that
evo
proposed
and
let's
have
a
chat
about
this
and,
as
I
said
evo,
you
should
make
a
pr
because
that
will
get
the
attention
of
everyone.
E
I
did
look
over
your
dock
and
I
think
it
looks
fine.
Just
fyi
there
shouldn't
be
a
problem
getting
this
approved,
but
it
does
raise
a
question.
We
don't
have
like
a
working
group,
thinking
forwardly
too
much
about
the
semantic
conventions
and
so
like
the
quibbles
I
have
with
the
document
that
you
produce
have
almost
nothing
to
do
with
it,
but
more
questions
like
you
know,
do
we
want
to
name
space
language,
specific
things
and
stuff
like
that?
E
E
No,
never
never
breaking
changes
in
my
opinion,
but
we
can
look
at
organizing
what
we
have
better
and
we
can
look
at
ensuring
that
things
we
add
in
the
future
follow
something
that's
more
like
a
a
more
regularized
theme
and
if
we
do
ever
want
to
go
back
and
regularize
our
existing
conventions,
then
I
see
that
as
as
additive
change.
Certainly
for
the
time
being,
so
things
would
just
report
old
conventions
and
new
conventions
with
the
option
to
turn
it
off.
That's
my
shoot
from
the
hip
way.
D
Okay,
andrew
last
topic.
K
Just
want
to
throw
one
friendly
reminder:
the
holidays
coming
up
at
the
end
of
december.
This
we're
what
december
8th
next
week
is.
We,
of
course,
have
the
open
telemetry
expect
meeting,
but
the
week
after
is
christmas
week,
the
week
after
that
is
new
year's
week.
So.
K
This
community
across
many
different
cultures,
many
different
time
zones,
many
different
countries,
so
I
don't
know,
there's
an
open
question
of
whether
we
should
do
that,
but
I
do
foresee
there
will
be
reduced
activity
across
the
board,
so
a
lot
of
us
will
be
celebrating
or
vacationing
or
something.
E
F
Yeah,
I
just
wanted
to
ask
like
people
who
are
in
asia,
for
example,
that
they
may
not
be
taking
holidays.
I
don't
know
what's
their
opinion
of
this,
because
I
could
feel
great
if
I
know
that
we
are
taking
a
holiday
and
I
mean
people
can
still
meet
right
if
they
want.
But
I
don't
know.
J
K
E
B
E
The
the
time
that
I
suspect,
almost
no
maintainers
will
be
around
is
for
that
29th.
B
J
K
That
be
noted
on
the
agenda
removed
from
the
calendar,
I'm
not
trying
to
push
it
one
way
or
the
other,
I'm
just
trying
to
highlight
it.
So
that
way
we
are.