►
From YouTube: 2020-07-30 Java SIG
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
You
have
a
good
good
break.
B
Yeah,
it
was
pretty
good.
We
went
up
to
vashon
island
for
a
week,
rented
a
house
by
the
water,
so
I
sat
and
stared
at
the
water
and
read
books
for
a
week,
so
that
was
nice.
A
B
B
Had
a
view
of
mount
rainier-
oh
nice,
very
nice
and
sitting
right
on
the
sound,
so
it
was
good
jason
plumb.
Your
hair
is
much
shorter
than
the
last
time
I
saw
you.
C
A
Yeah,
it's
pretty
intense.
D
D
A
A
A
discussion
of
the
oh
honorable
had
submitted
a
the
log4jmdc
integration
into
the
instrumentation
repo
and
then,
while
we
were
reviewing
realized
that
the
same
code
essentially
existed
already
in
the
java
repo,
so
was
wanted
to
try
to
like
outline
what
what
we
thought
belonged
where
and
so
definitely
you
know
need
both
groups
sort
of
consensus
on
this.
A
I
think
we
had
this
discussion
before
and
I
think
would
when
carlos
submitted
the
the
initial
systemetric
stuff-
and
I
think
we
had
discussed
moving
it
to
this
repo
at
that
time,
and
then
mdc
logging
integrations
that
sort
of
a
special
category
I
mean
with
wherever
it
belongs.
It's
not
quite
instrumentation,
since
they
don't
emit
anything.
A
It's
for
encoding,
trace
id
span
id
into
the
logs
and
then
spring
boot
starters
is
kind
of
another
thing:
it's
not
really
instrumentation,
so
I
think
it
would
be
good
to
sort
of
decide
where
we
want
all
of
these
different
components
to
live.
B
Just
on
the
on
the
system,
metrics
side,
there's
a
aside
from
carlos's,
more
detailed
one,
there's
a
very
simple
set
of
gc
and
something
else
I
don't
know
what
it
is:
metrics,
maybe
cpu
metrics
from
jmx
in
the
java
repo
that
should
be
moved
and
needs
all
of
its
all.
The
metric
names
need
to
be
fixed
for
that
as
well,
but
it's
currently
in
the
java
extensions,
sdk
extensions
or
api
extensions.
A
Cool
and
then
there
was
one
other
kind
of
grouping
that
I
didn't
include
here,
because
my
initial
thought
was
that
maybe
these
would
be
in
the
sdk.
A
A
What
we
want
to
do
as
far
as
micrometer
registry
or
micrometer
interop,
maybe
at
some
point
spring
cloud
sleuth,
but
just
that
idea
of
integrations
with
other
telemetry
libraries
as
another
bucket.
That
would
be
good
to
decide
where
we
want
them
to
live.
A
So
no
rush,
we're
not
gonna
make
you
know
who
won't
make
any
decisions
today,
but
would
like
to
get
initial
thoughts
on
this.
F
My
initial
feeling
for
the
open
tracing
is
that
it's
for
this
time,
for
the
time
being
in
the
open,
telemetry
java
repo,
it
should
be
fine.
I
don't
know
whether
we
will
be
using
it
much
with
instrumentation
jar,
but
probably
in
the
future.
But
I
don't
imagine
we
need
in
this
for
the
for
this,
for
the
short
or
medium.
A
Term
yeah,
but
I
mean
in
general
these
things
I
mean
we
do
want
to.
I
mean
like
if
we
had
a
micrometer
registry
or
spring
cloud
sleuth.
The
only
reason
that
I'm
not
really
that
interested
in
doing
open
tracing
in
on
the
agent
is
just
because
it's
a
deprecated
project,
but
the
others
are
still.
You
know
very
much
alive
and
moving
forward.
So
if
we
could
do
auto,
auto
registration
of
these
kinds
of
shims
or
something
we
would
want
to
do
that.
F
A
Could
keep
it
just
sdk?
You
know
just
like
really
focused
only
on
sd
the
api
and
sdk
well,
but
then
there's
also
like
propagators,
I
mean
there's,
there
are
other
things
over
there.
Also
that
do
make
a
lot
of
sense
over
there.
I
don't
think
they're
really.
B
I'm
glad
we're
talking
about
it.
That's
what
I
think.
That's
interesting.
There's
a
cuz
there's
also
like
alternative
there's,
the
the
what's.
It
called
disrupter
based
exporters
over
there.
I
guess
things.
I
guess
the
question
is:
if
they're,
maybe
sdk
extensions,
probably
would
not
belong
in
the
instrumentation
repo,
because
that
I
mean
it
feels
like
if
it's
an
instrumentation,
it
should
be
either
agent
related
right.
B
So
it's
actually
like
wiring
up
the
agent
and
getting
everything
working
and
doing
that
kind
of
stuff
to
get
the
sdk
working,
but
otherwise
it
should
be
thing
like
the
api
extensions
they
probably
most
of
them
do
belong
in
instrumentation
because
they're
all
about
using
the
api
to
do
something
interesting,
which
is
kind
of
what
instrumentation
is
about.
B
I
see
it's
disproved
ratified
and
added
to
the
constitution.
C
I
mean
maybe
one
additional
counterpoint
is
that
the
repo
is
pretty
sizable
already
and
adding
more
things
to
it
will
increase
that
size
which
may
not
be
desirable.
It's
kind
of
true
about
both
both
repos.
D
A
Which,
I
think
is
kind
of
the
I
mean
part
of
the
point
of
the
instrumentation
repo
is
to
manage
all
of
you
know
those
library
specific
things
across
the
java
ecosystem.
I
mean
in
that
way
it's
nice.
If
the
sdk
repo
is,
you
know
more
focused.
A
I
yeah,
I
guess,
I'm
I
still
kind
of
fall
back
to
this
piece
like
like.
If
it's
like
propagators,
feel
to
me
like
well
like
a
api
extension,
it's
not
related,
it's
not
like
integrating
with
spring
boot
or
in
it
or
integrating
with.
D
D
G
F
I
don't
feel
honestly,
that's
going
to
be
the
case.
I
think
that
the
idea-
and
you
know,
is
that
we
support
all
the
well-known
propagators,
even
if
they
are
not
open
source
and
I
think
having
the
amazon
one
shows
shows
that,
and
I
think
that
there
are
only
so
many
propagators.
F
A
And
we
did
just
add
the
lights,
death
or
the
open
tracing
and
the
x-ray
propagators
to
the
agent.
B
D
I
think
one
more
attribute
that
we
can
decide
upon
is
artifact,
name
or
group
id.
Do
we
want
this
artifact
in
io,
open,
telemetry
group
id
or
io
open,
telemetry
instrumentation
group?
B
B
A
This
does
seem
like
instrumentation
to
me
because
it
is,
you
have
to
sort
of
instrument
with
those
the
scope
the
mdc
points
to,
but
I
agree
that,
like
system
metrics,
I
have
a
harder
time
calling
that
instrumentation
and
same
with
spring
boot
starters.
A
D
Boot
starters,
for
me,
they
live
in
io,
open
telemetry
group
id.
I
don't
know
why,
but
I
I
feel
that
way.
I
open
italian
f3
instrumentation
spring
start
springboard
starter
a
little
bit
a
little
bit
weird
for
for
me.
If,
if
we
only
have
like
manual
well,
not
manual,
we
have
those
spring
specific
spi,
essentially
spin
boot,
specific
sbi.
E
B
A
Yeah
yeah,
that's
I
don't
know
like.
I
don't
know
what
to
do
like
like
we
all
all
the
vendors
have
a
micrometer
registry
right
that
collects
and
then
sends
directly
to
our
back
end
but
like
it
doesn't
quite
work.
B
I
mean
the
issue
really
is
like
that.
Just
the
model,
the
metric
model
is
so
different.
It's
gonna
be
hard
to
like
I
was.
I
actually
did
an
experiment
a
month
ago
about
trying
to
do
this,
like
what
do
you
do
with
the
histogram
type
like
there?
Isn't,
there's
no
such
thing
in
the
open,
telemetry
apis,
so
yeah
anyway,
no
idea
what
we
should
do.
A
There,
okay,
I
mean,
I
agree,
this
is
a
good
way
to
think
I
I
mean
this
does
strike
me
as
a
nice
way
to
think
about
it.
D
And
one
more
differentiator
is:
does
this
thing
have
to
use
any
classes
from
instrumentation
library?
So
that's
what
again
one
one
easy
thing
to
to
decide
if
it
only
depends
on
api
and
sdk,
and
then
it's
shady,
but
if
it
has
dependency
on
our
classes,
like
I
don't
know,
tracers
those
neutralizers,
then
it's
clear.
G
A
Cool-
let's
kind
of
all
digest
this
and
maybe
john
carlos.
Do
you
think
this
would
be
worth
chatting
about
tomorrow
in
the
java
sig,
or
should
we
wait
a
week
and
chat
again.
B
A
Cool,
I
will.
I
will.
A
Join
nikita
over
to
you.
D
D
A
So
are
you
thinking
about
like
like
trying
to
say
you
know
what
lay
out
like
a
week?
You
know
here
over
the
next
four
weeks.
You
know
trying
to
close
this
set
this
week.
This
set
this
week,
something
I'm
trying
to
think
of
what
what
your,
what
would
help
us
move
towards
less.
D
A
Make
up
like
a
plan
of
what
we're
going
to
yeah
yeah?
I
don't
know,
but
just
let
me
pull
up
here.
So
this
is
all
the
required
for
ga.
A
So
I
mean
certainly
that's
you
know
the
place
to
start
just
to
review
for
folks
what
the
p1,
what
the
kind
of
so
p1
you
know,
is
just
things
that
are
without
absolutely
necessary.
Can't
ga
without
them,
p2
is
everything
that
is
contributor.
Experience
related.
A
So,
as
far
as
being
able
to
onboard
new
contributors
have
existing
contributors
more
efficient,
primarily,
I
would
say
around
new
contributors,
though,
because
on
we
think
that
that's
the
only
way
we
can
kind
of
scale.
This
project
is
to
be
able
to
get
more
people
coming
in
and
contributing.
A
And
then
p3
is
a
bunch
of
great
features
and
things,
but
just
things
that
you
know
we
could
always
add
in
after
ga
I
mean
yes,
it
would
be
a
shame
not
to
have
metrics
for
ga,
but
we
can.
I
think
we
can
still
call
it
a
ga
scoped
down
to
just
tracing.
A
B
B
F
Probably
we
can
help
in
lifestep
going
forward,
as
I
said,
sergey
has
been,
you
know,
like
he's,
releasing
the
call.
Probably
he
could
help
a
little
bit.
A
So
nikita,
what
are
you
looking
for
here?
Are
you
looking
for
kind
of
a
plan,
coordination
for
moving
towards
ga.
D
My
concern
when
I
added
that
item
to
the
agenda
was
that
it
seems
to
me
that
I
and
you
trust
we
are
not
attacking
ga
like
on
like
explicitly
we
doing
stuff,
which
some
of
them
related
to
ga.
Some
of
them
is
scratching
our
current
issues
around
build
process
and
and
like
that,
so
of
course,
there
will
be
some
issues
that
come
from.
D
I
have
several
shows
that
come
from
vendor
side
that
I
have
to
fix
in
gen
in
open
telemetry
sooner
than
later,
so
there
is
some
like
tangential
issues,
but
at
least
those
p1
issues
we
should
somehow
like.
We
have
to
make
a
steady
progress.
Actually
I
don't
know
make
it
make
a
commitment
close
to
p1
issues
per
week,
at
least
something.
A
Yeah
yeah,
why
don't
we
start
making
that
a
regular
part
of
this
meeting
is
to
track
the
p1
issues,
progress?
What
you
know
we
can
look
at
what
we
closed.
Look
at.
It
keep
a
total
number
kind
of
try
to
burn
down,
because
that
I
agree,
the
93
number
is
kind
of
overwhelming,
and
so
it's
easy
to
be
like,
but
the
p1
issues
to
me
feels
focused
and
like
we
would.
We
could
track
that
and
try
to
push
those.
A
D
Well,
if
we
have
some
kind
soul
to
take
some
of
them,
that
would
be
perfect,
but
at
least
to
us
I
don't
know
if,
if
we
assign
to
ourselves
that
probably
will
turn
down
some
some
contribute
outside
contributor.
This
is
the
issue
is
already
assigned.
I
will
not.
I
will
not
take
that.
So
that's
probably
the
bad
thing,
but
on
another
side
we
currently
as
well
look.
Maybe
somebody
else
will
take
that
someday
in
the
future.
A
Let
let's
start
with
tracking
the
p1
issues
talking
about
them,
escalating
them
in
this
meeting
and
kind
of
the
main
end
maintainers,
who
are
you
know,
try
to
focus
on
those
issues
and
then,
if
we're
still
not
seeing
progress
that
we
want,
then
we'll
go
to
this.
D
C
A
A
D
D
H
D
A
So
zero
seven
zero
is
happening
should
happen
next
week.
Carlos
is,
do
we
lose
carlos?
I
don't
see
carlos
anymore.
A
John,
I
know
you're
just
back
so
do
you
know
if
sdk070
is
still
planned
for
monday.
B
I
just
got
back,
I
have
no
idea,
I
mean
it's
supposed
to
be.
I
don't
know
how
much
I
think,
there's
a
few.
B
A
So
wanted
to
reach
out
if
anybody
has
issues
that
they
would
like
to
see
us
get
into
zero,
seven
zero,
let
us
know
here
or
any
other
form
of
communication,
the
only
one
that
I
thought
that
I
would
like
as
this,
because
it
was
has
been
brought
up
a
couple
times
recently
is
the
multi-propagator
support
and
we
were
a
little
blocked
on
what
the
our
configuration
was
going
to
be
and
I'd
suggested,
taking
it
to
the
spec,
but
then
rereading
yesterday,
I
I
agree
with
nikita's
proposal
just
that,
if
there's
multiple
propagators
in
this
list
to
use
the
multi-propagator
just
automatically
put
them
in
the
multi-propagator
carlos
had
some
concerns
about
custom
propagation
signal
custom
propagators
in
that
list
and
that
they
wouldn't
necessarily
fit
in
you
wouldn't
want
them
in
the
multi-propagator.
A
A
A
Sergey
does
that
make
sense
to
you,
and
would
you
are
you
still?
I
know
you
you
were
assigned
to
this
originally.
Is
that
something
that
you
could
do,
or
should
we
unassign.
G
No,
I
I
can
do
it
of
course.
Yes,
because
yeah.
I
also
propose
the
same
to
carlos
like.
If
we
have
several
propagators,
then
we
use
multiple
multipropagator,
but
carlos
was
not
happy
with
it.
So
that's
why
we
have
such
long
discussion.
If
it's
okay
yeah,
I
can
create
pull
requests,
not
too
much
work.
E
A
You
before
so
I
I
had
thought
about
doing
this.
You
know
using
this
meeting
as
sort
of
a
potentially
because
since
we
had
some
slow
meeting
weeks,
that
kind
of
a
weekly
digest
of
what's
happened
in
the
project
since
not
every
everybody
follows
all
of
the
issues
and
prs
because
there's
a
lot
but
before
we
get
go
there,
any
any
topics
that
people
want
to
bring
up
today.
H
Yeah,
I
noticed
that
there
was
an
issue
about
like
providing
like
mdc
support.
I
noticed
that
right
now,
like
the
open,
telemetry
api
does
not
add
like
trace
ids
or
span
ids,
to
like
logic,
to
log
messages
when
they're
generated.
I
was
wondering
like
what's
the
timeline
on
that
and
if
I
could
pick
that
up
as
like
an
issue.
A
Yeah
so
there's
some
history
there
there's
a
probably
I
can
find
it
over
here.
Tyler
created
this
is
probably
the
oldest
might
be
like
one
of
the
oldest.
Oh.
No.
It's
closed.
I
thought
tyler
opened
it.
Okay,
let's
try
mdc
scope,
listener.
I
It's
295
down
there.
Oh.
A
Oh
yeah
and
then
I
think
here
bogdan
reopened,
oh
yeah,
initially
requested
in
295.
This
was
tyler's
original
issue
and
so
yeah
there's
no
way
right
now.
The
api
doesn't
provide
a
scope
listener,
which
is
really
what
we
need
to
implement.
Those
mdc.
A
B
A
I
think
we
thought
it
should
be
in
the
api,
for
I
mean
because
the
the
logging
mdc
integrations
would
want
to
use
that
right
and
the
typically
the
instrument.
Well
always,
the
instrumentation
is
all
done
against
the
api,
not
against
the
sdk.
B
I
don't
remember
what
I
thought
there
was
a
spec
issue
opened
up
about
this,
but
I
I
don't.
I
don't
remember
enough
about
the
whole
issue.
Okay,
but
I
mean
I
think,
I'm
not
opposed
to
adding
this.
It
seems
like
a
reasonable
thing.
I
don't
know
how
do
you
have
a
good
handle
on
how
much
of
a
change
it
would
need
to
be
to
the.
B
B
B
B
B
E
A
Oh,
that's
true
right
right,
because
if
we
the
width
scope,
oh
no,
but
the
width
scope
is
still
global.
It
doesn't
always
go
through
the
tracer.
No.
A
B
Again,
scope
listener.
H
A
Especially
now
that
the
only
time
that
me
and
nikita
and
honorag
are
awake
at
the
same
time
as
10
pm,
pacific.
A
Okay
good
question:
when
you're
yeah,
if
you
can
join
tomorrow,
that
would
be
great,
if
not
follow
those
issues
and
we'll
try
to
post
there
and
see
how
we
can
make
pride
progress.
A
I
D
I
have
concerns
with
with
our
java
concurrent
auto
instrumentations.
A
That
sounds
like
a
special
topic
meeting
yeah
set
up
special
topic
meeting.
I'm
gonna
give
that
to
you.
A
Okay,
all
right,
so
just
a
quick,
10
minute
weekly
digest
a
bunch
of
bunch
of
stuff
happened,
a
lot
of
activity,
a
bunch
of
other
things
contributed
by
new
contributors.
A
So
we
already
talked
about
issues
triaged.
We
now
have
our
mary
instrumentation,
which
is
a
project
that
anurag
has
worked
on
before.
So
he
was
interested
in
trying
out
writing
instrumentation
for
that,
but
that's
cool.
We
now
have
our
merry
instrumentation,
it's
a
fairly
popular
project
I
hadn't
heard
of
it
previously,
though
update
name
now
this
is
cool.
So
before
we
used
to
call
like
for
routes
for
spring
mvc
routes,
we
would
update
the
parent
span,
which
was
the
server
span.
A
We
would
update
the
span
name
on
that,
but
sometimes
it
would
be.
It
wasn't
like
if
it
hadn't
ended
up
being
a
span
in
between
there
does
parent
span
was
didn't
necessarily
wasn't
necessarily
the
server
span,
and
so
now
we
keep
the
server
span
in
the
context.
We
put
it
in
the
context
as
a
named
thing,
and
so
we
get
that
and
we
call
update
meme
on
that.
So
I
think
that's
cool.
A
We
have
a
nightly
build
now
using
github
actions,
and
so
we
still
need
to
we're
not
getting
we're
kind
of
ignoring
them.
So
far
until
we
create
an
issue
on
the
nightly
failure,
but
one
nice
thing
there
we'll
be
able
to
do
like
the
latest
dependency
tests
nightly
so
that
it
stops
breaking
people's
pr's
because
that's
confusing
for
contributors
when
the
latest
dependency
test
starts
failing
and
then
eventually,
we
would
like
to
move
to
github
actions
for
all
the
builds
the
database
type
spans.
Did
I
see
no
giovanni?
A
Who
is
not
here
today,
so
this
is
the
type
spans
that
we've
been
chatting
about
for
a
long
time,
and
so
this
is
the
first
iteration
to
now
hit
the
repo,
and
so
next
step
is
to
try
them
out
use
them
the
we
updated
the
database.
Oh
kitty,
we
updated
the
database
semantic
attributes,
so
this
oh
yeah,
so
this
was
giovanni.
A
This
was
helen
and
so
we're
now
the
database
semantic
attribute.
It's
got
a
big
makeover,
so
we
now
are
updated
to
them.
There's
still
a
lot
more
semantic
attributes
that
we
could
capture,
but
at
least
what
we're
capturing
now
conforms
to
them.
A
We
learned
how
to
make
a
patch
release.
We
we
try
it
at
zero,
six
one,
and
so
it
didn't
end
up
totally
working
out,
but
we
got
it
down
now
so
zero
seven
one
if
it
should
be
needed,
should
be
less
work
and
more
correct.
A
A
Yeah,
oh
cool,
there's
a
whole
there's
a
whole
logs
working
group.
A
We've
got
a
record
exception
now
in
the
span.
This
was
something
new
added
in
the
open,
the
hotel
java
repo,
and
then
we
updated
that
we
updated
to
use
that
so
that's
cool
spring
boot
start.
We
now
have
spring
boot
starters
yay
munir,
so
these
are
cool.
I'm
totally
recommend
you
know
if
you
have
any
spring
people
or
you're
into
the
interested.
Try
them
out,
give
us
feedback
and
then
yeah.
H
Yeah,
so
I'm
thinking
about
writing
like
a
medium
article,
like
as
my
internship,
starts
wrapping
up
in
the
past
in
the
next
like
two
three
weeks,
and
I
also
like
plan
on
including
documentation.
Right
now,
I
have
like
one
readme,
that's
kind
of
stale,
so
I'm
gonna
like
update
that
and
add
a
couple
more
readmes.
A
Yeah,
I
think
that's
going
to
be
a
popular
one
and
we've
got
these
last
two
were
contributed
by
frank
spidoltski,
so
it's
great
to
see
new
faces
joining
and
contributing.
A
So
now
we
support
some
new
http
semantic
attributes,
flavor
user
agent
and
client
ip
from
the
x
forwarded
by
kind
of
for
headers,
and
then
we've
got
he
also
added
new
propagators.
So
we've
now
got
ot
tracer.
A
I
assume
this
is
the
open
racing
format.
I
don't
actually
know
what
that
is
and
x-ray
and
then
just
last
night
I
recorded
the
with
steve
flanders
from
splunk
and
the
collector
group.
The
kubecon
eu
talk
that
showcases
the
collector
plus
the
java
auto
instrumentation.
So
we
talked
about
those
respective
pieces
and
then
steve
had
a
really
nice
demo
pulling
them
all
together
and
and
showing
it
end-to-end
and
I'd,
say
the
one
things
that
don't
continue
to
go
well.
A
Sporadic
test
failures
continue
to
plague
us
and
nikita's
concern
about
you
know.
Ga
readiness
is
I'd,
say
the
other
very
good
thing
to
escalate
as
a
concern.
A
Hey
that
only
took
me
eight
minutes
any
happy.
We've
got
two
minutes
left
till
our
five
minute
cut
off.
So
any
any
questions
about
any
of
these
things.
Any
other
topics
on
your
mind,
uh-oh.
We
only
have
one
minute
now.