►
From YouTube: 2020-12-09 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
B
C
D
C
C
E
E
Where's
where's,
our
fearless
leader,
trask.
A
E
So
I
guess
it's
worth
talking
about
kind
of,
maybe
the
I
don't
know.
If
conclusion
is
the
right
word,
but
discussion
this
morning
at
the
spec
meeting,
where
I
it
was
seeming
like
more
and
more
people
were
convinced
that
version
locking
across
all
artifacts
was
not
really
viable.
E
E
E
I
would
much
prefer
to
have
the
same
version
for
everything
I
don't
feel
like.
Our
sdk
is
currently
in
a
state
where
we
would
be
able
to
release
it
like
in
a
week
or
two.
I
think
we've
had
some
work
to
do
on
cleaning
up
making
sure
that
the
public,
what
is
public,
should
be
public
and
that
we
don't
have
some
public
references
lying
around
that
people
will
then
get
access
to
and
use
when
we
don't
want
them
to.
D
D
D
E
B
B
F
My
where
I'm
feeling
right
now
also
is
that,
if
to
keep
them
in
lock
step,
that's
going
to
be
really
limiting
for
the
sdk,
and
I
could
see
you
know
in
a
year
we
want
to
bump.
You
know,
break
some
stuff
in
the
sdk,
but
but
we
don't
want
to
bump
the
api.
I
E
We
aren't
required
to
have
breaking
changes
in
the
api.
At
that
point
I
mean
people
might
assume
there
were
breaking
changes,
but
there's
no
requirement
in
december
that
if
you
made
your
version
change
that
there
must
be
breaking
changes
in
every
component
right
if
we
view
it
as
one
larger
component
and
we're
breaking
changes
in
the
sdk,
we
can
still
say
that
version
two
works
with
version.
One
of
the
api.
I
So
the
only
thing,
the
only
thing
that
is
strange
a
bit
so
we
have
to
follow
some
specs
and
specs-
will
be
one
point,
something
and
us
getting
to
the
api
version.
Let's
say
10,
but
we
still
work
on
on
specs.
One.
E
C
C
E
C
E
Yes,
ish,
but
there's
a
big
difference
between
saying
that
the
the
sdk
configuration
is
locked
and
that
we've
defined
the
sampler
api
that
you
have
right,
that
we
can
make
a
distinction
here,
and
this
is
where
I'm
trying
to
figure
out
like.
What's
the
public
surface
of
the
sc
of
the
sdk,
and
how
do
we?
How
do
we
like
enforce
that.
I
Okay,
I
I
would
suggest
that
for
the
public,
we
start
to
make
a
list
of
what
we
consider
the
powerful
service,
because
I
think
this
is
a
lacking
thing,
even
in
the
specs
and
even
intel's
document.
What
is
on
the
sdk?
What
we
consider
api
and
we
consider
that
we
need
to
guarantee
compatibility
and
stuff.
E
Right,
yeah
well,
there's,
but
there's
a
couple:
different,
sdk
apis
and
different
classes
of
them
right,
there's,
like
extension,
points
like
samplers
and
exporters
and
eventually
views
and
things
like
that.
But
then
there's
the
configuration
api,
which
is
not
really
an
extension
point.
That's
something
that
you
use
to
start
up
your
app
or
set
up
your
app
configure
your
application.
C
C
D
E
Like
I
think,
maybe
we
say
like
sdk
extension
interface
call
it
the
the
sei.
The
sei
is
what
you
like
the
thing
that
we
would
publish
and
say
this
is
the
point.
These
are
the
extension
points
we
support
right
like
export
right
now.
It's
just
exporters
and
spam
processors
and
samplers.
E
I
need
generators
slightly
different
okay,
but
I
mean
I
get
your
point
I
get.
I
mean
I
get
to
get
the
point,
I'm
trying
to
figure
out.
It
feels
slightly
different,
because
it's
a
thing
that
well,
I
guess
the
ap
api
is
really
simple.
Also,
so
id
generator
is
a
good
good
example.
Possibly
resource
is
a
resource.
A
part
of
that.
E
Yeah
there
is
a
resource
provider
spi
for
resources.
Absolutely
and
resource
is
a
public.
It
is
a
public
api.
It
I
mean,
there's
not
very
much
that
you
have
to
be
able
to
do
to
be
a
resource.
E
Well,
maybe
it's
just
that
there
is
a
so
you
don't
have
to.
You
can
create
resources
using
the
static
class
or
the
abstract
class
and
the
the
methods
we
provide
around
it,
creating
it
from
attributes.
D
E
E
C
E
E
E
D
D
Yeah
so,
but
so
that's
that's
exactly
the
point
it
see.
I
I
heard
during
those
discussions
like
semantic
conventions,
should
be
more
or
less
same
stable
as
the
api
in
the
sdk,
which
is
certainly
not
the
case
and
for
our
instrumentations.
It
will
not
be
the
case
for
a
long
time.
C
D
D
C
D
E
C
B
D
D
That,
with
that,
we
shouldn't
have
public
enum
class
with
semantic
attributes
and
just
use
strings
in
auto
instrumentation,
because
that
reduces
our
public
service
yeah.
But
even
even
in
this
case,
if,
if
it's
not
public
class,
just
public,
it's
just
strings
and
instrumentations,
can
we
stop
sending
them
or
remove
them?
I
I.
D
No,
but
but
but
but
that's
a
problem,
because
I
I
I
mean
that
the
question
is:
is
telemetric
data
and
semantic
convention,
as
part
of
the
versioning
is?
Is
it
version
using
the
same
strict
rules
as
api
and
sdk?
No,
it's
not,
then.
What?
What
are
those
rules.
E
I
don't
remember,
but
the
semantic
conventions
are
currently
part
of
the
api
card
of
the
spec
and
they'll
get
released
with
like
when
they
I'm
sure
the
spec
will
get
updated
and
released
with
different
versions
of
semantic
conventions.
I
mean
we're
generating
all
that
all
of
them
right
now
out
of
the
ammo.
C
E
Yeah
ted
definitely
has
asserted
that
he
does
not
want
to
break
want
to
remove
semantic
conventions,
although
he
he
says
it's
okay
to
deprecate
them,
but
has
also
commented
in
that
otep,
or
at
least
there's
been
a
little
bit
of
discussion
that,
like
nikita,
was
saying
if
telemetry
data
out
of
instrumentation
changes
that
that
should
be
considered
a
breaking
change,
but
I
don't
know
what
that
I
don't.
Actually
I,
as
I
have
commented
on
that
otep
I
don't
know
what
it
means
like.
I
don't
know
how
to.
E
H
I
D
E
D
Well,
that's
user
change,
the
telemetry!
We
don't
care.
I
don't
care
about
that
at
the
moment.
My
question
right
now
is
what
we
as
auto
instrumentation
maintainers,
are
allowed
to
do
with
telemetry
data
and
semantic
connections,
specifically
what
we
are
allowed
to
to
do
without
considering
that
a
breaking
change.
C
I
would
say
we
support
as
much
of
the
spec
as
we
can
like.
Of
course,
it
can
only
be
partially
compliant
based
on
our
engineering
resources.
Once
we
support
respect,
we
wouldn't
want
to
unsupport
it.
That
seems
fine
to
me.
Okay,
so,
and
so
I
mean
implement
it
as
defined
on
the
spec
document.
Whatever
that
says,
yeah.
D
So
you
are
saying
that
what
is
the
specified
inspect
semantic
condition
wise?
We
implement
that,
taking
into
account
that
the
majority
of
attributes
are
optional,
so
we
are
not
required
to
provide
them
as
as
much
as
we
can
or
want,
and
what's
not
in
the
spec
we
well
free
to
do
whatever
we
like.
That's
why
we
don't
want
to
have
too
much
like
free
range
attributes,
yeah.
F
I
yeah
so
my
thoughts
are
that
you
know
we
can
add
stuff
kind
of
similar
to
api.
We
can
add,
but
not
remove,
and
because
of
that
for
makes
me
think
about
the
instrumentation
specific
attributes
that
we
have,
that
aren't
in
the
spec
makes
me
lean
more
towards
removing
it
like
hiding
all
of
those
behind
an
experimental
flag,
so
that,
since
we
basically
know
that
those
are
you
know,
like
our
kafka,
random
kafka
attributes.
F
I
The
other
thing
by
the
way,
the
other
thing
that
we
have
on
the
telemetry
data
is
the
instrumentation
version
instrument.
We
have
an
instrumentation
library,
name
and
instrumentation
library
version.
So
even
though
we
may
do
breaking
changes,
the
backhand
can
determine
the
word
the
name
on
in
the
version
some
of
these
and
handle
some
of
these
things.
D
D
D
E
D
E
F
So
one
concern
I
have
about
setting
all
of
the
instrumentation
to
the
same
version
is
like
all
the
library
that
means
that
all
of
our
library,
instrumentation
will
need
to
be
at
again
at
a
level
where
we
aren't
going
to
need
to
break
it
forever
for
a
really
long
time,
which
means
which
is.
F
That
would
help
the
the
that
other
repo
that
would
still
need,
I
mean
all
of
those
things-
will
still
need
to
be
versioned
and
potentially
independently,
but
yeah
that
would
help
it's.
It's
a
lot
of
work
going
across
the
the
80
instrumentations
right
now.
I
But
I
think
I
think,
from
instrumentation
perspective,
you
have
couple
of
interfacings
and
stuff
that
you
expose,
which
requires
to
be
backwards
compatible
and
stuff,
but
you
also
have
the
version
of
the
library
that
you
instrument
consideration.
So
I
don't
know
how
how
you're
going
to
handle
that.
So,
for
example,
if
you
are
instrumental
in
vrpc
and
prpc
moves
with
this
certain
speed
and
they
don't
respect
some
of
the
same
guarantees.
What
you
do.
D
J
I
D
Right
now
like
like
soonish
yeah,
but,
but
why
this
is
a
problem,
it's
it's
like
for
us,
it's
just
adding
new
instrumentation
or
adding
new
version
support
like
any
other
additive
change.
I
No,
no,
let
me
explain.
Let's
assume
this
culprit
is
grpc,
for
example,
and
everyone
is
using
and
the
latest
and
I'm
using
grpc
1.2
in
my
app
and
in
the
latest
instrumentation
your
instrumented
grpc
1.5
in
between
them
are
it's
a
very
breaking
incompatible
chain.
I
E
F
In
our
artifact
name
already,
and
so
when
there's
because
we
have
like
apache,
http
client,
two
zero
and
four
zero
different
instrumentations.
D
F
But
but
we
still
have
to
have
to
be
very
like
are
we
gonna?
If
we
need
to
break,
say
something
we
would
need
to
bump
the
whole
instrumentation
repo,
a
major
version.
I
F
Yeah,
so
we
have
the
instrumentation
api
artifact,
so
this
is
sort
of
our
api,
but
then
each
one
of
the
library
instrumentations
has
its
own
public
api
right
for
users
to
integrate
it.
So
that's
those
apis
are
spread
across
a
lot
of
different
instrumentations
and
they're.
Not
they
don't
tend
to
be
that
big.
I
I
I
don't
know,
I'm
I'm
I'm
trying,
but
all
of
them
are
implementing
a
kind
of
a
factory
method
which
is
returning
like
a
generic
team
and
and
all
of
them
are
accepting
all
the
properties
that
you
can
pass
through
to
any
instrumentation.
So
you
have
an
implementation,
api
and
instrumentation
configuration
and
all
of
the
artifacts
are
implementing
a
factory
pattern
that
gets
a
common
configuration
all
of
them
and
returns.
Whatever
object
requires
that
I
I'm
brainstorming,
I'm
just
thumping
ideas.
I
I
don't
think.
F
C
F
It's
totally
doable,
it's
there's,
no
there's
no
magic
there.
It's
just
like
the
the
same
exercise
like
that.
You
all
have
been.
F
D
I
F
I'm
just
worried
about.
We
find
something
in
one
of
the
instrumentation
libraries
that
we
want
to
break
need
to
break
for
some
reason
and
that
that
forces
us
to
bump
our
entire
instrumentation
repo
major
version.
I
I
also
think
you
shouldn't
be
worried
to
not
follow
simba.
I
was
keep
pointing
to
ted
and
to
the
to
the
versioning
meetings.
That
assembly
is
critical
for
for
artifacts.
That
may
be
transient
dependencies
correct,
like
the
the
problem.
The
the
biggest
problem
is
when
your
artifact
that
you
are
publishing,
maybe
independent.
I
D
I
Think,
in
marching
case,
the
expectation
is
there
is
no
such
thing
as
auto
instrumentation
at
all.
Like
you
just
put
smooth
and
that's
it
you
don't
put
any
other,
you
don't
install
or
any
other
instrumentation.
For
example.
I
expect
that
what
slu
does
is
they
depend
on
on
some
sort
of
http
or
whatever
plugins
you
have,
and
they
are
there.
A
E
Last
week
he's
using
both,
I
don't
remember
what
they're
called
you
have
an
http
client
something
and
an
http
server
or
something
yeah
he's
extending
both
of
those
classes.
I
G
C
Think
also
sleuth
has
gone
that
far
with
hotel,
but
and
sleuth
implements
its
brave
support
by
importing
the
brave
instrumentation
modules
and
just
setting
them
up
if
their
user
has
that
library
on
the
class
path,
similar
to
what
our
agent
does.
So,
I'm
pretty
sure
salut
is
also
going
to
do
that
with
open,
telemetry
library
instrumentation.
C
I
I
I
think,
I
think,
by
the
way,
I
think
there
has
to
be
a
separate
meeting
only
for
that
for
for
deep
discussion
with
instrumentation.
I
I
think
you,
you
will
have
a
big
problem.
F
And
can
you
be
more,
what
do
you,
what
are
you
suggesting
a
meeting
for
bogdan.
I
I
mean,
I
think
I
think
somebody
has
to
take
a
step
and
and
define
this
instrumentation
api
and
work
on
that.
Instrumentation
api
that
includes
factory
methods
or
factory
patterns
includes
configurations
includes
everything
that
you
want,
so
that
every
plugin
publicly
will
expose
the
same
interface.
So
every
plugin,
every
plugins
public
api
will
be
the
same,
will
be
something
that
you
define
in
instrumentation
api
to
avoid
to
avoid
mistakes.
I
F
Yeah,
all
of
these
things
always
sound
good
in
theory,
until
we
hit
the
80
different
instrumentations
and
find
all
the
corner
cases,
but
that's
the
work
that
we
need
to
do.
I
F
Yeah,
so
that
the
the
thing
that's
right
now,
the
big
part
is
so
if
people
want
to
customize
the
telemetry
that
is
produced
by
them,
the
plugins.
F
D
I
mean,
if
I'm
not
mistaken,
and
I
may
be
mistaken
when
I
did
that
exercise
recently
about
how
can
we,
how
can
external
person
tweak
instrumentation
they
telemetry
data
that
we
produce?
I
don't
believe
that
tracer
subclassing
one
one
of
the
viable
options,
because
you
cannot
just
surplus
tracer.
F
D
Want
but
I'm
still
totally
convinced
that
these
these
parts
that
currently
produce
our
semantic
convention,
like
on
request,
is
certainly
not
like
publish
it's.
It's
not
ready
to
be
stable
yet
and
for
a
long
time,
so
that
anyway
open
question
for
for
for
us.
But
then
you,
you
don't
go
to
one.
I
F
We're
not
talking
about
going
to
one
zero
cool.
You
guys,
the
the
api
and
sdk
are
we're.
We're
we're
definitely
lagging
a
few
months,
two
or
three
months
I
would
say
at
least
I
I.
I
D
A
I
F
I've
got
a
pr
waiting
for
nikita
to
review
right
now
that
I'm
restructuring
these
right
now,
but
then
I
go
out.
I
do
this,
and
nikita
gets
mad
at
me
for
not
doing
other
work
in
the
java
agency.
D
F
I
Anyway,
I
think
if,
if
that's
the
case,
it's
probably
premature
of
talking
about
version
thinking
and
stuff,
we
we
can
talk
about
this
once
majority
of
your
code
is
version
one
something
and
we
may
do
it.
One
moment
say:
let's
say:
api
sdk
will
be
at
1
15
and
you
you
become
one
four
and
we'll
say:
okay,
let's
next
release,
we
do
both
of
projects
116
just
to
sync
the
versions,
even
though
that
skipping
minor
version
is
an
unnecessary
cement
sensor
compatible,
but
I
think
we
are
allowed
to
do
that.
F
That's
that's
what
a
marching
is
been
putting
pressure
on
us
for
that
recently
also,
which
is
why
I
started
going
back
into
it.
F
I
D
So
what
once
again,
I
I
ask:
what
is
our
public
api
services?
Is
that
only
instrumentation
api,
or
we
somehow.
D
Put
telemetric
data
as
well
into
it.
I
would
not
consider
that
yet.
E
J
I
Apis
is
more
important,
because
apis
will
break
your
app.
You
will
not
be
able
to
compile.
F
But
for
auto
for
auto
instrument
for
java
agent
users,
there's
no
api.
E
I
think
it
is
really
important
to
delineate
not
only
for
java
but
probably
across
other,
although
all
the
languages
in
the
sdk
specification
like
what
the
officially
supported
extension
points
are
and
like
what
the
guarantees
are
that
we're
going
to
provide
around
those
extension
points
and
then
there's
the
second
piece
of
the
sdk,
which
is
the
configuration
apis
for
the
sdk,
which
I
think
I
think
should
have
a
slightly
should
have
a
lesser,
a
less
strict
guarantees
than
the
extension
point
apis
around
stability,
because
they
are
a
thing
that
should
be
done,
should
be
around
application,
startup
and
configuration.
E
Yeah
absolutely,
but
I
think
I
I
feel
like
that
configuration
story
is
one
that
when
sleuth
decides
to
upgrade
and
has
a
new
version
of
the
sdk
that
they
use,
then
they
go
and
update
their
configuration,
and
likewise
when
the
agent
goes
and
updates
the
version
of
sdk
that
it
uses
it
update,
updates
this
usage
of
that
configuration
as
well
like
it's
something
that
that
isn't
going
to
come
in
that
isn't
like
there.
I
About
salute
if
they
don't
have
enough
releases
at
one
point,
we'll
release
a
new
feature:
that
user
really
wants
and
is
working
on.
Two
three
versions
behind
and
people
will
go
and
tweak
their
palm
xml
or
gradle
to
use
flute
1.5,
which
depends
on
our
sdk
api
1.4,
and
then
they
manually
put
the
jars
for
1.7
or
1.8
or
hotel,
which
will
break
the
entire
thing.
Is
that
something
that
we
we
support?
Maybe
we
just
say
you
know
what,
if
you
use
loot,
you
cannot
manually,
add
new
versions
or
whatever
I
know.
E
Yeah
I
mean
I,
I
think
that's
reasonable.
We'd
have
to
get
obviously
the
sleuth
folks
and
marching
to
buy
off
on
that.
F
Just
about
the
sd
having
a
less
strict
guarantee
that
would
you
still
follow
semver?
Would
you
then
bump
it
to
like
if
they're
wet,
because
I
think
it's
I,
I
think
it's
fine
to
have
a
less
strict
guarantee,
but
I
also
think
that
it's
important
to
still
bump
to
200
if
there's
breaking
changes
on
that
artifact,
just
as
a
signal
to
people.
F
So
in
that
case
you
know
I
would.
I
think
I
would
want
the
s.
You
know
that
part
of
the
ap
that
sdk
configuration
artifact
to
be
bumped
to
2-0.
E
E
I
mean,
but
I
think,
if
we
go
down
that
road
we're
basically
either
locking
ourselves
into
essentially
never
changing
anything
which
I'm
I'm
not
happy
with.
I
don't
think
that's
a
viable
strategy
or
doing
a
lot
of
major
version
revs,
as
we
figure
out
like
how
the
sdk
needs
to
be
configured
in
the
real
world
and
for
use
cases
that
we
haven't
thought
of
yet
because
I'm
sure
there
are
use
cases
we
haven't
thought
of
yet
like
we,
for
example,
osgi
we
have
don't
have
support
for
osdi
right
now.
E
E
Is
you
know
this
is
the
next
thing
I
was
going
to
talk
about?
Is,
I
think
we
would
all
prefer
if
we
didn't
let
our
version
script
apart,
because
I
think
it's
going
to
be
very
confusing
for
users
to
know
like
what
they're
supposed
to
what
version
they're
supposed
to
use,
what
they're
supposed
to
put
in
their
palm
or
what
they're
supposed
to
put
in
their
build
gradle
as
a
dependency.
E
A
I
F
Oh,
I
was
thinking
more
like
library,
like
ins,
libraries,
that
are
pulling.
E
F
Just
thinking
the
bom
version
would
be
the
sdk
version,
because
that
presumably
there
would
always
be
a
new
sdk
version.
C
E
J
Counterpoint,
though,
not
to
get
too
philosophical
at
the
end
of
an
hour-long
call,
but
you
know,
as
a
user
coming
in,
if
you
see
a
thousand
configuration
options
available
to
you,
that's
maybe
not
clear
than
having
a
handful
of.
F
E
Well,
I
think
I
mean,
unfortunately,
I
think
we're
not
going
to
know
like
I
said
people
are
going
to
cook
up
things.
We
we
haven't
thought
of
right,
they're,
going
to
go
down,
paths
that
we
haven't
anticipated
around
configuring.
The
sdk,
like
I'm
sure,
that's
going
to
be
the
case.
We're
not
going
to
be
able
to
avoid
that
and
waiting
a
couple
months
will
just
mean
that
people
won't
use
it
yet
and
then
we're
not
going
to
find
it
until
you
start
using
it.
E
So
I
would
prefer,
like
I
mean,
maybe
we
just
when
we
just
bite
the
bullet
and
say
yeah
we're
going
to
use
sember.
But
what
we're
really
going
to
do
is
we're
just
going
to
stick
it
1.0
and
rev
a
lot
forward
and
never
break
anything,
never
remove
anything
deprecate
aggressively
for
things
we
don't
like
or
we
don't
want
them
to
use.
E
I
F
I've
seen
a
lot
of
I've
seen
a
lot
of
things
getting
removed
over
the
last
month.
A
E
Yeah,
but
there's
definitely
fewer
than
I
thought
there
were
like.
I
expected
there
were
going
to
be
stuff
all
over
the
place
and
it
wasn't
nearly
as
bad
as
I
feared,
but
there's
still
stuff
out
there,
though
I'm
sure
of
it.
This
doesn't
the
only
thing
we
haven't
talked
about
here
tomorrow.
Time,
I'm
out
of
time
is
the
metrics
and
whether
we
move
them
into
a
dash
experimental
module
or
whether
we
do
something
else
and
I'm
not.
I'm
honestly
not.
E
That's
that's.
The
other
option
is
make
it
a
different
version,
but
if
we're
going
down
that
road,
it
almost
feels
like
we
might
as
well
just
bite
the
bullet
in
different
version.
Everything
I
I
don't
know
I
don't
have
a.
I
don't
have
a
great
answer
for
that
one
I
mean
I'm
not
opposed
to
doing
just
a
dash
experimental
and
having
it
rev
along
and
if
it's
tag
is
experimental,
then
it's
experimental
whatever
its
version
is,
but
that
is
a
little,
maybe
a
little
weird.
If
you
you're
thinking
about
sember
strictly.
A
I
C
E
Things
artifacts
that
depend
on
experimental
dependencies,
but
we're
not
gonna.
We
can't
stop
it.
It's
gonna
happen,
yeah
yeah.
No,
it's
also
fair.
It's
also,
you
know
fair,
but
I
think
also
bugged,
into
your
point
about
you
know.
Looking
at
maven
maven
central,
if
we
have
a
whole
bunch
of
scattered
different
versions
of
things,
people
are
also
going
to
be
super
confused
about
what
they
should
be,
how
they
should
be
stitching.
It
together
sure.
I
C
I
For
users,
I
think
alpha
is
the
same
verb
to
convention,
correct,
simpler
to
convention.
E
E
I
Yeah
change
the
experimental
fish
out
there.
I
C
I
E
Cool,
I
will
I
will
amend
my
draft
pr
to
include
this
strategy
and
see
how
it
looks
all
right.
I'm
going
to
go
to
bed.
C
Are
we
good
with
requiring,
so
we
are
good
with
requiring
the
bomb
dory?
I
think
it's
fine,
like
that's
what
my
question
was
about
alignment.
So
that's
a
yes
for
that
right.
So
then
we
can
share
internet
internal
packages
and
that's
a
good
thing.
I
think
we
can't
strictly
require
it
right,
because
people
can
do
whatever
they
want.
It.
I
G
C
C
Yes,
the
global
is
just
I
mean
it's
just
a
food
for
thought
thing
I
mean
I
didn't
have
any
strong
opinion,
but
do
we
find
like
the
only
thing
that
came
to
mind
is
usually
when
you
want
something
you
go
to
that
interface
and
use
a
factory?
C
C
I
C
I
Yeah,
anyway,
everyone
else
please
look
at
these.
What
we
do
is
essentially
put
the
global
and
access
source
on
a
separate
class
than
the
open,
telemetry
interface
itself,
which
is
called
global,
open,
telemetry,
even
the
name.
It
suggests
it's
the
global
thing.
If
you
want
to
use
the
global
thing,
you
use
the
global
thing.
Otherwise
it
has
the
interface
and
use
the
interface
to
do
all
the
operations.
F
I
see
so
there's
not
a
there's,
not
a
global
instance
of
that
interface
anymore.
You
just
get
each
piece
directly
from
the
global
statics.
I
You
can
get
the
global
instance,
it's
you,
you
can
get
each
piece
or
you
can
get
a
global
instance,
because
we
recommend-
and
this
is
somewhere
where
I
would
like
to
review
some
of
the
your
guy
interfaces,
because
I
would
recommend
all
the
configs
and
everywhere
user
can
pass
their
own
entire,
open,
telemetry
class.
I
Yeah,
so
I
think
we
should
have
the
entire
class
pass
around.
So
that's
why
the
global
exposes
filled
the
entire
class
that
also
exposes
shortcuts.
Instead
of
you
saying,
give
me
the
entire
class
then
do
whatever
we
expose
shortcuts,
as
you
can
see
like
exactly
the
same
methods
without
you
calling
yet.
I
I
There
are
other
things
that
we
want
to
do,
but
the
the
major
the
most
important
one
is
global,
initialization
order
and
me
and
I've
had
a
bunch
of
back
and
forward
and
so
far
my
understanding
is.
There
is
a
push
from
you
nikita,
and
I
think
you
are
the
the
bad
guy
here
that
you
want
to
initialize
everything
in
one
place.
I
Bad
guys
are
the
the
products
here
they
want
to
initialize
everything
in
one
place:
okay,
but
the
problem,
the
problem
that
we
have
is
we
actually
have
a
circular
dependencies
between
these
the
circular
dependency
and
is
a
processor
or
exporter,
may
need
the
the
the
tracer
provider
because
they
want
to
create
spans
for
their
own
things.
I
So
now,
if
you
ask
me
that,
in
order
to
create
a
trace,
tracer
provider,
I
need
to
provi,
I
need
to
pass
the
the
spam
processor,
which
also
requires
the
tracer
provider.
I
cannot
initialize
them.
I
don't
know
how,
unless
I'm
resolving
deadlocks
and
another
problems,
but
I
don't
know
how
to
resolve
it.
So
we
have
this
problem
that
I
don't
know
yet
how
to
resolve.
But
I
would
like
everyone
to
think
about
my
thought.
Was
we
have
this
core,
what
we
called
sdk
any
with
no
no
resource
provider?
I
No,
no
like
remote
sampler,
no,
nothing,
just
the
core
piece!
That
does
not
depends
on
itself.
So
that's
the
the
core
piece
that
we
can
always
initialize
first
and
then,
and
then
on
this
corpus
core
part
we
can
decorate
or
we
can
add
all
the
other
things
in
one
shot
in
one
function
for
the
user.
So
from
the
user
perspective,
it's
not
going
to
be
a
builder
pattern
is
going
to
be
a
decorator
or
whatever.
I
We
call
it
pattern,
but
we
need
to
start
with
the
core
piece
first,
because
otherwise
the
other
parts
will
not
be
so
there
is
an
initialization
ordering
problem
that
we
have,
and
I
think
we
are
trying
to
get
to
one
only
one
scenario
or
one
pattern
for
users
to
follow
or
something.
But
it's
not.
It's
not
gonna
work.
The
way
how
you
envision
or
other.
D
I
I
Yeah
we
need
anyway,
I
was
wanting
to
tell
everyone
that
we
have
this
problem.
If
you
know
any
solution
about
this
problem,
let
me
know-
and
the
other
problem
is
that
some
of
the
pro
exporters
may
want
an
instance
of
the
tracer
provider,
but
some
of
them
may
look
to
the
global
insta,
the
global
thing.
So
we
have
we.
What
we
need
to
do
is
initialize
the
corpus
set
it
to
global,
then
start
creating
all
these
components
then
set
all
of
them
in
one
shot.
I
And
the
last
question
about
this:
how
everyone
feels
about
me
doing
a
change
in
the
global
setter.
We
have
a
global
set
correct.
We
have
a
set
a
new
instance
of
the
global.
How
do
everyone
feel
about
me
doing
a
change
to
the
setter
that
only
you
can
set
the
instrumentation
only
once
and
if
you
try
to
set
it
twice,
we
throw
an
exception.
I
Is
it
okay?
The
reason
why
I
want
to
do
this
is
if
by
mistake,
you
call
it
load
initially
and
you
load
the
default
and
you
start
using
the
default
in
some
places,
and
then
you
start
to
configure
the
the
the
global
I
want
you
to.
I
want
to
throw
you
an
exception
to
know
for
you
to
know
that
you
actually
use
up
initialization
you're,
not
gonna,
you're
gonna
have
random
missing
data,
and
I.
I
We
will
handle
detection,
not
an
unhandled
exception,
so
user
will
be
forced
to
handle
it
so
I'll.
I
would
put
a
troll
initialization
hotel,
initialization
exception
or
whatever
I'll
declare
my
own
exception.
The
user
has
to
handle
it.
It's
not
because
it's
happened
only
one
place.
I
don't
care
that
user
has
to
write
a
try.
Catch
and
user
does
whatever
they
want
with
that,
but
I'm
throwing
them
an
exception
and
tell
them
hey.
You
failed
you're
not
going
to
have.
F
C
C
I
found
two
issues,
and
so
that's
what
I've
been
interviewing
on
one
was
that
by
default,
maven
like
sauna
type,
would
automatically
direct
artifacts
it
just
a
couple
of
usually
just
be
jack
saurus.
I
don't
know
why
it
was
consistently
jack
serious.
They
would
create
multiple
staging
repositories
for
one
push
and
but
there
was
a
gradle
plug-in
to
solve
that,
there's
a
plug-in
to
solve
anything.
I
guess
so
after
adding
that
the
build
is
now.
C
It
succeeded
twice
in
a
row,
I'm
excited
because
we
had
20
failures
so
now,
but
the
first
time
it
succeeded,
I
found
our
palm
description
wasn't
set.
I
thought
I
had
compared
the
palm
settings
with
open
tummy
java
sdk,
but
I
missed
the
description
part
and
now
it
finished
the
second
time
it
should
have
the
proper
problems.
I
just
haven't
closed
it.
I
think
it's
gonna
work
this
time
and
then
I'll
post,
something
again
in
slack
but
seems
to
be
working
and
stable
for
now.
So.
F
C
D
D
F
They're
they're
cl
andrag
and
I
discussed
last
thursday.
Sorry
I
should
have
updated
you
that
it
worked
that
it's
close
enough
to
go
to
maven
central.
You
know.
F
What
would
mean
the
group
ids
are
stable
and
most
of
the
artifact
ids
are
stable.
There's
remember:
there
was
one
thing
left
on
that
issue.
F
Yeah,
the
java,
instead
of
having
multiple,
we
have
different
artifacts
right
now
for
java
for
agent
instrumentation,
depending
on,
if
it's
in
the
the
agent
class
loader
or
in
the
bootstrap
class
loader,
and
so
the
proposal
is
to
combine
those
into
one
artifact,
so
that
instrumentation
is
just
simpler.
You
just
pull
in
that
one
artifact
and
then
we'll
split
it
at
build
time.
Yeah.
D
F
So,
let's
how
about
I
will
close
this
one
and
open
a
new
one
just
for
that
last
remaining
text.
F
F
It
will
be
confusing
in
the
same
way
that,
when
the
sdk
renamed
exporters
to
exporter,
we
got
a
couple
of
issues
asking
why.
D
F
We
need
that
just
because
so
yeah
andrag
and
I
discussed
it
in
the
last
thursdays,
asia,
pacific
sig
meeting
and
I'm
sure
I
did
I
I
probably
did
not
take
notes,
and
so
he
wants
to
push
to
maven
central
right
because
of
the
build
the
bin
tray
problems,
publishing
problems
so
and.
C
F
D
F
D
And
and
the
second
problem,
if
I'm
not
mistaken,
we
currently
have
have
released
a
commit
which
is
failing.
Our
tests.
F
Okay,
I
just
mean
from
a
reproducibility
like
you
know
like
we
could
hit,
publish
and
the
second
we
hit
publish
it
might
pass,
but
it
two
seconds
later
it's
going
to
fail.
D
C
Absolutely
so
so
yeah,
I
think
just
tesla
the
steps
got
into
our
master
build
sort
of
randomly
because
he
applied
the
nightly
load
to
it.
I
think
our
original
intent
was
for
test
latest
steps
to
just
be
a
nightly,
build
right,
so
that
doesn't
affect
our
other
builds,
because
it's
annoying
just
out
of
them.
D
The
thing
yeah,
my
problem
is,
is
if
we,
if
you.
D
If
we,
if
you
know
that
test
latest
dab,
can
fail
for
just
time
based
because
a
new
version
was
released
and
we
still,
we
don't
support
that
yet
then
we
really
have
to
pull
that
away
from
our
like
master
build
because
well,
in
my
opinion,
you
cannot
have
version
tag
on
commit
which
has
a
a
red
build.
D
Never
ever
just
by
definition,
you
can.
You
can
remove
failing
tasks
if
you
know
that
they
are
failing
for
totally
separate
issues.
That's
okay,
but
tags
should
be
on
green
on
green
build
always
so
that
means
okay.
Then
we
will
have
to
remove
this
latest
depth
from
master,
build
that
that's
okay.
For
me,
okay,.
F
So
we've
got
open.
Let's
see
we
can
look
at
yeah,
so
you're
right.
We
do
have
three
because
we
have
two
under
java
agent,
so
we
split
out
everything:
that's
java
agent,
byte
code
instrumentation
into
its
own
ones,
and
library
instrumentation
anything
that
people
would
so.
These
are
anything
that
people
would
use
as
a
maven
dependency.
For
the
most
part,
these
are
things
that
people
would
use,
who
are
vendors
or
people
who
want
to
build
their
own
distro
of
the
java.
B
B
F
G
I
Okay,
yeah,
I
I
understand
why
you
have
three
but
very
confusing
for
the
users.
Luckily,
the
manual
instrumentation
users
would
use
only
the
first
artifact
a
group
id
correct,
and
the
others
are
something
that
user
won't
have
to
care.
Users
only
dev
build
other
stuff
can
would
care
about
that
normal
user
would
never
care
about
it.
D
D
F
So
yeah
that
might
be
I'm
trying
to
remember
exactly
what
this
was.
I
mean
it
may
not
actually
change
the
artifact
names
right,
because
it's
just
to
move
the
public
api
parts
of
tooling
into
java
agent
api.
D
D
D
Does
anybody
from
us
have
the
clear
understanding
what
the
intent
of
this
task
and
what
yet
should
be
done
here.
A
F
Tomorrow,
I
can
I'm
sure
I
can
access
that
those
brain
cells
and
remember-
and
I
can
what
I
would
propose-
is
because
this
was
there
was
a
ton
of
stuff
in
here
that
I
proposed
that
I
closed
this
one
and
reopened
a
new
one
with
whatever
is
remaining
here.
F
H
F
I
clearly
thought
that
some
stuff
needed
to
go
away
here,
but
these
are
it's
not
a
massive
number
of
them
and
they're
on
the
java
agent
side,
so
that's
kind
of
where
I'm
comfortable
with
going
going
ahead
and
pushing
to
maven
central.
At
this
point.
F
Okay,
because
there's
bound
to
be
changes
just
like
on
the
in
the
java
repo,
the
api
and
sdk
they've
moved
artifacts
around,
and
you
know
it's
not
ideal,
but
it's
not
the
worst
either.
Okay,.
F
I
think
I
I
oh,
I
owe
you
both
the
next
github
release,
page.
F
All
right,
I'll
trade,
you
all
right,
so
nikita
you're
gonna
review
the
the
tracers
operations
stuff
today.
Let
me
know
thoughts
about
that.
We'll
do
you.
I
agreed
with
your
comment
here
I
started.
Well,
I
I
didn't
agree
and
I
started
to
try
to
move
things
over
and
then
I
didn't
like
how
it
was
going.
So
I
I
think
it
came
out.
I
think
it
I
think
it's
good.
I
wrote
up
a
little
bit
I'll.
Let.
F
Yeah,
so
the
operation
yeah-
I
will
just
spend
a
minute
here
and
let's
files.
F
So
the
operation
has
oh,
so
the
tracers
are
a
lot
simpler.
F
F
So
it
gives
you
back
the
operation
and
then
users
interact
with
that
from
then
on,
but
and
that's
part
of
why
I
was
thinking
of
moving
everything
over
into
the
operations,
because
that's
like
what
you're
working
with
from
then
on,
but
I
kind
of
liked
how
the
if
we
did
that,
then
we
would
need
sub
classes.
F
Each
instrumentation
would
need
a
subclass
of
the
operation
class,
and
so
this
way
all
the
instrumentation
specific
stuff
is
still
in
the
tracer
and
it's
just
all
protected
methods
that
override
the
the
base
class
and
then
the
operations
talk
back
to
the
the
tracer
because
they're
in
the
same
package
they're.
Both
we
have
via
package
access.
F
F
F
F
Yeah
yeah,
I
had
resisted
the
operation
concept,
and
that
was
I
mean
this
is
a
sort
of
going
in
the
direction
of.
If
you
remember,
tyler's,
tyler
was
tyler's.
Original
design
had
spans
these
span
subclasses
at
tracer
subclasses
and
span
subclasses,
and
I
think
the
operation
is
kind
of
turning
out
like
that.
F
So
the
reason
why
I
did
kind
of
got
to
the
point
of
feeling
that
the
operation
object
is
necessary
is
primarily
for,
like
that,
should
that
should
start
span.
F
There's
our
normal
start
start
span
that
returned
a
context.
F
C
D
F
F
F
So
how
would
you
I
mean
downstream
calls,
then
wouldn't
be
able
to
like,
if
you
had
nested
say
like
sometimes
we
use
that
in
the
case
of
we're
already
inside
of
one
of
our
own
spans
say
like
ok,
http,
some
overloaded
methods.
So
in
that
we
have
our
context,
then
we
start
it.
The
next
call
we
put
that
rat
no
op
wrapper
in
there
and
then
downstream
from
that
wouldn't
be
able
to
access
the
the
client
anymore.
D
D
C
F
So
passing
through
everything
I
mean,
so
it's
a
little
weird
right,
because
then
the
instrumentation,
the
nested
instrumentation,
is
going
to
be
calling
updates
on
the
if
you're
passing
those
through.
C
F
Yeah,
because
it
did,
I
mean,
regardless
of
whether
yeah
a
lot
of
stuff
did
clean,
get
cleaned
up
in
the
advice
was
much
nicer
with
this,
so
yeah
yeah.
That
would
be
great.
I
will
look
forward
to
feedback.
F
I
will
take
a
look
thanks,
cool
all
right,
congrats
on
the
getting
sona
type
up
and
going
yeah.