►
From YouTube: 2022-05-26 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
A
A
B
A
So
yeah
so
previous
jack
we've
discussed
this
previously
a
long
while
back
and
I
think
at
the
time
the
thought
was
that
stale
prs
make
sense,
but
stale
issues,
maybe
not.
C
The
rules
that
are
set
up
on
this
issue
they're
pretty
they
kind
of
reflect
that
in
a
way,
I
think
the
they
say
that
you
know
an
issue
isn't
stale.
Unless
it's
you
know
730
days
so
two
years.
A
Yeah,
I
think
the
I
find
the
spec
one
a
little
bit
aggressive
the
pr
scale
just.
B
B
A
C
B
D
B
I
don't
know,
like
I
think
rate
when
I
see
issues
go
stale
and
then
they
don't
get
unstable.
Unless
someone
manually
removes
the
label,
that's
been,
how
I
see
things
happening,
is
it
just
getting?
Unstale
is
not
automatic,
but
the
counter
would
be
reset.
I
don't
know,
but
I
notice
people
like
there
should
never
be
a
need
to
remove
this.
A
label
like
a
reviewer
should
be
like
sorry,
I
was
late
or
something,
and
that
should
also
remove
the
state
label
automatically.
D
A
A
C
B
A
C
C
B
C
B
B
C
B
B
B
B
C
C
Okay,
we
could
do
it
at
anytime,
there's
like
a
merge
domain
or
that's
true.
Yeah.
C
Ideally,
we
don't
get
a
good
still.
That's
true
years
later,
when
all
the
maintainers
are
gone,
two
years
is
gonna
pass
and
and
all
the
issues
are
gonna
go
stale
and
nobody's
gonna
be
listening,
and
then
all
the
issues
are
gonna
get
deleted
or
get
close.
A
A
We
agree
on
the
pr
still
in
pr
close.
Let's
talk
issue
issues,
I'm
not
I
mean
I'm
not
entirely
opposed
to
doing
something.
Like
a
you
know,
many
year
thing,
let's
see
what
we've
got
in
our
repo
we've
definitely
got.
C
It's
here's
the
thought-
and
so
I'm
not
tied
to
this
still
issues
thing,
but
if
an
issue
hasn't
had
any
activity
for
two
years
and
it
becomes
marked
as
stale,
then
that
kind
of
bumps
it
to
the
head
of
our
notifications
queue
and
we
all
of
a
sudden
can
can
be
prompted
to
look
at
it
again
and
I
think
if
we
remove
the
stale
flag-
and
we
say
hey,
this
is
still
legit.
C
That
won't
happen
again
for
two
years
three
years,
so
it
doesn't
seem
kind
of
too
invasive.
You
know.
A
So
how
about
two
years
and
then
another
year
before
closing,
auto
closing
like
if
people,
because
my
feeling
on
issues
right
is,
if
we're
not
gonna,
do
it
like?
We
should
just
close
it
and
say
we're
not
gonna.
Do
it.
A
B
Because
I
don't
know
how
some
other
vehicles
have
it
configured,
but
I
got
in
sometimes,
for
example,
I
might
be
following
some
kubernetes
issue
for
some
reason,
and
so
like
there
are
these
projects,
where
I
didn't
see
like
every
couple
of
weeks
like
it
takes
a
long
time
to
get
there,
then
for
some
reason,
every
couple
of
weeks
they
get
stale
and
unstable
and
like
then,
this
starts
at
some
point.
So
perhaps
they
have
it
said
differently,
so
that
the
first
scale
is
a
long
time
and
then,
after
that,
it's
a
shorter
time.
B
I
don't
know
if
that's
a
possible
setting,
but
I've
seen
this
happen
so
that
we
definitely
wouldn't
want
to
do.
I
think
if
it's
every
three
years
it
gets
stale
new
market
installed,
and
that
seems
okay,
but
I
wouldn't
want
to
get
into
like.
Sometimes
I
see
these
issues
where
once
it's
stale,
it's
becomes
a
unstable
notification.
Every
couple
weeks
for
me.
C
Yeah,
I
I
don't
mind
these
settings
that
you
have
here
trask.
You
know
we
get
stale
issues
when
they
become
stale
they
bump
to
the
top
of
our
notifications
queue.
We
can
take
a
look.
If
we
forget
about
them,
we
can
quickly
filter
for
all
issues
that
have
been
marked
stale
on
some
sort
of.
I
don't
know
quarterly
cadence
or
something
like
that
and
and
triage
them
and
close
them,
if
appropriate
or
mark
them,
as
unstale.
B
A
A
Yeah
I
mean
I
also
feel
this
like
in
the
especially
in
the
instrumentation
repo.
We
get
a
lot
of
sort
of
questions
and
you
know
I
don't
I
tried
to
respond
to
most
of
them.
You
know,
I
think
the
across
the
maintainers.
D
A
B
Speaking
of
questions,
especially
yeah,
I
don't
think
sdk
reproduced
them
that
much,
but
the
most
important
in
this
case
for
stale
issues
would
be
after
the
question
is
answered
and
they
don't
come
back
to
respond,
which
is
pretty
common,
and
so
one
possible
thing
is
that
we
have
a
label,
that's
like
answered,
and
then
the
scalebot
comes
in
after
a
couple
weeks.
To
close
the
issue,
I
mean
that's
how
many
ticketing
triage
queues,
work
at
companies
and
stuff
also,
I
think
that's.
A
That's
what
I
do
in
our
repo,
but
microsoft
has
a
nice
spot
that
helps
me
but
yeah.
So
I.
A
But
yeah
like
I'll
mark
something,
as
you
know,
waiting
for
needs,
author
feedback,
yeah
and
then
it'll,
auto,
close
it'll,
it'll,
prompt
them
after
seven
days
and
then
close
it
after
another.
Seven
days.
C
I
bet
we
can
do
that
with
this.
This
stale
bot,
we
might
have
to
manually,
apply
those
labels
that
you
know
needs
author
feedback,
but
I
bet
you
can
look
for
the
presence
of
that
and
then
yeah
close
it
after
some
period
of
time
after
yeah,
the
intent
would
be
to.
B
A
Yeah
I've
kind
of
been
doing
this
manually
in
the
instrumentation
repo,
where,
like
from
time
to
time
when
I
do
a
triage
I'll
just
check.
If
you
know,
if
nobody
has
replied,
the
author
hasn't
replied
after
a
while
I'll
close
it.
B
Oh
I
think
I
mean
we
could
have
multiple
workflows
with
different
scale
configurations
I
think,
but
if
we
only
had
one,
then
it's
probably
would
be
set
to
it,
wouldn't
close
on
like
after
three
years
of
no
activity.
Instead,
it
would
be
set
to
this
label
where
never
closed.
After
two
weeks
of
this
label
being
set.
That's
probably
the
only
thing
you
can
do
in
one
workflow.
Of
course
you
can
multiple
workflows
if
you
wanted
to
go,
but
I
wouldn't
be
satisfied
with
that
anyways
without
the
future.
A
A
We
talked
a
lot
about
logging
and
events.
Apis
jack
walked
us
through
the
two
prototypes
and
at
least
myself
and
jason
plum
voted
for
option
number
two
of
the
more
separate
apis.
C
John
watson
did
as
well
and
via
slack
that
he
originally
was.
You
know
I
I
made
prototype
number
one,
which
has
like
a
combined
api
for
log
of
penders
and
for
emitting
events,
and
you
know
john
chimed
in
and
said
I
would
keep
those
separate,
and
so
that's
what
prompted
the
second
prototype.
A
B
A
B
D
A
B
A
B
A
C
B
C
C
One
of
the
things
that
slo4j
has
to
provide
is
bridging
to
you
know
for
between
the
api
and
the
frameworks
where
you
can
figure
what
happens
with
those
logs.
So
if
we
were
to
start
using
our
own
api,
the
log
appender
api
internally
we'd
want
to
ensure
that
users
could
bridge
that
out
to
their
the
framework
of
their
choice.
They
could
do
standard
things
with
those.
B
A
A
couple
of
other
features,
I
think
that
would
differentiate
or
we
would
need
one
is
a
up
like
right
now.
It's
I
think
it's
construct
like
memory
like
like
you,
would
want
to
have
a
severity,
a
shortcut
on
severity.
If
your
logging
level
didn't
meet
like
for
debug
messages
and
the
other
would
be
the
templating,
you
know
what
would.
D
C
If
we
I
mean,
if
we
bridge
out
from
our
api
to
other
log
frameworks,
then
I
think
a
lot
of
those
questions
go
away.
So
we
don't
have
to
come
up
with
a
like
a
configuration
template,
because
you
know
you
we
just
say
hey.
If
you
want
to
use
this,
then
you
know
use
this
bridge
for
log4j2
and
then
use
log4j2's
configuration
and
everything
that
comes
with
that.
C
Oh
you're,
talking
about
the
message
templating,
I
see
with
the
placeholders
the
curly
braces
placeholders.
B
B
C
B
A
That
will
be
a
yeah,
a
good
barometer
of
whether
people
are
using
using
it
with
by
itself.
B
If
someone
follows
an
issue,
but
I
have
a
feeling,
no
one
will
ever
file
an
issue
with
that,
but
you
never
know
more
likely.
Is
these
random
chinese
login
frameworks?
I
think
we
or
jboss
logging
framework
or
something
like
that-
I'm
sure
there'll
be
other
wording
frameworks
we're
not
that
familiar
with
that
exist.
I
don't
keep
all
my
issues
about
that.
C
A
Yeah
and
then
some
open
tracing
the
micro
profile,
folks,
emily
joined
and
so
they're
trying
to
because
they're
migrating
from
micro
profiles
migrating
from
open
tracing
to
open,
telemetry,
so
they're
trying
to
figure
out
interop
stories
and
how
customers
can
upgrade
some
microservices,
but
not
others
and
still
not
break
distributed
tracing.
So
luckily,
jack
found
the
ot
trace
propagation
format
that
is
designed
for
that.
A
Yeah
it'll
be
interesting
if
yeah,
because
that's
I
kind
of
asked
that
of
what
propagation
format
they
were
using
and
she
was
convinced
it
was
just
like
the
open
tracing
format.
B
D
B
B
For
instrumentation,
I
was
wondering
whether
there's
thoughts
on
releasing
library
instrumentation
stable
sooner
than
later,
because
I
can't
think
of
any
reason
we
would
release
a
javascript
table
with
changing
telemetry,
but
not
do
the
same
for
library
instrumentation.
It
seems
to
be
the
same
thing.
A
B
A
Wanted
to
keep
a
low
profile,
no,
the
the
telemetry
stability.
B
A
B
A
A
It
doesn't
have
telemetry
stability,
but
yeah,
so
I
guess
we
sort
of
say
that
none
of
the
instrumentations
inside
of
the
java
agent
are
stable.
B
A
A
But
I
think
they
made
it,
or
at
least
in
that
discussion
we
made
a
distinction
between
distros
that
contain
multiple
instrumentations
and
single
instrumentations,
where
a
distro
of
multiple
instrumentations
can
the
distro
itself
can
be
marked
stable.
But
you
document
which
instrumentations
within
it
are
stable
or
not
stable,.
A
It
is,
we
are
at
least,
I
think,
we're
getting
close
on
our
side
of
the
instrumentation
api,
although
I
guess
we're
at
no.
No,
we
do
expose
like
the
attribute
extractor
stuff,
so
yeah
that
needs
to
be
stable.
A
What
what
libraries
would
you
prioritize.
A
What
libraries
do
you
feel
like
are
painful
that
we
don't
have
stable.
A
I
was
afraid
you
would
pick
things
other
than
http.
I
mean
okay,
but
that's.
B
All
yeah,
I
mean,
of
course
you
know
so
in
that
sense.
Of
course,
spring
is
the
most
important,
but
I
just
know
that
we
are
much
farther
on
releasing
the
spring
this
table
versus
any
of
the
other
ones,
but
just
because
we
haven't,
like
we've,
never
invested
because
of
the
whole
suit
who's
supposed
to
own.
It
type
of
thing,
but
otherwise
spring
is
of
course
the
most
important,
but
I
don't
feel
it
realistic.
We've
had.
A
B
Yeah
somehow
I
got
into
the
maybe
now
that
I'm
out
of
it,
maybe
I
can
see
it
from
a
further
perspective
because
it
sort
of
felt
nice
that
http
might
be
stable
soon,
but
really
http
isn't
like
jdbc
is
required,
like
http,
only
isn't
satisfying
any
use
case
really
in
practice
like
http
plus
jdbc.
Maybe
then,
finally,
your
satisfying
use
case
at
that
point.
So
that's
going
to
be
year
down
the
line,
the
hotel's
still
sort
of
useless
for
a
year.
That
is
quite
problematic.
B
A
We
are
close
to
that.
Finally,
after
I
mean
that's
been
a
slog
on
our
just
on
in
itself
of.
B
D
A
B
A
I
mean
honestly,
we
could
even
potentially
publish
it
as
release
an
rc
like
just
say:
hey
we're
in
sort
of
perennial
rc
state
until
semantic
conventions
are
stable.
I
don't
know
if
that
smells.
My
oat
deal
is
a
joke.
D
A
A
A
C
Getting
people
to
you
know,
motivated
to
you,
know,
work
on
on
a
particular
area
of
focus
and
just
get
something
done
in
that
area.
There's
you
know,
there's
not
like
clear
focus.
You
know
month
over
month
what
what
what
open
telemetry
is
working
on
broadly
and
where
people
should
spend
their
times,
and
so
everything
just
kind
of
proceeds
forward
a
bit
it
seems
like
accidentally
or
haphazardly.
A
C
How
do
you
get?
How
do
you
say
something
like
this?
We
want
to
probably
we
want
to
stabilize
the
jdbc
semantic
conventions
by
september.
We
need
everybody
who
is
interested
in
in
doing
that,
to
you
know,
get
together
and
give
their
feedback
between
now
and
then
or
else
you
know,
you're
going
to
miss
your
window.
A
Have
you
been
following
johannes's
attempt
to
do
that
for
messaging
and
dennis's
attempt
to
do
that
for
http?
Admittedly,
now
I've
been
okay,
I've
been
in
metrics.
C
A
Yeah,
so
people
have
tried
that,
and
there
was
an
instrumentation
sig
formed
to
drive
that
process
and
that
group
met
regularly
and
put
up
various
oteps
and
plans
and
stakes
in
the
ground
of
we're
going
to
do
this
by
last
november.
We're
going
to
do
that
by
february
march
of
this
year
and
they
would
put
out
you
know,
proposals
that
that
group
approved
of
but
then
the
technical
committee
would
not
would
have
different
ideas
and
it
would
not
ever
get
approved
or
merged
or
go
anywhere.
C
B
B
This
I
mean
again,
people
are
only
going
to
work
on
what
they're,
particularly
interested
in,
because
it's
a
open
source.
I
guess,
because
I
mean
it
is
weird
that
messaging
has
so
much
activity
and
not
database,
even
though
we
know
that
database
instrumentation
is
way
more
important,
I
mean,
I
don't
think
anyone
can
argue
with
that.
So
just
the
ordering
already
shows
us
that
we
can't
really
be
very
optimistic
that
people
will
then
step
up
to
actually
prioritize
the
things
that
users
want.
B
C
I
mean
some
some
healthy
tension
might
be
a
good
thing.
We
could,
we
could
say
to
the
spec
we
we
were
really
interested
in
making
some
progress
on
the
stability
of
these
artifacts.
A
B
C
Is
there?
Is
there
an
issue
or
an
otep
that
kind
of
captures?
This
sentiment,
like
you
know
the
sentiment
being
tried
to
like
try,
try
to
get
stability
in
at
least
some
of
the
semantic
conventions
and
try
to
for
force
the
issue,
because
if,
if
there
is
such
an
issue,
then
we
can
point
users
to
that
and
we
can
point
customers
to
that
and
we
can
vote
on
it
and
comment
on
it
and.
A
So
this
is,
I
don't
think
this
is
the
first
one
I
feel
like
there
was
it's
based
on
the
previous
otap,
so
this
is
probably
the
most.
This
is
what's
happening
for
messaging
http.
They
merge
an
otep,
so.
A
Scope
and
wrote
something
like
this
from
earlier
this
year,.
A
A
A
A
But,
oh
okay,
so
tom.
C
B
D
D
B
A
All
right,
I
will,
I
will
sleep
on
I'll
sleep
on
this.
I.
C
Yeah
one
small
thing
before
you
before
we
wrap
up,
so
I
have
a
pr
out
that
honorark
has
improved
approved
to
collapse
all
of
the
stable
otlp
exporter
artifacts
into
one
I
just
want.
You
know
before
I
merge
that
I
wanted
to
hear
if
you
had
any
opinion
on
that
trask,
I'm
all
for
less
artifacts.
A
I'm
good
with
it
I
mean
the
I
feel,
like
I
think
you
pointed
out.
They
were
all
using
the
okay
http
dependency,
so
it
seemed
like
not
really
any
benefit
to
splitting
them.
B
A
Does
does
that
open
the
door,
for
I
mean,
do
we
or
do
we
even
want
to
shade
in
the
okay
ctp
at
that
point,.
A
B
Because
there's
a
lot
of
actually
non-hotel
stuff
in
there,
and
so
I
mean
we
could
maybe
move
some
of
that
into
this
shared
artifact
if
we
wanted
to,
but
in
the
meantime
otlp
common
is
where
everything
is
and
it's
an
uber
artifact.
And
so,
if
you
were
in
the
shadow
kitchen,
you
would
shade
into
that
anyways.
B
B
B
Yeah,
we're
gonna
have
characters
in
splitting
that
and
brooke
used
to
be
shading.
Our
policy
is
gonna.
Give
someone
reports
a
big
problem
because
of
it
then
we'll
shade
it,
but
we
did
get
that
one
report,
so
I
don't
know
it
might.
We
might
get
more
reports,
in
which
case
we
might
shade
it,
but
for
now
we're
still
not
cheating.