►
From YouTube: 2021-03-31 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
Sorry
about
changing
daylight
savings.
I
never
thought
about
the
global
implication
of
of
shifting
daylight
savings
by
two
weeks.
A
I
very
much
enjoy
it
personally,
because
I
much
prefer
daylight
savings
time
have
some
doesn't
get
dark
at
you
know
4
30
or
5
30
at
night
anymore.
C
B
B
A
So
I
don't
know
what
I
threw
a
couple
of
open
pr's.
We
can
chat
about,
but
any
bigger
topics
on
your
mind.
B
I
think
I
have
one
one
topic
is
again
the
very
same
vendor
distribution
stability
that
I
mentioned
on
slack,
so
that
specific
issue
was
more
or
less.
B
Well,
hdk:
auto
configuration
module
so
first
question,
but
we
don't
have
john
here
so
first
question
to
honor
what
plans
about
our
configuration
stability,
indians.
I
have
read
to
slack
and
the
second
question.
We
have
something
agent
right
now
which
influences
vendor
distribution.
I
don't
remember
from
top
from
from
top
of
my
head.
If
we
have.
C
A
A
Instead,
I
mean
okay,
oh.
C
A
So
we
have
these,
but
these
are
pretty
advanced.
I
would
think
for
customers.
B
Yeah,
do
we
need
them
in.
A
A
Oh
we're
right:
we
kept
them.
I
think
we
kept
them
around
until
we
get
rid
of
the
exporter
jar.
A
A
Cool,
so
I
mean
nikita:
are
you?
Do
you
think
we're
good
with?
Do
you
think
any
of
these
things
need
to
be
stable.
B
C
I've
been
considering
moving
that
sdk.
I
think
it
is
a
good
idea
that
would
be
one
way
to
try
it
artifact.
B
C
C
C
B
What
are
our
like
criteria
for
stabilizing,
so
they
are
advanced.
Okay.
We
are
reluctant
to
claim
to
declare
them
stable,
yet,
okay,
but
what
has
to
happen
for
us
to
be
comfortable
to
declare
them
stable.
B
B
A
C
C
One
thing
I
would
consider
like,
for
example,
this
bike
body
agent
customizer.
If
something
changed
our
agent
and
it's
just
not
possible
for
us
to
support
them
in
a
backwards
compatible
way.
Anyways
like
it
seems
a
bit
too
into
the
details
for
us
to
really
be
comfortably
maintained
for
a
long
term.
That's
one
sense
I
have
these
are
really
just
providing
implementation
details.
I
think
they're
not
really
apis
in
some
sense.
A
Another
thought
on
here
honorary
had
mentioned
this
idea
before
about
turning
all
of
these
into
more
of
like
an
agent
builder
pattern,
where
you
would
just
at
pre-main,
you
would
in
your
distro.
You
would
build
up
your
agent
distro
build.
You
know
to
set
the
different
hooks
as
opposed
to
basically
similar
hooks,
but
not
relying
on
spi.
A
B
B
Well,
the
benefit
is
the
stability
for
end
users
for
vendor
distribution
click,
creator
that
when
they
upgrade
from
version
x
to
version
x
plus
two,
they
they
don't
have
a
breaking
build,
or
at
least
they
have
breaking
bill.
Compile
time
not
run
time
like
when
we
remove
that
tracer
customizer
that
essentially
worked
fine,
compile
time
to
some
time,
then
bro
or
nonsense.
B
A
A
That
functionality
is
in
the
auto
configure
yeah.
I'm
not
always
just
wondering
like
these
feel
to
me
not
like
things
that
end
users
would
be
using
and.
B
A
B
Vendors
yeah
so
well,
I
don't
know,
I
mean.
B
Yeah,
for,
for
example,
we
have
that
currently
we
have
like
instrumentation
specific
classes
in
java
agent
api,
because
we
want
to
load
them
into
bootstrap
cloud
class
logger,
and
so
we
had
this
idea
that
we
used
bootstrap
packages
for
a
provider
to
allow
specific
instrumentations
to
say
this.
This
package
should
live
in
bootstrap
class
log
and,
if
I'm
not
mistaken,
the
that
doesn't
work
at
the
moment,
but
the
point
being
that,
if,
if
vendor
adds
its
own
distribution,
they
could
want
to
use
bootstrap
packages,
provider.
A
A
Between
the
vendors
monitoring,
vendors
and
end
users,
the
end
users
are
the
ones
that
I'm
worried
about
breaking.
A
A
B
B
A
Okay,
how
users
is
our
support
mechanism
for
plugging
into
what
most
users
will
want
to
customize
in
the
java
agent?
They
want
to
add
span
exporters.
They
want
to
change
the
propagator.
They
want
to
do.
Okay,.
A
Let's
see
what
those
let's
wait
for
those
use
cases
to
kind
of
bubble
up,
and
I
mean
I
agree
if
there's
a
use
case-
that
you
know
we
see
hey,
this
person
wants
to
write
this
instrumentation.
They
want
to
do
this,
then
you
know
we
can
provide
probably
a
better.
We
probably
should
provide
a
better
api
for
them
in
that
case
than
this
kind
of
hacky
api.
B
B
What
our
next
steps-
okay,
instrumentations
and
telemetry
data-
is
still
waiting
for
specific
to
stabilize
the
notion
of
tale
of
telemetry.
So
we
are
waiting
on
that
and
we
are
working
on
instrumenters
api
for
authors,
okay,.
B
A
A
A
B
B
B
C
C
C
Implementation,
wise,
I
don't
think
users
should
have
to
do
it,
though,
like
this
might
involve
the
spec,
of
course,
but
by
getting
a
proper
way
of
allowing
users
to
exclude
urls
from
tracing.
I
think
it's
a
very
important
feature
to
have,
because
everyone
complains
about
their
health
checks
showing
up
all
the
time.
C
C
C
B
B
B
Hopefully
I
mean
my
usual
mmo
is
that
I
I
hate
I
hate
graveyards
in
backlog,
so
if
we
think
that
we're
not
going
to
do
that
or.
B
B
B
A
Yeah
like
say
something
like
this,
I
mean
it's
a
nice
idea.
I
thought
I
had
to
like
close
it
like
saying
like
no.
C
A
Is
not
a,
but
I
doubt
that
anybody
any
of
the
existing
contributors
here
would
pick
that
up.
For
example,.
B
C
B
A
A
A
B
Work
for
me
either
way.
B
A
For
at
this
meeting,
I
think
we
were,
we
did
have
a
lot
of
sdk
stuff
in
this
meeting
for
a
while,
because
the
1-0
there
was
a
lot
going
on,
but
I
think
that
we're
probably
back
to
mostly
instrumentation
stuff
in
this
meeting
so
probably
would
be
a
good
issue.
Triage
touch.
B
B
C
B
A
Instrumentations
cool
honorary
you
were
mentioning
last
thursday,
a
discussion
you
are
having
with
ted.
C
So
we
were
talking
a
bit
about
potentially
having
distributions
like
aws
dispersed,
even
spawn
for
some
vendor
distributions
actually
published
by
open
telemetry,
also
so
that
they're
all
in
one
place
for
to
make
sure
users
don't
get
confused
like
where
to
file
issues
and
whatnot
like
it
wasn't
a
very
well
baked
talk
or
anything,
but
he
was
suggesting
that
it
might
be
a
good
idea
so
that
users
don't
end
up
going
downstream
and
disappear
from
open
telemetry,
and
so
that
seems
like
sort
of
an
okay
idea.
Of
course
it
contributes
to
infinite
repository
growth.
B
B
But
to
separate
from
from
that,
what
I
wanted
to
talk
in
the
context
of
this
document
as
well
is
what
do
we
want?
I
mean
how
we
want
to
solve
the
problem
of
almighty
god
repository.
B
B
C
C
B
The
problem
with
that
is,
if
we
still
want
to
support
the
use
case
of
one
mono
agent
with
all
implementation.
That
means
that
we
have
to
have
all
of
them
hosted
somewhere
by
us
and
that's
another
bro
problem.
For
example,
I
don't
want
to
support
that.
I
don't
know
apache
dubo,
instrumentation
and
care
about
latest
dependencies
and
and
whatnot
or
eric
previous
versions,
which
were
released
five
years
ago,
or
at
least
not
every
day
I
mean.
C
A
So
nikita
it
sounds
like
the
the
divider
or
the
question
you're
asking
is
basically
trying
like.
Can
we
decentralize
the
repo,
even
the
repos,
not
under
hotel,
like
if
somebody
want
like
for.
B
B
C
Because
we
can
also
like
other,
for
example,
the
couch
base.
They
can
only
have
library
instrumentation,
but
they
could
also
easily
publish
an
instrumentation
module
as
well
for
inclusion
into
the
agent.
So
we
could
push
the
ownership
of
that
module
down
and
still
depend
on
it
and
use
it
in
our
binary.
C
C
B
B
B
That's
one
way:
that's
one
way
to
solve
it,
so
certainly
it's
some
somewhere
in
between
in
the
middle
between
our
current
monograph
and
user
class
pass
scanning,
in
my
opinion,
so
that
certainly
will
be
the
first
step.
B
That
may
not
work
in
all
cases
like
yeah.
Probably
we
will
not
support
we,
at
least
in
the
beginning,
the
packaging,
those
into
war
files,
for
example-
maybe
not
because
that
brie
brings
a
quick
question.
If
one
war
file
have
configured
instrumentation
for
some
common
library,
how
do
we
guarantee
that?
B
Yeah,
so
that's
certainly
one
way
to
do
it,
and
the
other
is
just
saying
sorry
that
will
work
only
if
you
have
like
one
scope,
which
is
your
your
jvm.
We
don't
support
multiscopes
like
war
files
or
ear
files.
That
is
okay,
I
think,
and
as
well
as
long
as
we
have
that
fallback
mechanisms
like
extensions
or
just
build
your
leg
yourself.
A
B
B
So
these
are
all
cool
cool
ideas
and
I
think
we
should
explore
them.
But
again,
the
question
is
what
we
as
a
maintainers,
think
of
is
the
best
way
or
it
is
the
best
first
steps
to
do.
Do
we
still
want
to
have
that
mono
even
have
everything
under
our
control
we
want
to
decentralize.
I
certainly
do
do
we
want
to.
A
Yeah
I
mean
take,
for
example,
the
read
like
the
the
quit
instrumentation.
A
I
mean
that
the
option
would
be.
I
mean
it's
definitely
the
useful
right.
I
mean
there's
definitely
people
but
with
the
if
we
didn't
host
it
in
our
repo
I
mean
like
splunk
could
host
it
in
their
repo
and
we
could
direct
people
to
splunk
for
that.
Instrumentation.
B
B
C
Like
glass,
like
we've,
I
mean
I
will
say:
splunk
has
added
a
ton
of
instrumentation
lately,
but
most
of
them
are
the
type
where
I
don't
really
even
expect
those
to
get
natively
instrumented
ever
so.
C
B
B
Well,
yeah,
so
in
that
particular
case
we
we
I
mean
splunk
edited
that
which,
which
means
that
yeah
we
have
to
support
that.
If
we
have
our
reasons
to
have
that
instrumentation.
So
we
have
our
recent
reasons
to
support
it,
as
as
as
long
as
exactly
or
as
long
as
or
especially.
If
this
particular
versions
are
used
by
our
customer,
then
we
will
support
that.
Then
yeah.
B
C
B
Think
that
if
I
could
choose
that,
will
not
okay,
my
manager
probably
will
not
agree
with
me,
but
I
wouldn't
want
to
have
that
in
open
telemetry
java,
instrumentation.
B
A
C
C
C
B
C
And
if
someone
hosts
their
own
instrumentation,
we
decide
whether
we
add
it
to
our
mono
jar
or
our
build
tool
or
whatever
it
is.
We
provide
based
on
whether
it
seems
official
or
unofficial
or
the
quality
or
whatnot.
We
would
have
that
checked
there,
but
like
if
it's
an
official
thing,
if
couchbase
publishes
their
instrumentation.
Of
course
we
use
it.
I
think,
after
confirming
the
quality
because
they're
the
authors,
if
it's.
B
Yeah,
I
I
think
that
is
by
the
way
it
can
be
sourced
fairly
easily
and
to
open
telemetry
satisfaction
that
basically
process
the
part
of
inclusion
in
open
telemetry
registry
and
then
for
us.
If
it's
opened
elementary
registry,
we
can
query
that
and
put
and
take
whatever
there
is
into
almighty
god
java
agent
file,
so
waiting
is
already
done.
First,
yeah
yeah,
that's
a
good
point.
Yeah
probably
we
are.
We
are
going
to
do
that
waiting
for
java
instrumentation,
but
still
that
is.
B
Registered
so,
but
do
I
hear
you
correctly
that
you
are
okay
with
the
idea
that
open
telemetry,
java
instrumentation
repo
contains
only
tier
one
instrumentation
that
we
maintain
and
support?
B
C
C
C
C
A
I
don't
know
where
it
went
back
up.
Maybe
we
have
removed
that
already.
A
Yeah
I
mean
this
was
at
the
time
my
my
thoughts.
C
B
But
yeah,
but
at
least
my
vision
from
that
right
now
is
that
should
be
the
collection
of
independent
instrumentation
right
now
we
have
at
least
that
instrumentation
gradle,
which
it
still
brings
all
together,
and
you
cannot
actually
work
with
separate
pieces.
Mostly.
Oh,
it's
like
a
little
bit
complicated
so
that
that
repo
can
have
mostly
separate
projects.
We
provide
tooling
for
like
tasting
the
muzzle
so.
B
A
A
C
C
To
figure
out
whether
this
reactor
and
any
scope,
weak
thing
is
actually
caused
by
this
pr
or
just
flakiness
that
I'm
hitting
or
something
as
I
was
debugging
reactivity.
I
realized
that
most
of
our
http
client
tests
don't
actually
test
asynchronous
callbacks
and
most
of
them
just
call
the
callback
in
the
caller
thread
for
some
reason.
So
I.
C
And
I'm
going
to
first
refactor
all
the
http
client
tests.
We
have
right
now
so
separate
things
can
sink
properly,
like
ones
that
don't
support
ace.
We
just
wouldn't
run
them
with
callbacks,
there's
no
point
and
the
ones
that
do
they
actually
run
callbacks
like
even
the
reactor.
If
you
look
at
the
reactor
netting,
that's
just
calling
call
back
with
the
color
thread
after
doing
the
blocking,
so
that
doesn't
test
anything
yeah.
C
A
Cool
yeah,
I
mean,
if
you're,
asking
for
next
steps
nikita
it
feels
like
we
keep
finding
plenty
of
like
really
important
foundational
issues
to
tackle
so.
A
C
A
Called
out
the
great
all
groovy
madness
on
one
of
anurag's.
A
C
A
C
A
A
C
B
C
And
he's.
C
A
B
Sorry
nikita
well
mateos
was
converting
some
parts
of
to
java
as
well.
No.
A
Not
very
pretty
I
th
the
groovy
the
assertions,
the
span
assertions
are
very
pretty
I
do
like
those,
but.
A
C
C
Nah,
that's
our
gradle.
Ships
are
so
annoying,
so
they
far
less
motivated
than
other
repo,
but
like
cradle,
has
their
own
mechanism
for
converting,
actually
like
a
java
consumer
into
something
that
then
you
can
just
operate
on
with
this,
but
that's
not
a
copy
features.
You
always
need
the.
I
t
I
t
dot
whatever
okay,
which
is
not
as
nice.
A
But
it
wasn't
working,
but
yes,
I
can.
I
can
mess
around
with.
C
For
some
reason
for
executive
instrumentation-
that's
okay,
but
I
think
it
does
sometimes
like
the
context
for
these
cases,
because
it's
not
these
reactivities
have
so
many
executors
involved.
You
can
instrument
the
wrong
when
you're
dead,
so
hopefully
something
will
get
much
better.
Once
you
fix
this,
we'll
see.