►
From YouTube: 2020-08-28 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
D
Perfect,
that's
actually
perfect,
because
then
you
won't
worry
about
it.
So
much
right!
You
just
off
the
cuff
and
away
you
go.
B
C
D
Especially
since
it's
probably
going
to
be
remote
right,
so
yeah,
oh
yeah,
by
the
way
nice
to
meet
you,
I'm
my
name
is
john.
I'm
maintainer
on
the
java
project.
C
Cool
michael
mannella,
one
of
the
members
of
the
spring
engineering
team.
D
Where
are
you
all
located,
I'm
out
of
chicagoland?
Well,
I
went
to
northwestern
for
grad
school
where,
where
in
chicago
are
you,
I.
C
Live
in
naperville,
okay,
but
yeah
cool,
I
own,
the
burbs,
yep
yep.
Actually,
one
of
the
sales
guys
I
used
to
work
with
lives
in
evanston,
walking
distance
from
the
campus
yeah.
I
lived.
D
Most
of
my
time,
while
I
was
there,
I
was
in
rogers
park
like
two
blocks:
two
blocks
south
of
the
cemetery
cool.
It's
a
little
bit
of
a
dicey,
neighborhood,
but
there's
a
little
block
right
along
the
lake
on
a
little
little
road
called
east
lake
terrace.
So
we
had
we
had.
We
had
a
view
like
we
had
a
third
floor
apartment
view
of
the
lake.
It
was
great
and
it
was
affordable
because
the
neighborhood
was
so
terrible.
D
Although
in
the
winters
the
the
front,
we
had
the
front,
sunroom
only
had
single
pane
windows
and
it
was,
it
was
probably
like
40
degrees
in
the
sunroom
and
then
in
the
back,
where
all
the,
where
all
the
radiators
were
going.
It
was
like
88.
D
E
D
Anyway,
so
yeah
anyone
who's
here,
please
feel
free
to
add
yourself
to
the
agenda.
Attendees
list
like
to
keep
track
of
who's
here
and
for
newcomers.
A
reminder.
This
probably
will
end
up
on
youtube
at
some
point,
so
we're
gonna
be.
D
D
And
we
should
probably
put
that
note
in
the
meeting
notes,
keep
on
forgetting
some
of
the
some
of
the
groups.
Have
it
in
their
meeting,
notes
cool?
Well,
it's
five.
After
so
we
should
get
started
because
I
know
andrew's
gonna
try
to
pull
carlos
out
of
here
before
we're
done
so
cool.
So
I
have
three
items
in
the
agenda.
D
I
want
to
talk
about
the
first
one
should
be
pretty
quick,
we're
planning
on
doing
a
release
on
our
normal
monthly
cadence
of
0.8
next
week,
at
least
unless
carlos
you
want
to
push
it
off
for
another
week,
but
I
think
next
week
would
be
the
week
where
the
first
is
in
it.
So
try
to
do
it
then
yeah
that
works
and
since
I've
never
done
a
release,
I'm
going
to
try
to
do
it
and
carlos,
hopefully
you
can,
if
you're
going
to
be
around
hopefully
to
support
that
effort.
E
Yeah
they
are.
The
process
is
not
as
simple
as
I
wish.
It
was
where
what
yeah?
I
would
be
around
cool.
D
All
right
so
I'll
probably
kick
that
off
on
tuesday,
I
guess
so.
The
other
thing
that
means
is,
if
there's
stuff
we
really
want
to
get
in
for
8.0,
and
I
talked
to
the
instrumentation
group
yesterday
about
this-
that
if
there's
things
they
really
want
to
get
in
for
8.0,
please
let
us
know
and
we'll
do
our
best
to
get
that
in
by
early
next
week.
E
Yeah
one
of
the
things
that
I
wish
I
had
I
had
had
time
to
do
is
the
jager
support
for
for
correlation
context
or
package
now,
which
I
put
in
a
pr
in
a
draft
pr,
but
yeah.
This
won't
be
done
just
yet.
We'll
have
to
wait.
D
Yeah,
I
think
so
that
brings
us
kind
of
the
next
topic
which
is
kind
of
what
we
want
to
do
for
0.9.0
at
the
beginning
of
october
holy
moly
october.
So
I
just
wrote
down
kind
of
some
goals
that
I
have
and
if
this
is
just
my
rough
draft
that
I
wrote
down
last
night,
I
love
given
that
the
spec
is
supposed
to
have
the
tracing
specification
stable
by
september
first
week.
D
Maybe
fingers
crossed
that
we'd
like
to
then
shoot
for
o.9.0
to
have
our
api
and
sdk
stable
for
tracing
at
kind
of
release
candidate
level.
If
people
disagree,
please
speak
up.
D
No,
I
don't
disagree
great,
so
I
think
there's
some
there's
there's
five
open
issues
that
are
p1
we'll
get
to
those
at
the
the
end,
but
that
kind
of
api
wise.
I
think,
there's
three,
maybe
four
items
that
we
need
to
get
to
a
final
decision
on
pretty
quickly
for
o.I.o.
D
One
is
the
attribute
attribute
value
decision.
If
we
want
to
change
that
api
or
not,
I
had
a
big
long
discussion
with
the
instrumentation
group,
two
long
discussions
with
them
this
week
in
their
late
meetings,
so
the
asia
pac-friendly
meetings
so
been
getting
a
lot
of
feedback
from
honorable
and
ask
on
that.
D
D
So
I
personally
think
it's
a
good
change,
but
I'm
only
one
voice,
so
yeah
take
a
look
at
the
both
the
proposal
and
the
pr
that
kind
of
demonstrates
the
idea
of
draft
vr.
It's
not
intended
to
be
merged,
just
a
draft
to
show
it
off
in
a
experimental
package.
B
You
can
have
a
comment
here
regarding
the
api.
As
such
I
mean
we'll,
discuss
this.
I
guess
further
on
in
more
details.
However,
if
we're
talking
about
api
changes
and
theoretically,
let's
say
having
even
verify
like
conceptually
if
spring
cloud
sleuth
could
implement
a
spec
or
something
like
this,
then
we
definitely
had
to
would
have
to
chat
about
brave
and
the
brave
project,
its
api
and
the
api
of
open
telemetry
right.
So
I
I
don't
know
if
this
is
to
discuss
this
or
because
I
see
that
bogdan
is
writing
down
ibogaine.
B
G
Yeah,
martin,
can
you
can
you
turn
off
your
video?
It's
it's
breaking
the
audio
sure
yeah.
Thank
you.
It
was
breaking
and
couldn't
hear
very
well,
but
yes,
we
have.
I
want
to
discuss
this
in
in
a
lot
of
details,
but
let
john
finish
the
heads
up
for
everyone
of
what's
happening
in
the
project.
D
Yeah
yeah
cool.
So
the
second
item
is
a
conversion
of
trace
id
and
spanidy
to
push
them
into
this
bank
context
and
use
strings
as
the
initial
api
surface,
with
the
ease
of
adding
additional
api
services
as
we
need
them
to
the
span
context
itself.
D
So
there's
a
pr
for
that.
I
think
I
haven't
looked
to
see
if
honorable
has
made
any
more
comments
on
it
this
morning,
but
I
think
it's
pretty
solid
and
ready
to
go.
Everything
is
working
and
I
think
it
kind
of
has
met
most
of
the
goals
and
is
it's
the
minimal
api?
We
need
right
now
for
what's
in
the
project
and
then
we
can
add
to
it
as
we
need
binary
protocol
and
things
like
that.
We
can
add
to
it
as
we
go.
D
D
The
next
thing
we
definitely
need
for
a
stable
release.
Release
candidate
is
to
get
correlation
contact,
slash
baggage
implemented.
D
G
D
Yeah,
so
that
is
that's
kind
of
the
the
big
well
aside
from
the
next
item,
the
one
that
really
hasn't
been
attacked
at
all
for
ga.
In
the
last
question,
I'm
just
gonna
bring
it
as
a
heads
up.
Are
we
shipping
with
grpc
context
for
gaa
this
issue's
been
open.
G
Forever,
yeah,
I
think
I
think
it's
related
to
the
next
story:
let's,
let's
wait
until
we
discuss
with
the
guys
from
spring
and
get
more
feedback,
because
I
think
at
that
moment
we
stopped
a
bit
on
the
spring
integration
and
what
is
necessary
for
their,
and
if
this
is
good
enough
or
not,.
D
Perfect,
I
think
that's
fantastic
all
right,
so
I
guess
the
last
thing
I've
kind
of
mentioned
it
already
is
the
p1
burn
down.
We
won't
the
only.
We
have
only
one
unassigned
item
and
that's
correlation
context.
Package
sounds
like
logan
is
interested
in
at
least
taking
a
run
at
that.
So
that
would
be
fantastic.
D
I
don't
know
how
much
more
there
is
to
talk
about
that.
The
big
item
assigned
to
me
is
just
related
to
the
attribute,
attribute
value
and
trace
id
span
id
stuff.
So
there
was
a
discussion
last
night
on
the
apac
meeting
java
meeting
about
whether
we
should
think
about
also
moving
trace
flags
and
trace
state
into
the
context
and
have
them
be
a
part
of
the
context,
rather
than
be
into
separate
objects.
G
Opinions,
I
think,
trace
flag
is
fine.
The
trace
state.
We
may
want
to
keep
it
as
a
separate
class
because
it
has
a
lot
of
utils
around
that.
So
I
I
don't
know-
and
maybe
we
can
implement
some
lazy
initialization
of
that
because,
like
we
keep
the
string
that
we
get
from
the
wire
and
then
we
lazy,
parse
or
or
or
do
things
there.
So
we
may
want
to
keep
that
separate,
because
it's
a
bit
more
complicated
but
yeah,
that's
my
two
cents
trace
flag
should
always
should
immediately
go.
D
I
I
love
the.
I
was
just
looking
at
it
love
that
we
have
a
350
lines
of
code
to
wrap
a
bite.
Yes
with
the
trace
flags
implementation
at
the
moment,
including
like
150
lines
of
builder
code
for
one
byte,
I
don't
know
I
just.
D
Was
very
java
very
and
I
was
very
entertained
by
it.
No,
we
we
should
have
a
builder
for
factory
there.
You
go
exactly
and
then
a
factory
to
make
the
builder.
So
you
have
an
abstract.
Yes,
yes,
if
we
get
to
that
moment,
that's
when
we
say
we
are
done,
we're
done
yeah,
exactly
ready
for
release,
go
ahead,
cool
andrew!
Did
you
have
anything
else
you
wanted
to?
I
don't
know
if
we
want
to
dive
into
the
spring
stuff
right
away
or
if
andrew
you
wanted
to
talk
about.
F
The
only
thing
I
can
bring
visibility
if
it's
relevant
towards
what
you're
trying
to
target
is
the
changes
to
the
spec
that
is
encapsulated
in
the
change
log.
I
put
a
link
in
there,
so
prs
coming
in
should
be
updating
the
change
log
section
called
unreleased,
so
that's
kind
of
like
a
heads
up
of
stuff
to
come.
D
Yeah
I've
been
trying
to
create
issues
as
in
java
as
the
as
those
were
merged
in
the
spec,
so
I
think
I've
been
catching
them
all.
There
may
be
a
few
from
this
morning.
I
haven't
looked
at
yet.
F
So
I
put
that
in
in
the
dock,
so
that'll
give
you
a
preview
as
to
what's
coming
down
the
line,
but
after
we
lock
down
the
trace
api
changes
for
the
first
week
of
september
for
the
spec
we're
going
to
be
following
on
with
issues
related
to
context,
contact
correlation,
I
think
metrics
going
to
be
in
queue.
We
got
to
figure
out
like
how
much
that's
got
to
do
and
then
you'll
see
the
next
line
of
things
coming
down
the
track
related
to
those
those
areas.
G
G
F
G
I
don't
know
if
I
pronounce
your
name
correctly.
It's
michael
or
mikhail
defense,
michael.
G
Yes,
thanks
thanks
for
coming
give
you
a
bit
of
context
everyone
these
two
guys
offer
to
help
us
with
with
the
salute
integration
marching,
I
know
for
sure
he's
one
of
the
owner
of
that
project.
G
I
don't
know
your
role
there,
michael,
but
I
expect
that
you
are
interested
as
well,
so
I
think
the
story
that
we
have
right
now
I
got
a
question
of:
are
we
ready
to
be
integrated
in
and
the
quick
answer
that
they
gave
to
marching
was
not
yet
until
we
we
have
a
stable
api,
because
they
they
have
very
strong
requirements
about
backwards,
compatibility
and
not
breaking
others.
So
I
think
we
will
be
ready
in
couple
of
months
based
on
the
story.
John,
probably
zero.
G
Nine
would
be
a
candidate
to
start
more
investigating
these,
but
most
likely
officially,
probably
one
zero
will
be
the
one
that
will
be
shipped
in,
but
we
still
have
time
to
to
fix
some
some
of
the
problems.
So
that's
that's
the
the
that's
why
I
invited
these
guys
and
I
invited
them
to
help
us.
One
would
be
the
context
discussion
and
the
other
one
marching
pointed
with
the
brave
interaction
and
how
do
we?
How
do
we
work
with
that?
C
G
C
So,
really
quick
before
we
dig
into
the
technical
things,
just
a
little
background
on
our
motivation
of
being
here
and
just
where
we're,
where
we're
thinking
so
really
quick.
Who
am
I
because
I've
not
on
anything
related
to
this
ecosystem,
so
I'm
sure
a
bunch
of
head
scratching,
so
my
name
is
michael
manella,
I'm
one
of
the
managers
on
the
spring
team.
I
actually
manage
both
martian
and
tommy
ludwig
tommy's.
The
project
lead
for
micrometer,
so
salute
on
one
side
metrics
on
the
other,
so
both
of
them
reported
me.
C
So
that's
why
I'm
here,
tommy
couldn't
be
because
obvious
time
zone
situation
he's
out
of
tokyo,
but
so
you
know
we're
looking
at
this
right
now
in
a
couple
of
ways
we
see
from
a
product
perspective,
there's
this
big
convergence.
If
you
will
around
metrics
logs
and
tracing
right,
we
see
that
happening.
Everybody
wants
one
place
from
a
product
perspective
to
see
this
stuff.
C
The
a
consolidation
on
the
api
side
only
makes
sense.
So
you
know
this
seems
to
be
the
effort
where
that's
where
that
is
attempting
to
happen
right.
So
that
makes
sense.
Standardizing
infrastructure
makes
sense
to
us.
So
you
know
this
effort
all
makes
sense
to
us.
That
being
said,
though
bogdan,
like
you
mentioned
a
few
minutes
ago,
we
have
a
large
existing
community,
so
we
have
to
be
careful
about.
C
You
know
basically
not
breaking
anybody
if,
if
we,
if
we
do
start
to
engage
in
this
stuff,
there
are,
and
since
they
are
heavily
using
every
corner
of
the
micrometer
and
and
sleuth
you
know
there
are.
There-
are
concerns
with
regards
to
api
gaps
and
like
brave
for
that
for
that,
on
the
on
the
tracing
side
on
the
micrometer
side,
I
know
john
schneider
did
a
did
a
deck
that
compared
the
two.
The
open,
telemetry
metrics
piece
with
micrometer
did
some
comparison.
C
There
there's
also
been
some
conversations
with
the
quercus
and
microprofile
groups
on
the
micrometer
slack
talking
about
potentially
using
micrometer
for
that
effort,
which
is
to
be
completely
transparent,
kind
of
disappointing.
It
feels
like
open
telemetry
is
where
we
would
make
sense
for
them,
but
that
being
said,
they're
actually
asking
about
micrometer
because
they
actually
their
api
differences
that
that
they're
interested
in,
and
so
that's
in
the
public.
Micrometer
slack
that
if
you
I
can
give
links
if
you're
interested
in.
G
That
conversation
to
provide
us
feedback
fyi,
we
are
more
than
happy
to
help
with
any
missing
parts
in
the
api
or
anywhere
just
to
to
make
the
community
better.
I
mean
you
know
the
whole
project
started
as
multiple
projects:
open,
sensors,
open,
open
trading
situation,
different
and
stuff.
Like
that-
and
we
said:
okay,
let's,
let's
make
all
the
concessions
and
make
everyone
happy.
Let's
have
a
project
that
everyone
is
happy
with.
G
So
if,
if
any
interest
from
from
your
side
to
to
participate
in
this,
and
and
for
example,
let's
say
there
are
missing
features
from
micrometer
in
order
for
you
to
use
this
instead
of
micrometer
just
bring
them
all
like,
we
will
look
for
for
all
these
things
and
make
sure
that
we
we
solve
all
the
problems.
Great.
D
On
this
note,
I've
been
also
chatting
with
ken
and
aaron
about
this
about
all
this
stuff,
and
you
know
chatting
with
them
about
this
experiment
about.
You
know
how
what
can
we
do
right
now
to
kind
of
merge
or
implement
sdk
features
with
micrometer
doesn't
make
sense,
so
I
think
we're
it's
more
kind
of
experimental
chit
chat
at
this
point
right,
it's
conversations
being
where
the
gap
see
and
trying
to
really
discover
those
gaps
by
writing
some
code
and
seeing
what
happens.
C
Yeah
and
the
other
thing
I
want
to
bring
up
is
just
from
our
perspective,
there's
a
unique
window
of
opportunity,
basically
right
now
with
regards
to
our
release
cycle,
so
the
spring
cloud
portfolio
port
of
the
portfolio
is
going
to
do
a
major
version
later
this
year.
The
way
we
handle
our
going
back
to
what
bogdan
mentioned
about
our
backwoods
compatibility
and
support
and
that
kind
of
thing
the
spring
open
source
policy
is,
we
support
major
versions
for
three
years
and
miners
for
one.
C
So
when
they
do
this
major
that's
going
to
be
around
for
three
years.
So
if
we
were
to
do
anything
that
if
we
had
to
make
seismic,
you
know
breaking
changes
on
our
side
to
incorporate
open,
telemetry
now's
the
time
without
that
there
is
a
bigger
there's,
a
lag
there
that
before
we
could
realistically
reconsider
this.
Okay.
G
Definitely
definitely
we
are
more
than
well
happy
to
to
help
with
all
of
this.
I
think
I
think
we
we
need
to
start
from
somewhere,
and
probably
probably
that
somewhere
would
be.
This
discussion
also
some
kind
of
prototype
ish
to
identify
gaps
on
our
side
and
to
help
you
fix
all
of
these
things.
So,
as
you
heard
from
our
side,
we
are
aiming
to
bga
later
this
year.
So
around
the
same
time,
we
can
push
harder
to
to
meet
the
your
goal
as
well.
G
If,
if
now
that
we
know
it's
a
big
goal
for
you
of
this,
so
I
think
we
are.
We
are
committed
to
to
help
the
community
and-
and
this
is
a
great
opportunity
for
us,
so
let's
yeah
anything,
you
ask
us,
we,
we
are
more
than
happy
to
help
and
do.
B
Yeah,
so
you
know
with
the
sleuth
to
o
we've,
because
with
sleuth
1
0,
we
had
our
internal
tracer
with
sleuth
2.
We've
migrated
everything
to
brave.
So
for
now,
let's
say
in
most
cases,
sleuth
is
an
auto
configuration
for
brave,
so
like,
in
my
opinion,
to
cut
the
story
short
for
a
sleuth
to
migrate
to
open
telemetry
in
any
ways.
B
First,
what
should
happen
is
that
brave
and
open
telemetry
meets
somewhere
that
there
is
some
sort
of
a
bridge.
There
is
some
sort
of
something
if
there's
something
related
to
a
brave
implementing,
open,
telemetry,
spec
or
whatever,
then
sleuth
can
abstract
anything
or
everything
that
currently
is
done
via
brave
api,
tuesday
spec
and
we're
done
essentially
right.
B
If,
if
we
don't
have
it,
then
we
have
to
do
it
twice
right,
because
it's
not
like
take
a
look
at
the
point
of
view
of
our
user.
So
we're
doing
the
breaking
change.
As
michael
said,
with
version
30
right
now
and
we
provide
migration
guides
for
our
users,
how
would
they
how
they
migrate?
If
we
don't
have
a
let's
say,
support
for
for
brave
that
would
be
gigantic
work
to
be
done.
B
All
of
their
code
would
actually
not
work,
so
it
would
be
much
better
and
very
beneficial
to
the
to
the
community
if
there
is
a
support
for
brave
and
open
telemetry
together,
because
open,
let's
say
brave
as
such,
has
also
gigantic
code
base.
Yeah.
Sorry,
my
codebase
user
base
right
so
not
everybody.
Let's
say
who's
using
spring,
like
there
are
people
who
are
not
using
spring
and
you're
using
brave
right
if
you're,
using
sprinkles,
sleuth
you're,
also
using
brave.
E
B
So
the
first
thing
is
to
consider,
in
my
opinion,
the
key
thing
really
would
be
to
make
brave,
implement
open
blemish.
G
Let's
yeah,
if
can
you
define
what
support
and
what
implement
means?
Because,
because
there
are
a
bit
of
vag
for
me,
definitely
definitely
wire
compatibility.
We
are
with
brave
and
we
this
is
one
of
the
major
things,
but
most
likely
you
are
talking
in
process
not.
B
B
G
Okay,
is
it
possible
from
your
side
to
to
put
like
half
a
page
description
of
exactly
all
this
scenario
that
you
envision,
that
we
need
to
make
sure
they're,
gonna,
work,
sure
sure
or
issue
or
whatever
something
that
we
need?
We
can
track
and
have
some
clear
things
that
we
need
to
to
follow
to
to
make
this
in
terms
of
brave.
I
don't
know
the
current
state
of
brave
anymore,
but.
G
B
I
don't
I
mean
they
like
with
open
tracing.
They
had
a
bridge
at
one
point,
so
there
was
like
an
idea
to
actually
do
it.
I
have
no
idea
about
open
telemetry.
I
doubt
that
there's
anything
done
there.
G
D
So
for
well,
for
example,
right
now
for
the
open
tracing
apis,
we
have.
We
have
a
an
implementation
of
an
open
tracing
tracer
that
actually
is
backed
by
open
telemetry.
Also.
B
G
That's
the
thing
because
I
I
don't
understand
but
but
if
there
are
concrete
classes
there,
it's
going
to
be
hard
for
us
to
to
make
induction
anyway.
B
I
mean
there's
a
spec
right,
open,
telemetry
spec,
which
is
a
set
of
interface,
essentially
right.
So
theoretically,
theoretically,
if
we've
managed
to
encapsulate-
let's,
let's
say
like
we're
talking
hypothetically,
let's
say
we
have
sleuth
code
base
where
every
single
code
called
to
right
now
to
braves
api
would
be
abstracted
or
maybe
already
is
abstracted
by
the
spec.
B
G
I
see
I
see
so
so
what
you
try
to
achieve,
if
I
understand
correctly,
what
you
are
having
in
mind
is
us
having
an
implementation
of
open,
open,
telemetry
api
that
redirects
to
break.
B
Correct
exactly
and
then,
for
example,
you
add
brave
to
the
class
path
and
sleuth
will
say:
oh
you
have
brave,
so
we
we
know
how
to
hook
it
up,
so
it
works
for
you.
But
actually
there
is
not
a
single,
let's
say,
line
of
code
that
you're
calling
inside
your
code
that
actually
uses
brave,
except
for
some
customizations,
maybe
somewhere
in
some
configurations.
G
I
I
got
it,
I
got
it
so
if
we
provide
you
that
you
are
you,
can
you
can
change
the
code
base
to
talk
to
open
telemetry
api,
respecting
the
spec
which
will
redirect
to
the
respected
spec
brave,
which
means
for
for
your
current
users?
Nothing
will
change,
will
be
just
a
small
redirect
and
for
for
new
users
they
can
change
and
use
open
telemetry.
All
the
way
is
that
for.
B
Example:
yes,
yes,
yes,
so
so
I
mean
the
the
thing
that
would
change
is
that
they
would
have
to
do
some,
maybe
find
and
replace,
because
currently
they
were
using
the
brave
api,
so
they
would
have
to
migrate
to
using
the
spec,
but
this
is
something
that
can
be
documented,
etc.
Yeah
that
way
we
would
abstract
brave,
and
today
they
can
use
brave
tomorrow
they
can
use
open,
telemetry
and
the
next
day
they
can
use
whatever
else
by
just
putting
it
on
a
class
path.
G
Okay,
I
I
think
it
will
be
good
if
you
document
this
idea
and
how
you
envision
this
to
work,
and
we
should
give
a
try
to
to
help
with
this.
D
G
Guess,
let's,
let's,
let's
get
to
that?
Okay,
the!
So
this
is
one
thing
I
I
what
I
what
I
think
for
an
action
item.
I
think
I'm
waiting
for
you
marcin
to
help
us
with
the
pro,
with
a
more
concrete
proposal
of
how
do
you
envision
this?
Maybe
just
a
diagram
or
something
to
show
us
like
hey,
is
talking
to
these
interfaces.
These
interfaces
has
to
be
able
to
talk,
open,
telemetry
has
to
be
able
to
talk
brave,
and
this
is
where
open
telemetry
has
to
support
brave
and
so
on.
G
B
I
mean
that's,
that's
absolutely
not
a
problem.
It's
like
conceptually
we've
been
doing
that
throughout
the
whole
spring
cloud
portfolio.
The
same
thing
was
related
to
you
know:
service
discovery
circuit
breakers.
There
are
abstractions
some
api,
that
is,
let's
say,
not
related
to
any
concrete
implementations.
Then
you
add
stuff
to
the
class
buff
and
it
automatically
works,
and
you
can
configure
some
stuff.
I
can
document
it.
That's
that's
documented.
G
Because
we
are
not-
probably,
we
are
not
very
familiar
with
all
these
things,
at
least
myself
talking
about
myself
and
would
be
good
to
to
learn
from
this
and
and
help
help
with
this
no
problem
perfect.
Thank
you
so
much,
and
the
last
topic
is
the
our
favorite
context.
G
B
Mention
some
things
so
bogdan
I
mean
you
men.
You
mentioned
that
at
the
beginning,
it's
my
actually
our
us
being
afraid
of
those
breaking
changes.
Right
I
mean
with
open
tracing.
There
were
some
issues
in
terms
of
backward
compatibility
and
we
would
take
backward
compatibility
compatibility
extremely
extremely
seriously.
B
So
the
thing
is
that
if,
for
example,
there
was
one
version
of
the
open,
telemetry,
spec
or
whatever
open
telemetry
is
such
that
we
support,
and
then
there
is
a
breaking
change,
then,
theoretically
for
our
users
to
have
best
possible
quality
of
service.
So
to
say
we
should
start
supporting
two
separate
branches
right
which
we
don't
want
to
have
right
now,
because,
for
example,
we
have
two
release
trains
that
we
support
times,
for
example,
two
versions,
each
of
open
telemetry
because
one
broke
the
other
right.
It
becomes
a
very
big
support
burden.
B
G
B
B
B
So
that's
one
thing:
the
other
thing
that
I've
seen
because
I
did
like
a
quick
scan
of
the
of
the
whole
open,
telemetry
portfolio.
I
guess,
if
I
remember
understand
correctly,
there
is
an
open,
telemetry
agent
based
in
tracing
instrumentation.
Am
I
correct?
Yes?
Is
there
a
runtime
one
or
there's
only
agent
one
base,
one.
B
B
If
we
have,
for
example,
we
add
open,
telemetry
agent
right
and
there
is
also
sleuth
at
the
same
time
in
the
same
class
path.
How
will
the
agent
know
about
sleuth
and
vice
versa,.
G
G
B
D
Can
give
a
little
bit?
I
mean
I've
been
very
kind
of
very
closely
working
with
trask
and
honorable.
So
right
now
we
that
that
is
totally
supported.
You
can
like
it
for
open
telemetry
apis.
You
can
use
the
open
telemetry
apis
along
with
the
agent
you
can
do
manual
instrumentation.
You
can
add
that
it
all
works
great.
D
So
I
my
guess,
is
that
and
trask
is
going
to
be
the
expert
here,
but
something
similar
like
if
we
have,
if
it
if
it
works
with
open,
telemetry
apis,
we
should
be
able
to
make
it
work
with
other
apis,
and
the
instrumentation
group,
like
trask,
is
probably
the
I
would
say,
the
world
expert
in
making
this
stuff
work
so
he's
on
the
job.
D
G
No,
absolutely
absolutely
not,
and
also
there
are
some
pieces
of
code
that
right
now
we
are
have
in
the
agent
code
base
related
to
instrumenting,
a
bunch
of
library,
external
lab,
temporary
libraries,
which
will
be
extracted
to
not
depend
on
the
agent
or
anything
will
just
be
standalone.
G
Things
can
be
consuming
consumed
by
by
a
spring
user
themselves
or
can
be
auto
injected
by
the
agent
if
they
decide
to
do
that,
but
that's
a
separate
thing
and
I
think
we
should
have.
We
should
make
sure
that
or
maybe
our
story
should
be
if
you
are
using
spring
with
spring
fluid,
never
use
the
agent
because
salute
will
do
all
the
things
for
you.
Maybe
that's
that's
a
another
reasonable
answer,
marching.
B
B
D
G
One
quick
thing
marching:
this
is
the
reason
why
we
unify
open
sensors
open
tracing
to
not
have
three
times
four
times
instrumentation.
So
I
don't
know
to
answer
your
question
immediate
question.
We
have
to
have
these
instrumentations
being
a
standard
being
an
api
standard.
We
have
to
have
these
implementations
now.
There
is
a
question:
how
can
brave
or
you
or
reuse
the
same
things?
I
think
we
should
figure
out
a
way
to
for
you
to
consume
this
and
drop
others,
or
vice
versa.
We
need
to
yes,
long-term
goal
should
be.
D
D
We've
we've
deliberately
separated
kind
of
api
sdk,
consider
considerations
for
this
group
and
instrumentation,
which
uses
them
kind
of
deliberately
kept
them
separate
for
good
reason,
because
we
want
them
to
use
the
apis.
We
don't
want
them
to
be
like
building
stuff
into
the
sdk
directly
to
support
the
agent
like
it
needs.
The
agent
needs
to
use
the
same
thing
that
everyone
else
can
use
so
that
having
a
unified
view
of
that
is
really
good
and
trask
and
company
are,
are
very
excited
to
work
with
you
all.
As
I
said,.
D
So
there's
three
meetings
that
they
generally
are
at:
they
have
their
official
group
meeting
at
9.
00
am
pdt
on
thursdays,
but
there's
also
a
kind
of
an
office
hours
meeting
on
thursday
at
6,
00
pm,
pdt
and
there's
also
an
informal
really
instrumentation
focused
meeting
at
10
p.m:
pacific
time
on
tuesday
night,
because
they
are,
they
are
much
they're
distributed.
They
have
their
three
primary
maintainers
are
in
estonia,
tokyo
and
portland.
G
Yeah,
so
nikita
nikita
from
estonia
is
one
of
the
maintainers
for
the
instrumentations
and
he's
coming
thursday.
So
a
lot
of
questions
about
instrumentation.
In
unifying
this,
I
I
would
strongly
encourage
if
you
start
filing
an
issue
or
participate
in
one
of
these
meetings
and
dump
the
question
to
them.
They
they
should
be
more
than
happy.
I
already
introduced
you
to
everyone.
I
told
them
that
hey
martin
is
a
great
guy
that
will
help
us
with
this,
so
feel
free
to
go
reach
to
them
and
ask
any
kind
of
questions,
and
they
should
be.
B
Cool,
so
the
last
question
from
my
side
is:
do
you
have
some
sort
of
a
road
map
like
how
do
you
plan
what
should
be
there
in
the
epi?
When
are
you
doing
releases
when
some
milestones
will
pop
up
or
gas.
G
B
G
And
we
we
are
going
to
do
it
next
week:
zero
for
zero,
eight
and
in
a
month,
zero,
nine.
In
terms
of
ga,
we
we
have
a
goal
of
finishing
the
specification
with
semantic
conventions
and
everything
in
in
about
two
weeks
and
then
from
the
java
to
make
sure
implements
all
the
the
ga
requirements
from
the
specification.
So
our
project
is
separated
into
specification
like
a
pure
specification.
B
Cool
and
so
one
last
thing,
so
if
do
I
remember
correctly,
that
you're
planning
to
in
the
ga
version
have
tracing
only
and
the
metrics
will
not
be
there.
G
In
the
final
ga
we'll
be
there,
we
we
are
a
bit
behind
with
metrics
tracing
may
be
called
ga
before
that.
But
when
we
put
one
zero
in
the
library
we'll
have
matrix
entries.
G
Thank
you
help
us
with
context.
That's
what
we
we
need
from
you.
So
give
you
a
bit
of
context
about
context
you,
you
know
very
well
a
lot
of
things
with
context,
propagations
and
stuff.
I
think
a
bunch
of
spring
applications
are.
They
are
using
the
react
context,
correct.
G
Yeah,
so
we
we
started
using
the
grpc
version
for
better
or
forwards,
and
we
we
need
to
know
what
is
the
the
spring
position
spring
is
adopting
globally
reactor
or
just
some
projects
or
how
is
that?
Okay,.
B
So
project
reactor
is
absolutely
in
the
core
of
spring
okay.
So
so,
for
example,
if
you're
using
spring
web
flux,
which
is
the
reactor
http
or
http
version
of
mvc,
so
to
say
right,
then
it's
fully
based
on
reactor,
so
I
mean
reactor
is
all
over
the
place
just
just
to
back
up
a
bit.
C
There's
basically,
two
paths
within
the
spring
world:
there's
reactive.
B
There
are
libraries
that,
even
if
you're
using
non-reactive
approach
you
do
have
reactor
because,
from
the
api
perspective,
you
can
have
a
blocking
version
with
reactor,
but
you
can't
have
the
other
around
right.
The
reactive
version,
without
a
reactor
right,
so
a
reactor
like
explicitly.
You
might
even
not
know
that
reactor
is
there
because
you're
using
the
non-reactive
approach,
for
example,
sprinkled
load.
Balancer
works
like
this,
that,
if
you're
using
load
balancer,
you
will
not
even
know
that
under
the
hood
reactor
is
used
because,
for
example,.
B
Using
the
blocking
part,
it's
actually
blocking
right,
but
the
so
you
like
to
sum
it
up
explicitly.
You
have
two
ways,
as
michael
say,
says,
but
implement
from
the
implementation
perspective.
B
B
So
if
we
are
doing
tracer
dot
current
span,
it
won't
work,
because
there
is
this
conceptual
mismatch
that
we
have
in
the
or
at
least
until
now
we
had
in
the
spec
or
other
tracers
from
what
I
know
that
you
can
have
this
fred
local
thing
from
which
you
can
retrieve
the
value
of
the
current
stuff.
The
reactor
that's
impossible,
because
the
reactor
can
change
threads
at
any
time.
So
if
you
started
an
operator
in
one
fret,
there
is
no
knowing
whether
you're
going
to
finish
it
in
the
same
one.
B
So
what
sleuth
does
it
has
like?
Like
with
the
latest
snapshots?
I
I
introduced
a
new
way
of
doing
things,
because
I
got
tired
of
having
support
questions
that
something
doesn't
work
with
sleuven
reactor.
But
let's
we're
going
to
get
to
that.
So
the
default
mode
is
that
we
are
wrapping
every
single
operator
in
a
slow
version
which
introduces
a
lot
of
performance
issues
and
what
it
does
it's
at
the
beginning
of
an
operator
it
puts
stuff
to
fred,
local
and,
at
the
end
it
removes
it
from
fredlock.
B
B
It
will
work
because
this
instrumentation
of
http
client
assumes
that
something
is
infrared
local,
so
that
will
work
out
of
the
box,
because
the
reactor
instrumentation
puts
stuff
to
fred
loco.
However,
it
doesn't
always
work,
that's
the
problem.
So,
in
my
opinion-
or
let's
say
I
had
a
lot
of
discussions
with
the
reactor
folks-
and
I
see
only
one
way
of
making
this
work,
which
is
non-automatic,
which
means
that
you
have
to
tell
the
user
hey.
E
B
G
B
B
There
is
no
context
that
you
can
inject
take
from
what
you
have
to
do
is,
for
example,
there
are
two
operators
like
do
on.
I
don't
want
to
lie,
but
something
like
do
on
signal,
which
is
completely
generic,
like
absolutely
generic
and
and
there
from
the
signal
you
can
retrieve
the
context,
and
there
is
one
more
like
subscriber.
I
don't
want
to
lie,
but
there's
like
if
you
have
100
operators,
two
extremely
extremely
generic
ones
have
access
to
the
context.
B
If
you
wanted
to
have
access
to
the
context,
they
would
have
to
double
the
amount
of
operators
right
to
have
like,
for
example,
a
zip
and
you
get
in
a
an
element.
This
is
one
version
of
the
api
and
the
second
one.
You
get
the
element
and
you
get
the
context
and
they
don't
want
to
do
it
because
they
already
have
I'm
not
lying.
I
mean
I'm,
I'm
lying,
it's
it's
not
100
operators.
I
think
it's
even
more
so
now.
Imagine
that
you
you
you
get
twice
as
much.
G
B
But
yeah
but
yeah
it's
it's!
It's
it's
real!
So
I
think,
michael
with
transactions.
The
situation
is
easier
because.
G
B
G
B
Is
working
great
right,
the
context
is
working
great.
However,
it's
pretty
much
useless
to
some
extent:
okay,
yeah,
because
the
user,
if
if
the
user
wasn't
supposed
to
actually
reference
the
context-
and
we
were
just
using
the
context
to
propagate
stuff
further
on
it's
working-
it's
already
working,
fine,
okay,
the
thing
is
that
we
want
the
user
to
actually,
for
example,
do
something
right.
G
B
Sure
so
the
thing
is
that
the
reactor
knows
how
to
propagate
the
context
right
and
sleuth
as
an
implementation
knows
how
to
let's
say,
leverage
that
and
add
some
stuff
to
the
context
under
the.
E
B
Right
because
we
can
hook
in
into
let's
say
how
reactor
works.
The
thing
is
that
from
the
user
perspective,
let's
say
imagine
that
you
have
an
http
controller
that
is
working
in
a
reactive
way
correct.
So
you
don't
have
access
to
the
context
really,
because
what
you
need
is,
for
example,
a
request
or
something
like
this
right
and
you're
doing
some
reactor
operator
magic
so
to
say,
but
you
don't
have
access
to
the
context.
So
this
is
the
problem.
B
G
G
Grpc
was
nice
enough
for
us
extracted
that
context
as
a
standalone
package
that
we
can
consume
without,
depending
on
the
whole
thing
reactor
does
not
have
that
the
context
is
embedded
into
a
large
artifact
that
we
will
never
gonna
depend
on
the
whole
thing
so
and
we
were
considering
like.
Should
we
use
the
reactor
context
as
our
context
to
to
to
store
things,
or
should
we
use
other
implementation,
or
should
we
come
with
our
own
obstruction
and
our
own
implementation.
B
I
think
the
best
idea
is
to
have
a
meeting
about
this
with
react
to
folks.
Maybe
some
things
have
changed
since
I
last
talked
to
to
the
reactor
team,
maybe.
E
B
Gonna
have
a
broader
perspective
because
I
I
speak
only
from
let's
say
sleuth
perspective:
let's,
let's
have
a
meeting.
G
D
G
G
We
just
have
two
classes
that
we
bring
from
them,
which
is
the
context,
but
still
people
are
complaining
that
we
are
grpc
centric
using
jrpc
and
I'm
like
guys,
it's
just
an
artifact
that
they
happen
to
share
with
us,
but
anyway,.
B
So
after
the
meeting
I'm
going
to
send
you
an
email,
putting
let's
say
other
reactor
folks
in
the
in
the
email.
G
As
well
use
this
email-
I'm
typing
here
thanks,
it's
very
easy,
I'm
just
a
lazy
person,
so
I
just
said
to
make
it
clear.
D
D
G
G
Thank
you.
Thank
you,
everyone.
I
think
this
is
great
and
please
please,
let's
start
a
broad
collaboration,
make
sure
make
sure
we
are
addressing
all
your
concerns,
all
your
issues
and
let's
make
the
collaboration
even
more
like
from
michael
from
your
side.
If,
if
you
don't
mind
at
one
point
to
start
discussing,
maybe
with
micrometer
and
there.
C
G
It
was
just
yesterday
talk
to
a
time
zone.
It
will
be
in
two
weeks,
thursday,
thursday,
in
the
next
two
weeks.
C
Is
there
somebody
that
well,
that
extra
that's
well
tommy's,
not
speaking
in
spring
one,
so
he's
probably
can
probably
talk
sooner?
Is
there
somebody
specifically,
I
should
connect
tommy
with
the
mean
okay,
okay,.
G
So
yes-
and
maybe
maybe
maybe
we
can
set
up
a
specific
meeting
next
week
to
start
a
discussion,
so
you
know
about
our
calendar.
If
you
go
to
the
to
the
community
report,
so
open
telemetry,
slash
community
repository,
there
is
a
public
calendar
with
google
outlook
and
all
of
them
whatever
you're
using
and
you
can
see.
G
There
is
a
matrixy
that
alternates
every
thursday
from
european
time
zone
to
a
pack
concert
like
okay,
we
try
to
to
to
have
both
meetings
and
all
the
meetings
that
we
have
are
there
like
specifications
and
everything
is
open,
like
all
the
the
meetings
are
open.
The
only
thing
that
you
need
is
respect
the
guidelines,
not
starting
to
say
bad
words
or
stuff
like
that.
But
I
don't
think
it's
the
case,
but
yeah
everything
is
open.
Recordings
are
public
as
well
on
youtube.
You
can
find
them
on
youtube
with
all
the
meetings.
G
This
one
is
recording
so
fyi,
I
don't
know
if
you
it's
for
that,
I
don't
I
let
everyone
know
at
the
beginning,
so
yeah
anyway,
so
michael,
yes,
please
make
sure,
maybe
use
the
same
email
and
I'll
bring
others
and
start
discussing
with
the
with
that.
We
also
have
people
from
reach
from
open
metrics
that
is
coming
to
this
meeting
to
talk
with
us.
So
we
we
kind
of
try
to
reach
on
that
direction
as
well.
We
we
chat
with
them
and
would
be
good
to
have
somebody
from
micrometer
as
well.
D
Great
well
thanks
everybody.
This
is,
this
is
great,
very
excited
to
start
collaborating
some
more
on
this
good
stuff.
Thank.