►
From YouTube: 2022-09-15 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
C
B
B
A
Looks
like
we've
got
a
quorum,
Jack
and
John.
Probably
question
for
you:
I
was.
B
A
Around
a
little
bit
with
the
metrics
views,
attributes
processor,
which
is
internal
but
a
very
powerful
hook,
because
it
also
takes
the
context,
and
so
it
takes
the
attributes,
the
context
and
you
can
return
a
new
set
of
attributes
to
actually
stamp
for
that
specific
metric
recording.
A
I
noticed
there
was
it
looked
like
slightly
stable
support
for,
like
that
specific
use
case,
of
pulling
things
out
of
the
baggage,
but
not
the
full
power
of
you
know
doing
anything.
You
want
with
the
context
and.
C
A
A
If
there's
us
any
spec
work
ongoing
about
that.
D
I
haven't
heard
any
activity
and
I've
been
watching
Pretty
closely.
Unfortunately,
I
think
it's
a
it's.
C
D
Lack
of
a
ability
to
have
any
sort
of
SDK
level
hook
into
how
metrics
measurements,
not
metrics
and
specific
measurements
are
handled
right,
is,
is
kind
of
a
missing
piece
of
the
the
metrics
SDK
right
now,
like
another
use
case,
that
I've
heard
of
is
like
suppose,
you
want
to
be
able
to
take
your
HTTP
server
duration
instrument
and
be
able
to
determine
if
you're
meeting
some
sort
of
SLI
so
like
you
want
to
be
able
to
count
how
many
specific
requests
were
above
or
below
your
threshold.
D
It'd
be
nice.
If
you
could
configure
that
exact
threshold
in
some
sort
of
measurement
processor,
where
you
know
if
the
if
the
the
response
time
is
below
the
threshold,
contribute
to
the
count.
If
it's
not,
you
know,
contribute
to
some
other
count
so
that
you
can
have
an
exact
ratio
compute,
an
exact
ratio
of
of
of
how
many,
the
percentage
of
requests
that
are
meeting
your
your
SLI,
that's
not
possible.
A
Okay,
cool
just
kind
of
curious:
what's
if
that
was
a
near-term
or
a
long-term
thing,
I
should
I.
C
Just
I
suspect
you'd
need,
if
you
want
it,
you'll
need
to
drive
the
spec
process
forward.
As
usual.
D
Yep
the
latest
work
in
this
vaccine
is
focused
around
around
the
spec
and
metrics
seems
focused
around
Prometheus
compatibility
and
around
exponential
histogram
stability.
A
Cool
I
wanted
to
draw
people's
attention
to
this.
Pr
I
haven't
had
a
chance
to
probably
won't
get
to
it
until
next
week,
but
there
was
some
good
discussion
and
in
this
issue,
around
sort
of
the
yaml
configuration
for
being
able
to
declare
custom
jmx
metrics
in
the
agent
I
think
it's
a
really
cool,
really
useful
feature
and
if
you
think
so
have
a
look
at
the
pr.
A
I
haven't
quite
figured
out
Mateus
how
the
some
of
the
Java-
oh
I,
know
the
thing
that
I'm
having
trouble
with
right
now.
Thinking
about
this
is
I
want
from
our
distro.
I
want
to
be
able
to
configure
some
Jam
X
metrics
like
or
some
to
do
some
configuration
work,
but
there's
not
really
like.
A
B
B
Oh
so
it's
on
you
just
could
initialize
it
with
your
own
article.
It
configure,
or
with
your
own
Harvard
called
rstm
Already
like
you
could
initialize
the
second
instance
of
it
in
your
own
destroy.
So
it
really
depends
on
how
it
is
code
actually.
D
Yeah,
some
of
the
so
I
I
want
to
talk
about
the
1.19
release
for
next
month,
and
one
of
the
things
I'd
like
to
get
in
is
a
prototype
log,
slash
event
API,
and
you
know
in
order
to
get
that
in
there's,
like
a
sequence
of
things
that
need
to
be
merged
and
so
I'm
I'm
just
trying
to
think
ahead
and
kind
of
advertise.
My
my
plans
to
folks
because
I
think,
if,
if
we
want
a
chance
of
getting
all
those
steps
merged,
we
probably
got
to
start
soonish.
D
This
has
been
open
for
a
while.
This
is
the
this
is
critical
path
right
now,
so
this
renames,
the
various
components
and
the
log
SDK
library
to
match
the
changes
to
the
spec.
And
you
know
the
follow-up
step
to
this-
is
to
break
out
the
SDK
into
an
API
component
and
that's
Alpha.
So
it
kind
of
relies
on
this.
D
Did
it
did
and
and
they're
releasing
as
well?
So
that's
kind
of
exciting.
C
D
D
I
mean
technically
it's
all
experimental,
and
so
they
they
reserve
the
you
know
the
right
to
do
that
type
of
thing.
I
think
it's
kind
of
unlikely.
There's
momentum
growing
in
the
in
the
log
signal
space
and
so
I
think
everyone's
kind
of
starting
to
coalesce
around
these
ideas.
There
doesn't
seem
to
be
any
dissent.
A
D
So
just
a
quick
question
to
ask
about
like
the
mechanics
of
this,
so
let's
let's
say
that
we're
able
to
get
this
API
ready
for
1.19.0
there
there's
a
couple
of
components
in
instrumentation
that
would
be
made
obsolete
by
this,
and
so
you
know
I.
D
A
It's
a
good
Point.
We
can
point
at
the
snapshot.
It's
not
super
convenient,
but
probably
worth
it
in
this
case.
A
Given
the
I
mean
it
probably
wouldn't
be
I,
don't
know,
probably
wouldn't
be
too
bad.
Well,.
D
Fine
and
just
thinking
out
loud
actually
so
we
don't
need
to
point
the
whole
repository
to
the
snapshot.
We
just
need
to
point
that
one
PR
that's
going
to
remove
this
stuff,
so
you
can
just
like
you
know,
have
that
PR
point
to
the
snapshot
and
then
you
know
hold
off
merging
the
pr
until
you
know,
after
the
the
release
on
Friday
and
then
you
know,
most
of
the
review
will
already
have
taken
place,
so
it
should
be
pretty
trivial
to
to
merge
it
after
that.
A
And
Jason,
these
are
the
the
odd
yeah
I
forgot
that
those
were
in
there.
Thank.
D
And
then
the
other
thing
that
I
was
hoping
to
get
in
for
1.19
is
a
series
of
changes
related
to
exponential
histograms.
So
there's
a
a
controversial
change
in
the
spec
that
that
went
through
finally
to
change
the
definition
of
the
the
bucket
boundaries,
and
so
you
know
essentially
the
the
the
bucket
boundaries
disagreed
with
prometheus's
definition
of
bucket
boundaries.
D
So
Prometheus
has
a
definition
that
says
lower
exclusive,
so
you
know
the
lower
boundary
is
greater
than
and
the
upper
bound
is
less
than
or
equal
to
and-
and
you
know,
open
telemetries
bucket
boundaries
were
different
than
that
we
had
our
lower
boundaries
were
greater
than
or
equal
to,
and
our
upper
boundaries
were
less
than,
and
so
we
we
capitulated
to
Prometheus
and
changed
our
bucket
boundaries
for
alignment.
It
makes
the
math
a
little
bit
harder,
but
it's
you.
B
D
Guess
it's
it's
more
consistent
across
ecosystems,
so
that's
good
and
so
what
there's
a
PR
that
I
have
to
align
our
definitions
with
the
specifications.
Now
that's
four
six,
nine
eight,
the
math
is
the
math
and
this
is
is
pretty
tricky.
Well,
this
is
an
issue,
but
there's
a
link
to
PR
but
I.
You
know
I!
Guess
it's
hard
to
understand
the
math,
because
we
break
down
IEEE.
D
Yeah
yeah,
we
break
them
down
into
the
individual
bits
and
manipulate
the
the
the
components
of
the
the
double
manually.
D
So
it's
it's
kind
of
tricky
to
follow,
but
I
lifted
the
the
test
cases
all
from
the
go
implementation,
which
was
you
know,
I
think
Josh
McDonald
has
worked
really
hard
on
putting
the
test
cases
together
here
and
so
I
just
lifted
them
from
go
and
translated
them
to
Java,
and
so
I've
I
have
a
fair
degree
of
confidence
that
this
is
that
this
is
correct
and
and
James
took
a
look
as
well.
D
That
was
part
of
the
histogram
exponential
histogram
implementation,
all
right
so
yeah,
so
I
I
want
to
get
this
in
and
I
think
that
this
would
help
unlock
stabilizing
exponential
histograms
at
the
spec
level.
I
think
they're
waiting
for
implementations
and
you
know
go
has
one
and
Java
has
won
and
Dot
Nets
is
pending,
and
so
you
know,
stable
implementations
are
I.
Think
the
the
limiting
factor
at
this
point
is
stability.
A
A
And
yeah
there
was
the
the
consistent
sampling
the
probability
sampler
also
had
some
similar
IEEE
double
math.
That
was
equally
fun
to
review
bit.
A
D
It
took
me
a
while
to
to
digest
what
the
math
that
Josh
McDonald
was
advertising
in
the
in
the
spec.
So.
B
D
I'm
pretty
confident
in
it
and
then
okay.
So
here's
an
open
question
so
I
want
to
promote
the
exponential
histogram
data
model
portions
to
be
in
our
stable
packages
they're
in
internal
packages.
D
Right
now-
and
this
is
like
this-
is
a
bit
strange
because
the
Proto
is
stable
so,
like
our
data
model
classes
are
a
reflection
of
the
the
protos
and
the
protos
are
not
allowed
to
change,
so
you
know
the
only
thing
that
can
change
is
things
like
you
know
the
the
comments
around
the
fields
and
so
changing
the
bucket
Bounder
definitions
from
lower
inclusive
to
lower
exclusive
is
like
an
example.
They
just
the
way
they
made.
That
change
was
they
just
like
changed
the
comment
in
the
Proto
schema,
and
so
you
know
I.
A
D
They
change
the
behavior
without
changing
the
interface
right
and
so
I
think
in
a
similar
way,
we
could
Mark.
We
could
Mark
our
exponential
histogram
data
classes
as
stable
as
well,
because
I
don't
think
the
interface
is
going
to
change
at
all
and
that
would
open
us
up
to
getting
rid
of
this.
Like
pesky
metrics
testing
artifact
that
has
been
floating
around.
We
have
this.
D
You
know
extra
artifact
that
just
contains
assert
J
classes
for
asserting
the
unstable
parts
of
the
metrics
SDK,
namely
exponential
histograms
and
exemplars,
and
so
exemplars
are
not
going
to
stabilize
anytime
soon.
Unfortunately,
but
you
know
I
figure
we
can
move
like
we
can
stabilize
exponential
histograms
and
then
move
the
Exemplar
assertions
to
an
internal
class
and
the
standard
testing
artifact
and
everybody
wins.
C
D
Well,
the
only
other
candidate
would
be
dot
net
because
I
don't
think
that
JavaScript
or
go
have
marked
mark
their
metrics
sdks
as
stable.
Yet
so.
D
A
Cool
yeah
that
would
be
maybe
my
only
thought
or
or
maybe
bring
it
up
in
the
spec
meeting
just
to
confirm.
Nobody
has
objections.
D
D
So
those
are
my
two
items
or
kind
of
two
categories
of
work
that
I'm
targeting
for
1.19.0.
If
anybody
else
has
any
kind
of
you
know
changes
to
the
core
repository
that
they're
thinking
about
and
that
would
take
longer
to
you
know,
review
or
and
merge.
Let
me
know,
and
we
can
get
started
on
that.
E
A
E
A
Missed
that
there
was
over
here
also
I
removed
it
from
the
calendar.
Sorry
I
thought
I
was
thinking
that
meant
this
calendar,
the
Google
Calendar
I
removed
it
I
will
send
a
PR.
E
And
then,
regarding
that,
so
it
sees
that
there
is
already
so
the
question
was
about
juice,
Matrix
and
I.
Think
Jack
has
a
proposing
place
for
GC
related
metrics
and
I
found
that
proposal
pretty
interesting.
Interesting
I
have
interest
in
that.
So
I
would
like
to
know
what
what
needs
to
to
to
be
done
in
order
to
get
this
moving.
So
I
had
some
comments
on
it.
D
Oh
I
I
haven't
looked
at
this
in
a
while
because
it
kind
of
went
stale
I
see
you
left
a
comment
yesterday.
Let's
see
in
terms
of
what
would
need
to
happen
to
get
this
to
merge.
D
I
think
you
know,
I
I,
think
some
of
the
folks
that
have
been
involved
in
the
the
jvm
conversations.
The
jvm
working
group
would
need
to
comment
and
say
that
they're
aligned
with
the
directionally
aligned
with
this
and
if
they
are
then
I
can
go,
and
you
know
get
this
PR
ready
for
actual
merging.
D
D
A
D
Yeah,
there's
like
an
ordering
question
right
so
do
we
do
we
first
propose
it
in
instrumentation
and
validate
then
we
can
actually
implement
it
as
proposed
and
then
add
it
to
the
spec
or
vice
versa.
D
E
D
The
open,
Telemetry
specification
has
a
portion
related
to
jvm
semantic
inventions,
and
that's
what
we
see
that's
what
trials
yeah
and
the
idea
behind
you
know
having
these
in
the
semantic
conventions
is,
is
there
may
be
more
than
one
implementation
of
these
metrics?
D
D
You
know
we
control
the
the
Frameworks,
and
so
when,
like
we're,
gonna
we're
just
gonna
say
that
these
are
the
important
things
we
have
lots
of
History
instrumenting,
the
the.net
runtime,
and
these
are
the
things
that
are
important.
So
it's
kind
of
a
different
approach
than
what
we've
taken.
A
So
yeah
Rafael
I
mean
I,
think
there's
I
I
know
I'm
supportive
of
this,
so
I
Jack
would
I.
Would
it
help
to
have?
Are
you
just
looking
for
review
or
at
looking
for
somebody
to
sort
of
take
over
the
the
work.
D
I'm,
just
looking
for
like
a
thumbs
up
or
like
a
couple
of
thumbs
up
that
people
are
aligned
with
the
approach
right.
So
then
I
can
I
can
continue
with
it.
But
you
know:
I,
don't
wanna
I,
don't
wanna
push
forward
if
I'm
the
only
person
that
thinks
that
this
is
the
right
direction.
A
Got
it
cool,
yeah
I
will,
let's
get
some
people
and
primarily
I
would
say
if,
if
you
don't
review
well,
I
guess
the
code's
pretty
straightforward
anyway,
which
is
awesome,
but
just
the
kind
of
the
spec
commenting
on
the
spec
here
would
be
great.
E
D
Real
quick
on
that
subject:
Raphael
so
I
just
got
a
chance
to
read
your
comment.
A
bit.
I
haven't
fully
digested
it,
but
I
did
do
some
research
into
the
memory
usage
before
and
after
so
that
information
is
accessible
in
these
garbage
collection
events,
you
can
you
can
look
at
the
different
pools
and
sum
up.
The
total
memory
before
and
after
in
practice,
I
found
that
it
was
problematic,
because
some
of
these
events
are
happening
in
parallel.
D
So
you
can't
you
can't
necessarily
say
that
this
garbage
collection
event
was
responsible
for,
for
you
know
the
Reclamation
of
this
memory,
because
there
could
be
other
garbage
collection
events
that
were
like
interacting
with
those
pools
as
well.
E
E
But
in
that
case,
wouldn't
that
information
be
reliable,
let's
say
in
that
case
we
would
in
the
end
we
would
get.
Let's
say
the
lowest
possible
amount
of
memory
that
we
will
be
able
to
run
with.
Let's
say
all
the
reference
were
cleaned
other
all
the
reference
that
are
see
not
valid
anymore
will
be
cleaned,
and
then
that
point
we
get.
Let's
say
what
this
is:
the
minimum
amount
of
memory
that
the
your
application
can
run
with.
D
Yeah
and
in
that
case
you're
totally
right,
you
can
so
those
stop
the
world
events,
the
I
kind
of
punted
on
this
question.
But
so
you
know
you
have
a
couple
bits
of
information
to
identify
the
type
of
garbage
collection
event
that
was
happening.
You
know
like
the
garbage
collection
and
that's
reflected
in
these
attributes
that
I'm
reporting
here.
D
So
you
have
the
garbage
collection,
key
the
cause
and
then
the
action,
and
so
you
can
you
can
you
know
you
have
to
be
able
to
determine
from
that
those
bits
of
information,
whether
the
event
was
a
stop
the
world
event
or
not?
Like
you,
don't
there's,
there's
no
like
property
that
says:
hey
this
garbage
collection
event
was
to
stop
the
world.
D
You
have
to
like
use
context
based
on
the
type
of
garbage
collector
that
was
happening
and
the
type
of
garbage
collection
action
that
took
place
to
figure
out
if
it
was
likely
to
stop
the
world
event
and
so
I
guess
what
I
didn't
take
the
the
time
to
do
was
to
analyze
all
the
different
garbage
collectors
and
all
their
different
actions
and
try
to
come
up
with
like
a
mapping
of
like
this
garbage
collector
and
this
action
corresponds
to
stop
the
world.
D
So
I
I
haven't
done
that
work.
Yet,
okay,.
E
C
D
C
D
A
So
one
lens
to
look
at
this
in
as
like,
if
there's
additional
things
like
capturing
memory,
you
know
before
and
after
are
those
things
that
could
be
layered
on
top
of
this,
and
if
so,
you
know,
we
could
be
comfortable
with
this
as
sort
of
a
minimum.
You
know
step
and
an
initial
step,
and
then
we
can
experiment
with
other
things.
On
top
of
that,.
A
The
yeah
so
like
I
want
to
be
able,
like
in
a
span
processor,
for
example.
I,
would
love
to
be
able
to
stick
something
into
the
context
or
maybe
in
the
sampler,
but
yeah
as
John
says
it's
the
it's
a
two-step
in
the
at
the
SDK
level.
It's
a
two-step
process
start
your
span,
you
get
your
span
back
and
then
you
have
to
manually
create
a
context
with
the
Span
in
it.
C
Only
because
I
think,
if
you
put
it
in
the
SDK
itself,
it
was
would
end
up
being
something
that
controlling
the
scope
of
that
context
would
end
up
being
very
easy
to
get
wrong
for
what
the
user
actually
wanted.
I
think,
whereas,
if
you're
in
the
very
controlled
world
of
you
know
how
all
the
instrumentation
that
uses
this
is
going
to
use
it,
I
feel
like
I
could
be
wrong
here
like
I
would
be
okay
if
someone
wanted
to
propose
an
API,
although
this
is
also
something
that
probably
I
think
should
go
in
the
spec.
C
If
we
wanted
to
be
able
to
support
it,
but
I
have
a
hard
time
imagining
an
API
in
the
SDK
proper
that
wouldn't
make
it
super
easy
for
a
user
to
do
something
wrong
and
break
everything
for
themselves.
A
Yeah
sort
of
what
I
was
imagining
was
like
say
start
span,
returned
a
context
instead
of
returning
a
span,
but
I
mean
this
is
a
huge
change
and
I
kind
of
think
it
ties
into
at
one
point:
wasn't
there
this
discussion
of
eliminating
span
altogether
and
just
just
having
the
context
yeah
yeah?
That
is
true
and
so
I
think
it's
kind
of.
C
A
So
then,
maybe
mitesh,
my
question
may
come
back
to
then
on
the
instrumentation
side
or
in
the
Java
agent
side.
Is
there?
Could
we
have
like
a
global
like
an
SPI
that
somehow
that
we
can,
in
a
distro
add
our
own
context,
customizers
to
the
instrument
or
API.
B
B
B
That
it's
used
to
insert
some
things
that
are
used
during
respawn
processing
like
the
HTTP
withholder,
on
the
same
other,
like
exception
holders,
and
mostly
things
that
you
want
to
save
for,
spend
the
tent.
B
A
Okay,
yeah
and
kind
of
where
my
kind
of
related
to
this
is
in
this
API.
It's
nice
that
we
pass
in
the
attributes,
because
part
of
my
interest
is
around
spans
that
get
sampled
out.
A
I
still
want
to
stamp
some
things
onto
the
metrics.
Basically,.
B
Yeah,
so
this
happens
with
four
metrics
well
handled,
and
this
I
mean
in
the
instrumental
class
that
you
we've
seen
before
the
operation.
Wrestler
is
responsible
for
running
metrics,
usually-
and
it's
apparentical
just
after
that.
So
if
you
had
some
kind
of
a
global
customizer,
then
it
would
happen
before
Matrix.
So
you
could
access
things
in
metrics.
E
I,
don't
know
I
really,
don't
know
what
will
happen
on
sampled
out
traces.
Oh
if
we
want
to
include
that
on
logs.
A
A
But
if
you
wanted
to
stamp
something
else
like
like
a
tenant,
ID
is
kind
of
the
the
use
case
that
I'm
working
through
is
I
want
to
stamp
this
tenant
ID
on
all
the
metrics,
whether
it
got
sampled
or
not,
and
so
logs
would
be
yeah
a
good
example
there,
and
it
relates
a
little
bit
to
Christian,
has
a
an
Otep
proposal
about
contact
scoped
attributes.
A
So
this
is
kind
of
nice
kind
of
related,
and
maybe
ideally
we
should
use
baggage,
but
I,
don't
know
the
baggage
propagates
over
the
wire,
but
then
there
could
be
enhancements
to
baggage
I.
Think
there's
a
few
baggage
also
supports
not
propagating
over
the
wire,
but
we
don't
support
that
in
Java.
Yet
do.
A
C
B
A
C
D
C
Is
actually
something
that
open
census,
baggage,
supported,
I
believe
and
there
it's
the
purpose
from
what
I
understand
of
the
metadata
that
you
can
associate
with
baggage,
which
isn't
used
for
anything
right
now,
but
that
metadata
field
was
supposed
to
be
for
yeah
exactly
for
like
describing
in
what
some
cases
describing
how
it
should
or
should
not
propagate.
C
Mean
it
could
be
used,
the
metadata
that
can
be
used
for
anything,
and
there
was
no,
they
never
got.
They
haven't
gotten
around
to
at
this
point,
specifying
exactly
what
the
semantics
are
for
the
metadata
but
yeah
anyway.
That's
that's
what
that
was.
It
is
intended
for
just
nobody
has
got
the
specification.
Done
Yet,
interesting.
A
This
out
tip
is
an
interesting,
read
and
related
to.
That
seems
to
be
the
main
contention
here
as
whether
we
should
improve
baggage
to
handle
this
stuff
or
not.
B
I
think,
a
while
ago,
all
over
yours
or
something
that
somewhat
relevant
PR,
that's
actually
kind
of
accidentally
implemented
this
on
them.
That's
added
a
possibility
to
set
attribute.
So
did
we
propagate
attributes
for
context.
B
It's
it
was
required
by
like
requires.
This
was
one
of
our.
Our
customers
wanted
to
customize
the
HTTP
clients
panel,
which
is
normally
not
accessible
in
like
application
code,
and
this
way
you
could
like
prepare
some
attributes
before
the
actually
being
called
stocks,
and
then
instrumental
would
just
automatically
append
them.
A
Right
and
this
primarily,
this
was
exposing.
B
A
Cool
yeah
I'll
have
to
look
back
over
this
I
think
that
we
were
pretty
much
agreed
with
this
pending.
B
No,
we
didn't
rename
the
artifact
and
we
probably
didn't
do
anything
else
on
the
other
bullet
points
like
there
is
no
incubator
package
over
there.
Oh
so
yeah
that
we
need
to
do
that.
First,
obviously,.
A
All
right
well,
thank
you
for
chatting
through
that
with
me
any
other
anything
else.
Anybody
wants
to
chat
about
today.
A
Release
went
out
yesterday,
instrumentation
release
yay,
the
contrib
release
should
go
out
tomorrow.
A
There's
a
problem,
though
the
static
instrumenter
test
integration
test
is
failing
and
so
I
may
just
disable
it
unfortunately
I
the
test
kind
of
points
to
it.
The
static
instrument
are
actually
being
broken,
though.
B
A
Is
not
great,
so
I
don't
really
want
to
just
dis,
ignore
it,
but
it's
also
not
I'm,
not
sure
if
anybody
is
using
the
static
instrumenter.
Yet
we
can
ask
them
to
take
a
look
at
it
if
they
have
Cycles
yeah.
Okay,
I
appreciate
it.
C
Hey
Jack:
did
you
want
to,
in
the
spirit
of
transparency,
talk
about
the
cleanup
we're
gonna
do
on
the
approvers
in
Java.
D
D
There's
a
PR
out
proposing
that
we
add
Trask
and
Matisse
as
approvers
they've
been
great
reviewers
of
everything,
and
so
you
know,
thanks
for
all
your
contributions
and
some
of
the
other
approvers
that
we've
had
I
haven't,
really
been
super
engaged
and
so
we're
gonna,
we're
gonna,
trim
them
off
and
unless
they
they're
interested
in,
you
know
becoming
more
active
in
the
project
and
so
I
think
the
the
plan
was
to
remove
watch
the
Kuba
watch
and.
A
A
Most
of
most
of
the
other
repos
use
the
alias
in
the
code
owners
file,
yeah.
D
So
yeah
thanks,
Trask
and
Mateus
for
all
your
all
your
reviews
and
if
anybody
else
is
interested
in
getting
involved
with
the
the
open,
Telemetry
Java
project,
you
know
we
we
are.
We
are
open
to
contributions
and
and
PR
reviews
and
ideas,
and
so
please
please,
please
give
us
some
reviews
if
you're
interested
in.
C
Yeah,
especially
if
you
are
a
lover
of
bit,
masks
and
IEEE
floating
Point,
arithmetic
and
such
that
exponential
histogram
PR
needs
eyes
on
it.