►
From YouTube: 2021-01-20 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
B
Hello,
everyone
we'll
start
in
few.
B
B
I
think
we
can
start.
I
have
shared
my
screen.
It
should
be
useful.
Now
we
don't
have
a
lot
of
agenda
so
just
see
if
anyone
has
questions.
B
Oh,
so
I
want
to
welcome
a
couple
of
new
faces.
I
mean
victor
is
not
really
new.
He
has
joined
last
week,
but
the
mistake
direction.
He
I
let
victor
do
a
self
introduction.
Hey
victor.
Can
you
do
a
self
intro
for
the
community?
What
you're
up
to.
B
Okay,
probably
is
not
hearing
I'll
come
back
and
kenny.
I
think
we
like
heard
from
you
like
some
time
back
because
the
name
sounds
familiar,
but
if
not,
you
can
just
introduce
yourself
because
I
don't
think
like
anyone
else
have
met
you.
I
was
trying
to
look
your
name
here,
but
I
could
not.
B
B
No,
I
I
think
like
if
kenny
or
victor
is
speaking,
you
are
muted.
Otherwise
we
will
come
back
to
you
later
I'll,
just
quickly
go
through.
The
very
small
agenda
I
have
put
here
so
one
good
news
from
last
since
last
week
is
ellen,
has
joined
the
same
maintainer.
He
was
an
approver
for
like
several
months.
B
Most
of
you
know
alan
west
from
euroleague,
so
we
yeah
if
we
have
like
one
more
active
maintainer,
so
that
should
also
help
with
speeding
up
clearing
our
backlog
of
open
issues
and
prs.
So
thanks
ellen
for
accepting,
apart
from
that
yeah.
Oh
sorry,
someone.
B
All
right,
yeah
and
next
is
bought.
This
specification
had
had
an
open
pr,
I
mean
still
open
about
versioning,
and
that
seems
to
be
mostly
ready.
I
looked
at
the
pr
this
morning.
It
looks
like
it
has
enough
approver,
so
I
am
expecting
it
to
be
merged
very
soon.
B
We
would
be
following
up
with
our
own
dog,
because
the
one
of
the
requirement
is
every
language
should
create
a
versioning
dog
which
is
specific
to
the
language,
and
we
do
have
the
pr
from
a
few
weeks
back,
which
has
received
a
lot
of
comments.
I
haven't
seen
like
actual
approval,
so
I'm
hoping
that
we
should
be
able
to
close
on
this
really
cute
once
the
actual
like
once
I
get
the
actual
approval,
I'll
refactor
it
and
make
it
like
a
single,
because
right
now
I
have
listed
approach.
B
One
approach
to
approach
three,
it
looks
like
most
most
of
reviewers
are
inclined
towards
approach.
Three,
where
we'll
have
separate
branches
for
experimental
features
and
releasing
the
features
would
be
as
a
1.1
hyphen
pre-release
marker,
like
alpha
so
matrix,
would
be
the
good
candidate
for
that.
So
tracing
will
not
contain
any
matrix
code,
it
will
be
separate
same
package
but
different
version,
and
eventually
we
will
merge
it
into
the
same
package.
So
this
is
detailed
here.
So
please
take
a
look.
B
If
everything
looks
good,
please
put
a
thumbs
up
or
thumbs
down
or
raise
issues
once
this
is
merged
after
getting
the
profile
I'll
organize
repo
in
such
a
way
to
actually
implement
what
we
talked
about
in
this
spec
because
it
did
require,
or
it
will
require
some
changes
in
the
way
we
are
packaging.
B
B
I
just
need
to
get
this
in
so
that
we
can
actually
start
executing
one
of
the
key
things
which
was
discussed
last
week
was:
we
will
not
be
able
to
release
instrumentation
at
the
same
time,
so
we'll
be
releasing
it
afterwards,
because
the
spec
year
clearly
states
that
instrumentations
are
not
ready
for
one
dot,
so
we'll
be
delaying
it.
B
So
that's
all
I
had
on
depths
of
update
and
there
is
a
question
which
I
want
to
ask
about:
the
existing
metrics
code.
Are
there
like
people
who
are
like
relying
on
that
for
any
scenarios?
B
Would
I
mean,
would
you
want
to
keep
it
in
one
daughter
with
absolute
marker,
or
is
there
any
any
objection
if
we
just
remove
it
completely,
because
we
anticipate
getting
a
build
from
at
least
a
private
build
from
the
dotnet
runtime
sometime
like
march
or
early
april,
so
at
that
time
we'll
have
the
first
version
of
matrix
sdk
from
this
repo.
B
D
D
The
question
is:
if
you
want
to
improve
it,
can
we
like
we
want
to
improve
it,
and
dotnet
team
may
need
to
start
experimenting
with
how
this
api
service
will
look
like?
Do
we
want
to
start
a
new
assembly
or
like
nuget
package
alongside
the
open,
telemetry
api,
or
do
you
want
to
keep
it
inside
a
open
s
main
dll.
B
So,
based
on
the
questioning
like
the
metrics
code,
will
be
in
the
same
package.
It
will
not
be
a
separate
package,
it
it
will
be
called.
It
will
be
versioned
differently,
not
named
differently,
so
we'll
not
be
having
like
dot
matrix
as
a
separate
package.
It
will
be
still
open
elementary
sdk
package.
B
B
Matrix
sdk
slash
api
for
some
scenarios.
Would
you
be
okay
to
continue
doing
that
in
the
release
candidate
versions,
or
you
are
proposing
that
we
should
you?
You
still
want
to
use
it
like
going
forward
until
the
final
metrics
are
ready.
D
I
mean
ideally,
we
want
to
get
final
metrics,
but
we
are
still
working
on
them
right.
So
as
we
work
on
them,
I
think
we
are
happy
to
consume
rc
versions,
so
the
choice
is
really
either
to
implement
our
own
library
that
will
implement
basically
similar
functionality
or
contribute
to
common
good,
and
if
we
have
a
place
to
experiment
and
drive
it
forward,
then
we
definitely
want
to
keep
it
here
in
open
telemetry.
I.
D
B
We
shouldn't
be
even
doing
anything
in
this
repo
if,
since
dotnet
is
doing
it,
so
whatever
we
do
will
be
like
thrown
away
at
some
point.
E
E
B
No,
the
matrix
code
has
already
like
warning
above
it.
If
anyone
tries
to
compare
it,
it
should
say
it's
absolute.
B
E
D
B
Okay,
so
if
you're
afraid
to
like
one
daughter
version,
then
we
my
vote
would
be
to
say
like
remove
it,
don't
don't
carry
it
because
it's
it's
still
a
prototype.
It's
not
recommended
for
any
practical
purposes
other
than
just
playing
with
it
and
like
understanding
the
spec
may
be
better,
but
that
I
said
there
is
no
actual
use
case
or
it's
not
really
usable
at
all.
Is
that
what
like
victor?
You
are
also
suggesting
that
we
shouldn't
release
it
in
1.0
or
we
shouldn't
release
it
in,
like
alpha
version.
Also.
E
A
E
Because
it
would
confuse
me,
I
accidentally
use
it.
Yes,
I
understand
that
it
does
print
out
a
whole
bunch
of
errors.
Saying
that
you
know
you
should
not
use
this
for
production,
but
then
why
is
it
there?
And
if
I
then,
just
assume
that
maybe
it's
there
for
experimental
and
maybe
they're
gonna
one
day
take
off
that
you
know:
don't
use
some
production
tag
and
if
I
start
to
use
it,
then
that
is
also
not
you
know,
aligned
with
the
current
spec
or
the
future
spec,
so
for
all
intent
and
purpose.
E
B
Yeah,
that's
not
the
point
for
like
one
daughter
release,
we
don't
try
to
keep
any
experimental
stuff
and
the
matrix
code.
It
still
remains
there
because
there
was
no
official
plan
on
how
how
do
we
decouple
experimental
stuffs,
because
when
we
started
matrix
work
it
was
not
originally
planned.
That
matrix
would
be
like
delayed
or
it
will
come
as
a
separate
time
timeline
as
opposed
to
tracers.
But
the
way
things
turned
out
was
tracers
became
ready
much
earlier
and
metrics
are
still
no.
So.
E
B
So
basically
I
was
asking
what
should
be
like.
Is
there
any
reason
why
we
should
keep
the
current
absolute
mark
matrix
code
in
the
one
auto
release
at
all?
If
I'm
just
asking
like,
if
there
is
anyone
who
has
depended
on
it
for
some
reason,
they
don't
want
to
like
move
to
a
different
version
just
to
continue
to
using
that.
F
I
don't
think
anybody
actually
has
a
dependency
on
the
old
code,
so
I
think
we're
all
in
agreement
in
terms
of
removing
this
obsolete
code.
Until
you
know,
we
have
a
new
version
and
I
think
at
least
my
understanding.
What
sergey
was
saying
is
that
can
we
have
another
area
yeah?
I
think.
F
Right
right
where
we
can
actually
continue
to
work
on
the
metrics
implementation
in
parallel,
while
you
know
1.0
stabilizes
and
rolls
out.
B
Yeah,
I
mean
I'm
mostly
asking
this
because,
like
since
we
are
depending
on
the
dotnet
runtime,
to
provide
the
api,
it
won't
be
like
for
another
one
or
two
months
before
we
have
like
that
playground,
because
if
there
is
no.
F
B
From.Net
yeah,
then
we
wouldn't
have
even
an
experimental
sdk
in
place,
so
there
is
like
at
least
a
one
month
gap
from
whenever
we
remove
it.
So
I'm
seeing
like
whether
this
will
affect
anyone
who
wants
to
because
again,
I
know
that
you
are
contributing
something.
So
basically
it's
just
for
you
all
alternately.
We
can
keep
that
in
a
separate
experimental
branch.
B
D
Yeah,
it's
great,
I
don't.
I
prefer
not
to
have
branches
like
branches
are
terrible
in
github,
just
from
flow
perspective
and
like
trying
to
keep
them
up
to
date.
I
mostly
were
like
usain.net,
you
provide
this
api.
Are
they
actually
working
on
it?
In
some
other
repository?
No.
B
I
think
so
all
the
code
which
ships
from.net
it
would
be
in
the
github
github,
slash,
microsoft,
slash,
sorry,
github,
slash
dot
net,
slash
runtime,
so
that's
where
the
code
would
be
if
you're
asking
like.
Is
there
anything
to
try
out
today?
There
is
nothing,
but
we
expect
like
some
code
to
come
in
the
next
month
or
two,
so
it
still
github
in
public.
So
we
should
be
able
to
see
that
and
contribute.
If
that
worked
for
you
as
well.
F
That's
what
sergey
was
asking
right:
where
would
we
collaborate
if
we
did
not
do
a
branch,
then,
where,
where
could
we
move
the
metrics
code
as
it
stands
today,
yeah
so.
B
On
top
of
it,
then,
like
we'll,
have
a
branch
which
contains
the
metrics
code,
so
that's
where
we
would
be
collaborating
and
for
the
api,
it's
document
on
times
repo,
it's
still
open,
so
anyone
can
look
at
the
pr's
command
things,
but
that
is
at
least
a
month
away,
so,
like
probably
like,
if
you
want
to
do,
let's
assume
that
we
remove
the
metrics
code
like
next
week
or
jan
end
of
month,
which
is
in
next
two
weeks.
E
C
joe,
why
are
we
dependent
on
the
net
implementation?
Can't
people
continue
to
contribute
toward
the
sdk.
E
So
so
you
made
a
you
made
a
couple
of
statements
saying
that
we
are.
We
are
waiting
for
the
net
team
to
implement
stuff,
which
I
presume
is
the
api
side.
So
the
question
then
follows:
why
do
we
have
a
dependency
on
the
api
side?
Can
we
not
continue
to
work
on
the
sdk,
which
presumably
does
not
require
anything
from
quote
the.net
key.
B
I'm
not
sure
like
how
do
we
implement
the
sdk
set
of
things
without
api
the
same
with
tracing?
We
need
the
api
first
before
we
can
implement
anything
in
the
sdk.
The
way
we
structured
that
in
the
tracing
is,
we
already
had
created
a
activity.
Sorry
the
span
equivalent
in
this
repo
and
once
dotnet
exposed
it.
We
like
throw
away
the
one
we
had
and
replaced
it
with
the
one
from
dotnet.
So
are
we
done
with
aggregators
and
processors?
B
You
know
I.
I
was
talking
about
traces
interfaces,
that's
how
we
did
it
without
waiting
for
dotnet
to
expose
the
api.
We
started
working
with
our
own
implementation,
which
was
later
replaced
with
the
dotnet
runtime
one,
the
api
for
tracing
for
matrix,
since
the
dotnet
does
not
have
anything
as
of
today
to
start
working.
The
questions
should
be
like
create.
It
should
be,
create
some
code
and
eventually
throw
it
away.
B
When
dotnet
exposes
the
api
that
that
was
the
question
which
I
was
trying
to
ask
like:
should
we
just
completely
remove
it
or
retain
it?
So
we
have
like
somewhere
someplace,
where
there
is
a
matrix
apa
code
and
we
can
write
an
http
implementation.
E
So
so
forgive
me
see
joe,
I
I
would
I'm
a
bit
confused
here.
So
if
we
had
a
separate
repo
that
has
just
the
api
and
sdk
for
metric,
that
seems
to
potentially
satisfy
most
people
right
like
when
you
say
repo,
like
did
you
mean,
like
a
github
repo
like
a
separate
one,
separate
package,
separate
nougat,
separate.
B
Repo,
we
don't
have
any
plans
at
least
based
on
today.
Today's,
like
my
understanding,
there
is
no
plan
to
create
a
separate
repo.
That's
the
question:
yeah.
There
is
no
plan
for
like
separate
repo
yeah.
F
F
B
Different
brands,
we
can
still
produce
a
different
like
version
of
nougat,
so.
D
B
Yes,
I
I
think
what
you're
trying
to
say
is
about
the
versioning
strategy,
because
we
have
these
two
listed
in
the
like
open
pr,
and
it
looks
to
me,
like
most
people
were
in
favor
of
creating
a
separate
branch
for
matrix
work,
but
sega.
What
you
seem
to
suggest
is
the
opposite:
they
keep
the
same
branch
but
extract
matrix
into
its
own
package.
B
So
let
me
open
that,
and
I
think
it
may
be
easier
if
you
just
open
that
up
pr
and
look
over
it
and
see
if
the
let
me
load
it
first.
B
So
so
again,
I
think
what
you're
suggesting
is
for
metrics.
We
create
a
separate
package.
I
think
the
expert
example
would
be
fine
yeah,
so
we'll
have
like
1.0
from
containing
tracers
and
metrics
containing
our
pure
metrics
code,
which
is
like
a
separate
package,
separate
name
but
still
maintained
from
the
same
repository
same
branch.
B
Is
this
what
you
were
preferring
and
my
alternate
proposal?
Yeah
is
I'm.
D
Just
my
biggest
worry
is
simplicity
of
maintenance.
B
B
D
B
So
have
listed
down
like
the
pros
and
cons
with
this
approach,
like
the
approach
where
we
still
keep
the
same
branch
but
a
separate
package,
and
the
third
approach
is,
I
think
the
experiment
example
should
explain
that,
so
it's
still
the
same
package
for
matrix
and
tracers
but
version
differently,
so
this
1.0
would
be
released
from
the
master
branch
and
1.5.
B
It
would
be
containing
the
exact
same
code
as
one
dot
of
four
traces,
but
it
will
also
contain
additive
matrix
changes,
and
this
will
be
released
from
the
experimental,
hyphen,
matrix
branch
and
yeah.
I
mean
we
are
fully
aware,
like,
like
you
said
it,
it's
going
to
be
a
little
bit
more
in
terms
of
like
bookkeeping
like
we
need
to
make
sure
like
this
branch
is
kept
in
sync
with
the
master
version,
but
this
is
what
I
have
explained
in
approach
three
here,
so
this
should
still
satisfy
your
requirement
that
you
have.
B
You
have
a
place
to
consume
the
like
matrix
package.
You
want
to
use
it
provide
feedback,
so
that
would
be
this
place,
and
this
is
where
the
of
course
this
will
improve
to
alpha
beta
or
time.
But
this
is
where
the
stake
implementation
would
leave
for
metrics
in
the
future
and
eventually,
once
like,
once,
the
work
is
ready
and
dotnet
is
ready
to
release
their
package
also
was
stable.
Then
we
just
have
like
1.5
release,
which
consists
of
tracing
work
and
all
the
previously
experimental
metrics
work.
B
Yeah,
I
think
you
know
we
did.
Actually
we
didn't
list
down
that
separate
approach
like
instead
of
using
a
separate
branch,
we
can
keep
metrics
in
the
same
code
and
conditionally
come
that
is
still
an
option
it.
It
looks
like
we
need
the
the
question.
Pr
was
not
just
addressing
metrics,
it
was
more
like
what
do
we
do
in
general,
with
experimental
signals
and
matrix
was
chosen
as
a
like.
B
A
good
candidate
example
and
multiple
branches
strategy
should
solve
like
any
number
of
experiments
and
conditional
compelling
might
be
a
little
tricky,
but
I
haven't
really
thought
through
the
specific
or
implementation
details
on
how
do
we
approach
this
with
their
conditional
compilation.
B
B
Task
from
like
everyone,
because
this
records
we
started
with
one
approach
very
beginning,
but
after
as
I
like
mister
down
the
exit
steps,
it
became
clear
that
it
is
not
sustainable.
So
that's
why
we
decided
to
go
for
like
do
more
listing
down
of
specifics.
How
would
how
would
this
be
like
whole
carried
out
and
one
of
the
outcome
from
that?
I
was
able
to
write
down
one
of
the
four
downsides
with
each
approach.
B
So
the
approach
two
which
involves
accepting,
I
did
like
write
down
all
the
downsides,
which
I
think
would
be
which
it's
right
here
yeah
there
is
no
clean
translation
issue,
it's
mister
down
and
that's
the
thing
which
we
would
solve
with
like
different
branch
approach.
Where,
like
one
of
the
main
goal,
is
like
at
one
point,
we
will
decide
that.
Okay,
this
is
not
experimental.
B
This
is
stable,
so
that
would
be
of
least
disruption
to
the
people
who
were
consuming
it
like
they'll,
just
upgrade
from
1.5
beta
to
rc2
1.5,
and
they
will
require
no
like
no
code
change.
There
is
no
need
of
a
changing
entry
point
or
anything
because
it
should
just
evolve
like
if
you
are
like
kept
up
to
date
with
your
like
rc
releases
or
beta,
and
the
final
one
should
exactly
match
what
we
do
for
beta.
B
When
you
say
separate
repo,
like
I'm
trying
to
read
like
do,
you
intend
like
a
separate
github
repo
completely
just
for
metrics?
Is
that
what
you
are
envisioning
when
you
start
separate
repo,
or
you
just
mean
like
separate
package,
only.
E
E
Right
but
but
the
package
would
be
inclusive
of
trace
as
well
as
it's
not
independent.
It's
you
know
you,
you
can
choo,
you
have
to
pick
either
the
the
rc
package
or
the
quote
experimental
package
right.
There
isn't
a
case
where
you
just
picking
off
whatever
the
rc
package
will
just
trace.
You
know
and
then
separately.
You
pick
up
a
separate
nuget
package
for
all
of
the
experiments
for
metric
and
then
sometime
in
the
future.
When
those
experiments
are
valid,
they
then
show
up
magically
into
the
rc.
B
E
E
E
But
you
keep
your
same
main
line
of
code
for
people
that
are
not
doing
anything
special
with
metric
they're,
just
not
changing
code
they're,
just
updating
the
version
from
rc
to
1,
to
rc2
and
so
forth,
and
for
the
other
people
that
want
metric
today
they
could
just
independently
and
separately
pick
up
a
package
but
because
they're
doing
those
experiments
themselves.
They
know
that
in
the
future
those
packages
will
be
merged
back
to
the
rc
right,
so
that
keeps
them
totally
separately
and
it
keeps
your
line
of
branch
clean.
B
Yeah,
it's
just
that,
like
I
never
called
it
like
rc.
It
is
still
the
master
branch,
because
master
is
the
one
which
currently
contains
all
the
code
and
matrix
would
come
from
separate
branch,
so
keeping
the
branch
in
sync
like
we
would
keep
the
experimental
matrix
branch
in
sync
with
the
master
branch.
So
if
you
have
like
new
features,
two
tracers,
you
would
get
that
in
the
1.5
beta
or
alpha
release.
B
If
you
are
just
using
metrics
part,
then
you
will
have
that
also
in
the
1.5
beta,
so
it
I
think
it
should
satisfy
what
sega
was
asking,
because
the
you
you'd
have
a
playground
for
like
like
using
and
contributing
to
matrix
code
without
affecting
the
tracing
stability
in
any
way.
E
B
It's
not
clear,
so
I
think
what
you're
saying
is
like
one
package
which
contains
traces
and
another
which
contains
matrix
only
right.
That
second
part
is
not
correct,
because
the
second
package
would
contain
matrix
and
that's
my
point
exactly
that's
my
concern.
E
B
Do
we
have
like
better
options
which
would
allow
like
clean
cut
as.
E
B
E
B
I
mentioned
it's
as
a
clean
cut
scenario
like,
for
example,
like
some
of
the
entry
points
are
like
in
the
shared
place.
So
if,
let's
say
like
matrix
is
like
in
a
standalone
thing,
there
is
no
connection
with
the
main
package
which
currently
consists
of
traces.
The
entry
point
once
we
move
it
to
the
common
place,
people
who
are
using
the
separate
package
once
it
becomes
ready,
they
will
be
like
upgrading
to
the
new
version
and
they
will
need
to
do
like
code
changes
as
well.
E
B
There
will
be
code
change
right
for,
for
instance,
like
things
which
are
coming
from
the
common
common
entry
points
like
like,
specifically
in
the
case
of
metric.
It
would
be
something
like
creation
of
meter
provider
builder,
as
shown
here.
So
if.
B
E
B
Yeah
I
mean
if
there
is
a
way
to
avoid
code
change.
I
don't
think
it
is
an
issue
to
keep
separate
packages
like
independent,
like
separate
package
as
an
independent
package
for
metrics
and
traces
with
there
is
no
commonality.
So.
E
E
B
C
D
A
D
B
So
there
are
two
things
like
one
is
any
further
comments.
Let
let's
do
this
in
the
pr
about
the
versioning
strategy,
but
so
again
your
question
is
like:
where
would
my
team
expose
the
matrix
code
like
the
like,
whenever
they
start
exposing
matrix?
Where
would
they
expose?
It
is
that
you.
B
D
Would
assume
that
they
need
some
playground,
and
I
don't
think
I
mean
it's
hard
to
make
it
right
from
a
first
attempt,
so
they
need
to
have
either
some
reference
implementation
or
some
playground,
and
I
suggest
I
maybe
you
can
ask
them
to
come
to
the
meeting
and
discuss
whether
this
playground
can
be
this
package
inside
open,
telemetry
position.
B
B
Is
that
like
something
which
is
something
which
we
can
continue
for
metrics
as
well.
B
B
I
think
I
cannot
regulate
how
exactly
we
did
the
tracing
part,
because
I
was
not
part
of
it
when
we
started
the
tracing
work.
But
if
my
memory
serves
correct,
it
was
still
in
the
dotnet
runtime
repo,
where
all
these
experiments
were
performed
and
we
were
given
like
like
some
new
get,
which
is
not
even
published
in
uk,
it's
probably
published
too
like.net
daily,
build
or
some
place
by
the.
D
B
Could
potentially
follow
the
same
thing
as
tracing
like
in
the
in
this
repo?
We
will
implement
like
an
open,
elementary
matrix
api
and
let
dot
net
use
that
as
your
reference
like
build
it
and
eventually
we'll
replace
the
api
with
the
actual
thing
from
the
dotnet.
D
B
Oh
no
yeah,
I
mean
the
plan
is
definitely
to
collaborate
as
much
as
possible.
It's
just
the
logistics
which
you
are
like
asking.
I
will
definitely
ask
like
what
is
the
plan
from
the
runtime
folks
like?
Do
they
then
to
produce
a
or
keep
a
branch
in
the
like
runtime
report,
to
have
the
metrics
code
exposed
there
or
is
it
something
else?
So
I
will
definitely
ask
and
maybe
like
ask
them
to
represent
or
join
the
meeting
and
see
if
the
their
proposal
is
acceptable
to
us.
B
Yeah,
just
to
make
sure
I
understand
it
correctly,
you
do
do
you
intend
to
like
contribute
to
the
apa
part
which
will
eventually
be
in
the
runtime,
or
you
intend
to
be
like
a
consumer
of
it
like.
Whenever
dotnet
team
produces
a
build
of
matrix
api,
you
intend
to
consume
it
soon.
D
B
I
think
yeah,
so
you
want
to
make
sure
like
we
are
not
like
delayed
by
any
like
documenting,
not
starting
early
enough
or
not
providing
the
packages
to
the,
because
the
official
package
will
only
come,
I
think,
may
or
in
end
of
may
or
june.
That's
where
you
can
consume
the
dot
net.
Six
preview
builds
from
newgate,
but
until
then
like
up
until
that
point,
you
need
a
place
where
you
can
like
completely
consume
and
produce
from
the
beginning.
B
B
So
the
initial
approach
I
mean,
since
the
aps
spec
for
matrix,
are
not
yet
stabilized
what
I'm
hearing
is
like.
We
are
initially
trying
to
figure
out
the
like
the
listening
mechanism
like
similar
to
how
we
default
activity
like
you,
have
an
api
for
activity
and
you
have
a
way
to
like.
Listen
to
it.
That's
what
constitutes
your
sdk.
B
So
that's
a
big
problem
in
itself,
so
we
would
probably
start
with
that,
and
even
if
the
matrix
api
makes
some
changes
from
like,
we
should
still
be
able
to
accommodate
it,
because
it
should
be
relatively
relatively
easy
compared
to
like
figuring
out.
How
do
we
connect
the
ap
and
sdk
components
together?
So
I'm
hoping
that
whatever
be
the
api
change,
we
should
be
able
to
quickly
make
the
actual
apa
change,
but
yet
how
that
sdk
connection
like
be
available
for
consumption
really
soon.
B
Yeah,
and
would
it
would
you
want
to
like
how
someone
from
dotnet
teams
you
know
meeting
like
next
week
or
the
week
after,
to
have
likes
more
discussions
about
metrics
or
or
do
you
just
want
them
to
like
produce
something
in
the
runtime
repo?
And
then
I
can
put
a
note
here
that
hey
there
is
a
new
build
or
there
is
a
new
proposal
in
the
dot
net
runtime
repo
please
go
and
comment.
B
Okay,
yeah,
we
were
doing
like
a
mix
of
both
last
time
when
we
did
for
tracing
dot.
Net
folks
did
join
the
meeting,
sometimes,
but
mostly
like
they
create
a
a
proposal
in
one
time
repo-
and
I
I
think,
like
sir
getting
you
or
one
of
us,
created
issues
here,
asking
people
hey.
There
is
a
new,
build
or
new
feature
in
dot
knight,
which
is
going
to
eventually
replace
the
tracing
api.
B
Please
go
look
at
it
so,
but
yeah
all
right
and
for
the
question
you
do
have
like
like
more
approaches
or
any
issues
which
we
have
interviewed
and
referred
with,
which
is
already
not
captured
here.
Please
do
look
at
the
beer,
because
I
mean
this
is
something
which
we
really
need
to
close
before.
We
can
start
arranging
the
branches
and
if
we
go
with
the
branches
model,
so
once
again,
just
like
I
mentioned
at
the
beginning,
please,
like
add
your.
B
D
I
didn't
mean
to
cut
you
off.
I
just
want
to
make
sure
that
we
spend
our
time
actually.
G
Yeah,
I
just
also
wanted
to
add
that
we're
going
to
take
the
take
the
extra
step
and
go
in
and
fix
the
remaining
vendor
plugins
that
are
in
the
contrib
folder
to
be
up
to
spec,
with
currently
whatsapp
main
line,
so
that'll
that'll
at
least
get
the
contrib
rupo
into
somewhat
of
a
better
state.
And
if
we
were
to
open
up
those
pull
requests,
would
you
guys
be
able
to
take
take
a
look
at
them
in
a
timely
manner?.
B
Oh
sorry,
I
I
lost
the
last
part
like
you,
you
wanted
to
show
something,
or
you
were
just
asking
people
to
just
review
it.
G
B
G
I
don't
see
that
that
that
that
that
is
a
blocker
for
this
right.
I
think
we're
we're
still
going
to
push
forward
that
discussion
that
we
talked
about
earlier
today,
but
we
also
want
to
unblock
the
the
contribute
contribution
folder,
and
I
think
the
problem
is
right
now.
Is
that
all
these
all
of
these
are
either
some
of
them
are
out
of
date?
They
need
to
be
upgraded
to
the
new
rc
apis
and
and
because
you
guys
don't
have
that
prioritized
just
yet.
G
If
we
open
pr's,
would
you
still
review
them.
B
B
But
if
you're
asking
like
in
general
like
is
the
community
like,
we
need
to
do
code
reviews,
I
think,
like
we
have
seen
people
actively
participating
in
it.
But
I
haven't
looked
at
specific
whether
anyone
else
has
looked
at
aws,
specific
instrumentations.
G
C
I
think
what
what
we
plan
to
do
here
is
like
before
we
can
go
in
and
merge
like
any
of
the
aws
specific
code.
The
contrib
repos
still
points
at
are
used
as
the
0.7.0
beta
build
of
the
of
the
open
telemetry.
E
C
So
if,
if
we
can
upgrade
this
to
the
rc-1,
I
believe
a
lot
of
the
stuff
in
the
contributor
would
be
breaking.
I
think
you
mentioned
earlier
that
eddie
was
working
on
fixing
some
of
those
like
upgrading
to
the
latest
version
of
open,
telemetry,
sdk
and
stackdriver
was
breaking
and,
and
so
would
the
aws
specific
code
would
break.
So
if
we
go
in
and
try
to
get
the
contrib
repo
to
use
the
latest
version
of
open,
telemetry
sdk
the
rc1
and
try
fixing
as
much
as
we
can
do.
C
We
have
someone
who
can
review
the
code
and
like
accelerate
us
in
getting
the
contrabrupo
in
shape
and
like
using
the
latest
version
of
the
sdk,
because
I
I
believe
after
that,
like
how
much
of
a
breaking
change
would
be
from
rc1
to
d1.0,
because
if
we
fix
it
now,
if
there
is
not
going
to
be
a
lot
of
breaking
change,
if
we
fix
the
quantum
repo
to
use
the
rc1,
then
we
in
the
future.
We
can
probably
move
faster
with
the
prs
on
the
contrib
repo.
B
One
of
the
reason
why,
like
we
were
blocked
from
upgrading
to
the
I
mean
from
0.7
to
the
one
daughter
rc,
is
we
made
like
couple
of
classes
internal,
which
was
dependent
on
by
the
instrumentations
in
this
repo?
So
it
was
already
like
decided
that
we'll
have
like,
like
one
of
that
class
sorry,
one
of
them
is
activity
source
adapter.
We
already
decided
we
are
going
to
make
it
open
as
public,
so
that
should
unblock
major.
B
I
mean
I
haven't
looked
at
everything,
but
at
least
it
should
unblock
mass
transit
and
elasticsearch.
That's
the
only
two
thing
which
I
looked
recently
because
they
are
both
blocked
from
upgrading
to
the
newest
version
of
the
main
sdk.
So
I
can
definitely
like
prioritize
making
the
exposing
activity
source
adapter
public,
which
would
unblock
horror
statement.
I'm
not
sure
like
who
has
the
time
to
like
quickly
modify
all
these
individual
instrumentations
to
use
a
new
one.
B
To
the
current
state,
where
it's
not
feasible
to
upgrade
so
would
that
work
like
if
we
like
make
a
build,
which
consists
of
a
new
version
which
has
activity
source
adapter,
for
I
mean
public
like?
Are
you
saying
that
you
would
be
able
to
look
at
and
upgrade
because
right
now,
it's
a
single
source?
C
C
If
we
can
get
the
contrib
repo
in
shape
with
the
latest
version
of
the
sdk,
we
can
ensure,
like
a
lot
of
the
prs,
would
be
merging
much
faster
because,
like
I
had
the
pr
for
aws
client,
which
is
also
breaking
because
it
uses
a
get
tag,
value
api,
which
is
now
internal,
I
believe
so
like.
D
C
D
I'm
happy
to
take
a
look
at
prs
that
unblocks
it
so
just
mention
me
explicitly.
Please
it's
sergey
speaking.
B
Okay,
yeah
thanks
again,
no
I'll
start
the
first
step
like
like
just
to
list
around
what
we
want
to
do
here
like
number
one
thing
before:
even
you
can
do
like
any
significant
changes.
We
will
want
to
get
a
build
which
contains
activity
source
adapters
public.
So
this
should
be
like.
C
B
Not
just
that
like
there
is,
we
had
an
alternate
suggestion
on
how
do
we
deal
with
legacy
instrumentations
like?
Basically,
you
have
an
activity
which
was
already
created.
Let
me
just
throw
it
away
and
create
a
brand
new
one,
but
that
approach
do
not
work
in
mass
transit
and
there
is
no
other
workaround
like
you
cannot
really
offer
any
other
workaround
other
than
making
activity
source
adapter.
B
It's
in
the
issue
which
we
have,
but
I
think
it's
already
decided
like
we
will
have
activity
source
adapter
as
a
public
class.
So,
like
you
can
start
consuming
it.
So
this
part,
okay,
you
can
like
count
on
me
to
fix
it
at
the
earliest,
but
the
second
part
like
if
you
like,
once
you
go
to
the
repo
and
start
upgrading
you'll,
see
like
pretty
much
everything
fails
so
we'll
have
to
like
individually
look
at
each
instrumentation
adapters.
B
Active
source
adapter
would
fix
like
a
lot
of
them,
but
then
there
are
like
there
were
like
helper
methods
from
the
main
repo
which
was
used
by
the
instrument
used
by
the
control
people.
So
you
mentioned,
like
activity
set
tag
like
something
like.
I
cannot
record,
but
there
is
one
yeah
but
yeah.
If
it
is
not
public
like
to
unblock
just
clone
it,
I
think
literally
copy
paste
it
and
like
keep
it
internal.
I
think
it's
one
of
the
extensions
to
quickly
I
trade,
the
tag
I.
C
B
Something
else
there
is
a
bunch
of
diagnostic
source
instrumentation,
it's
I
mean
at
least
to
begin
with.
I
would
suggest
copy
it
and
there
is
still
a
discussion
like
should
we
like
expose
this
as
public
as
a
separate
package,
not
the
core
open
elementary
sdk
package
we
haven't
like.
I
think
I
don't
think
we
finalized
it.
I'm
not
big
fan
of
exposing
all
this,
because
these
are
like
pure.net
class.
B
E
B
Means
like
some
okay,
some
amount
of
work,
it's
non-trivial
because
we
have
to
like
touch
all
these
projects,
not
just.
C
Right
because
the
the
entire
build
is
a
single
single
entity
and
correct
that
so
after
you
make
the
activity
source
adapter
class
public,
that
would
be
rc2
right,
yeah.
B
Or
like
or
alternately
to
like
make
quicker
progress,
you
can
rely
on
a
daily
build
from
my
gate
like
this
one
is
currently,
I
don't
know
like
where
we
have
mentioned
the
open.
C
Delivery:
it's
if
you
go
to
the
root,
not
in
the
source,
yeah
and
the
build
directory.
C
B
B
You
can
like
wait
one
day
because
the
next
day
it
will
be
in
my
gate,
and
you
can
just
start
like
working
on
this
and,
like
I
don't
know
yet,
when
we
will
release
the
rc2,
we
can
do
it,
it
just
set
it,
but
you
should
not
be
like
blocked
on
that.
You
can
still
use
my
get
feed
which
will
be
published
daily
and
start
unblocking,
yeah
and
like
definitely
like
you
mentioned
in
the
pr
and
try
to
put
it
in
jitter.
So
you
may
get
like
better.
C
Yeah,
we
will
probably
like
tackle
one
project
at
a
time
once
we
upgrade
and.
D
B
So
basically,
we
want
like
each
version
to
have
a
independent
dependency
on
the
main
sdk,
because
if
one
instrumentation
is
ready
to
move
forward,
but
the
other
is
not
it's
going
to
have
the
same,
we'll
have
the
same
problem
again
I
mean
the
present
problem
is
very
specific
to
breaking
apa,
which
will
not
happen
once
we
do
1.0,
but
it
is
still
possible
that,
like
one
of
them
want
to
like
depend
on,
let's
say
instrumentation
for
the
sixers
wants
to
depend
on
matrix
feature
and
they
want
to
use
the
beta
version.
B
However,
the
other
instrumentation
is
not
ready
to
change
to
a
beta
version,
so
we'll
have
these
conflicts
going
forward.
So
yeah,
that's
why
I
said
we
want
to
like
establish
one
a
process
and
second
like
we
need
to
do
like
some
leg
work,
to
really
make
all
these
things
independent,
rather
than
having
anything
common,
including
the
release
and
chx,
so
that,
like
nobody,
is
blocked
on
other
components.
So
that's
the
long
term
plan,
but
at
least
we're
not
solving
it
like
in
one
day.
B
So,
let's
try
to
like
make
all
the
things
which
fees,
which
was
at
least
already
working
initially
make
it
back
to
a
working
stage,
yeah
yeah
and
like
I'll
still
trade,
the
versioning
and
release
of
the
main
one
still
my
priority,
but
it
doesn't
mean
I
won't
look
at
it.
It's
just
that,
like
we
have
too
many
things
to
look
in
the
main
repo,
so.
C
B
Did
mention
like
last
week
that
he
would
be
able
to
offer
him?
He
knows
all
these
instrumentations.
At
least
he
knows
how
instrumentations
in
general
work,
so
he
would
be
like
looking
at
it
as
well.
I
mean
he's
not
here,
but
I
I
mean
I
heard
from
him
that
he
would
be
also
interested
in
fixing
some
of
these.
So
okay.
B
For
any
any
of
you,
and
like
always
do
mention,
I
mean
ask
for
people
in
jitters,
or
maybe
I
think
like
we
are
seeing
like
people
other
than
like
sega,
also
looking
at
it
like
sometimes
michael
look
at
it
yeah
and
like
hopefully
like
us
once
the
one
daughter
is
really
sorry.
I
should
get
like
more
time
to
do
it
also
just
to
like,
even
in
the
country
report,
the
people
who
originally
contributed
this
like
the
mass
transit.
B
They
are
also
like
like
very
much
interested
in
fixing
this,
so
we
can
talk
to
alex,
and
I
forget
the
name.
There
was
one
more
person
who
might.
B
You,
like
picks
one
then
like
just
tell
okay,
we
fixed
it,
others
go
and
follow
the
same
approach.
Yeah.
You
might
have
very
much
better
chances
of
fixing
everything:
okay,
cool
thanks,
okay,
yeah,
so
I'll
just
take
like
one
key
action
item
on
like
from
the
main
ripper,
which
is
to
expose
this
as
public,
and
then
you
can
definitely
bring
us
like
if
there
is
still
something
else
which
is
broken,
then
we
can
look
at
it.
B
B
Yes,
yes,
victor
yeah,
I
mean
I
know
you,
but
I'm
just
saying
like,
since
there
are
a
lot
of
folks
here.
We
just
usually
ask
people
who
are
relatively
new
just
to
introduce
so
each
other.
E
E
You
know:
microsoft
proprietary,
you
know
open
tail
like
sdks
and
so
forth
so
anyway,
so
I'm
looking
to
help
with
hotel
metrics,
where
I
can.
B
I
B
Yeah
yeah
welcome
yeah.
If
you
still
need
like
any
help
like
you
can
always
ping
me
in
jitter
as
well.
I
think
you
you
already
took
like
some
items
writing
from
here.
That's
how
I
reflect
your
name:
yeah
yeah,
if
you're
still
looking
for
more,
like
definitely
like
I've
been
like
creating
issues
more
and
more
every
day
like
we
are
creating
more
issues
than
we
are
solving.
So
if
you
have
more
time
to
help
yeah
happy
to
show
you
something,
absolutely
thanks,
yeah
all
right!
Thank
you!
Everyone.
H
Excuse
me
just
one
thing
that
just
occurred
to
me
and
perhaps
I'll
follow
up
with
the
at
guitar,
because
we
already
one
hour,
but
I
would
like
to
ask
the
aws
folks
what
they
recommend
for
net
aws
open
telemetry
instrumentation
for
lambda.
You
know,
so
I
think
we
are
already
one
hour.
So
perhaps
now
not
the
time,
I
will
I'll
send
you
guitar
and
I
I
hope
you
guys
can
follow
up
there.
Yeah.
B
I
mean
there
is
a
similar
open
issue
for
azure
functions
as
well
like
open
somewhere
here.
G
Just
just
to
follow
up
on
that,
we
we
are
going
to
be
starting
a
lambda
and
platform
sig
just
as
a
umbrella,
open,
telemetry,
sig
meeting,
so
just
keep
an
eye
out
for
that.
We
can
keep
you
guys
up
to
date
on
that
as
well.
Okay,.
B
Yeah,
paulo.