►
From YouTube: 2021-01-13 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).
B
B
Can
you
confirm
you
can
see
my
screen?
Yes,
okay,
yeah.
We
can't
start
if
you
want
to
write
your
name
in
that
indies.
Please
go
ahead
and
do
it.
I
didn't
have
anything
in
the
agenda,
so
I
have
like
few
updates,
but
if
there
are
any
other
questions,
we
can
go
over
it
as
well,
so
we
can
start
with
the
versioning
dock.
It's
marked
from
draft
to
ready
for
review.
B
I've
been
like
doing
some
more
iteration
on
it,
so
my
first
task
is:
please
go
ahead
and
look
at
it.
It
looks
like
I
didn't
get
anyone
to
review
it
after
I
updated
yesterday,
so
this
was
updated
so
which
describes
like
what
is
a
versioning
plan,
and
how
do
we
I
mean
specifically
the
whole
reason
why
we
need
a
detailed
document.
Is
how
do
we
ship
metrics,
given
that
it's
currently
part
of
the
same
repo
same
package
and
metrics
are
not
yet
declared
stable?
B
So
we
discussed
like
three
approaches.
I
mean
it's
not
really
like
three
completely
different,
but
at
least
there
are
enough
examples
to
tell
how
do
we
deal
with
shipping
experimental
features
in
general
and
I'm
using
metrics
and
example,
but
going
forward
we
could
potentially
have
other
experimental
features
as
well.
B
So
matrix
work
will
happen
in
a
parallel
branch.
Let's
call
it
like
matrix
branch,
while
the
master
branch
will
contain
the
stable
signals
like
tracers,
propagators
and
baggage,
and
the
matrix
branch
will
be
versioned
separately.
So
if
you
are
releasing
1.0,
the
matrix
code
would
be
released
as
same
package
but
an
upgraded
version.
So
this
particular
package
would
contain
everything
from
tracing
propagates
from
1.0
and
all
the
experimental
metrics
code
and
eventually
like
as
we
are
close
to
completion
like
we
will
be
doing
a
1.5.
B
I
mean
I
just
picked
like
1.5
is
an
example.
It
can
be
anything.
The
spec
committee
decide
it's
up
to
the
language
which
particular
version
they
want
to
use
main
metrics
already.
So,
let's
assume
it's
1.5,
we'll
keep
really
maintaining
two
branches,
one
for
master,
where
we
can
continue.
Our
active
work
on
traces
on
like
bug,
fixes,
features
everything
and
eventually,
like
once.
B
Metrics
are
ready,
we'll
do
like
one
dot,
five
dot
or
release
which
could
which
would
contain,
like
all
the
work
from
master,
as
well
as
all
the
metrics
work.
B
I
have
like
listed
down
like
some
downsides
with
each
approach,
but
this
one
seems
so
far.
Best
suited
for
any
experimental
features
in
general,
like
matrix,
is
just
one
example,
and
it
also
offers
a
clean
transition
once
we
do
the
once.
We
declare
that
metrics
are
stable.
People
will
be
able
to
just
upgrade
the
version
and
make
no
code
change,
no
name.
Space
change,
no
change
to
entry
point
code,
but
this
was
like
literally
defined
more
like
how
do
we
if
we
go
with
a
different
approach?
What
are
the
downsides?
B
So
don't
think
we
need
to
discuss
it
today,
but
I'm
open
to
discuss
this
if
anyone
has
had
the
opportunity
to
look
at
it
earlier.
Otherwise,
I
expect
to
close
on
this
in
the
next
two
days.
So
please
share
your
comments.
B
I
can
take
any
questions
like
if
there
are
anything
which
is
obvious,
which
I
missed
out.
If
you
already
looked
at
the
pr,
I
can
take
it
now.
Otherwise,
please
share
the
comment
in
the
pr
itself.
B
Okay,
yeah
so
I'll
move
to
the
next
one
and
asking
everyone
to
look
at
it.
We
intend
to
like
get
this
merged
like
sonar,
because
the
the
parent
pr
in
the
spec
repo
is
still
being
still
receiving
comments
and
still
resolving
issues.
But
as
soon
as
we
get
the
green
light,
we
should
have
this
merged
and
then
do
the
actual
execution
and
actual
execution
would
be
a
little
bit
more
involved
than
normal
release.
B
I'll
talk
about
it
in
a
moment,
so
the
one
of
the
other
thing
which
is
coming
out
from
the
versioning
plan
is
again.
This
is
a
recommendation
from
the
spec
which
is
asking
to
release
apa
and
sdk
first
and
delay
the
instrumentation
release.
The
reason
is:
semantic
conventions
are
not
yet
declared
as
stable,
but
there
are
still
discussion
on
whether
we
want
to
offer
any
guarantees
about
semantic
questions
being
same,
but
it
could
be
it's
quite
possible
that,
like
semantic
inventions,
would
be
declared
stable
like
several
weeks
after
the
api
and
sdk.
B
If
that
happens
in
the
spec,
all
our
instrumentations,
including
the
ones
in
the
main
drop,
I'm
not
talking
about
control
every
instrumentation,
which
has
a
dependency
on
semantic
inventions,
would
be
released
after
the
ap
and
sdk.
But
this
is
really
subject
to
what
the
parents
pick.
I
have
the
link
to
the
spec
pr
about
the
same
topic,
so
whatever
is
concluded
there,
we'll
just
follow
it
there,
which
also
brings
another
question
like
we
currently
have.
I
mean,
historically,
all
the
past
releases.
We
did
like
everything
in
one
shot.
B
So
all
the
packages,
all
the
cs
approach,
get
exact
same
version,
so
we
do
not
have
the
ability
today
to
release
like
things
separately,
so
that
is
being
worked
on
right
now
like
it
is
helping
me
and
I'm
doing
some
experiment
with
mingler.
B
There
was
some
proposal
to
use
a
different
tool,
but
it
looks
like
we
can
still
use
manure
and
achieve
this
different
versioning
for
each
project,
so
we
could
do
like
ap
and
sdk
in
one
train,
which
can
be
released
in
one
shot
and
all
the
exporters
in
another
train
and
possibly
all
the
instrumentations
in
it
really
like
train,
which
is
like
really
behind
others.
B
So
we'll
get
more
time
to
release
or
we'll
get
more
time
to
wait
for
the
spec
to
stabilize
another
topic
on
like
really
related
to
it
is
was
what
is
the
status
of
quandary?
Prepo
again
like
there
was
some
discussion
on
this
in
the
spec
meeting
I
didn't.
I
don't
mean
there
was
someone
from
the
spec
meeting
offered
to
write
an
issue
to
describe
the
issues
with
country
prep
and
how?
B
How
are
how
how
some
reports
are
solving
it,
but,
like
immediate
guidance,
is
just
focus
on
ap
and
sdk,
because
we
cannot
look
at
everything
at
the
same
time,
so
I'll
try
to
wrap
up
the
ap
sdk
release
at
the
earliest
and
then
come
back
and
help
with
unblocking
contrib
repo.
It
is
broken
for
two
different
reasons.
One
is
we
still
wait
for,
like
some
official
guidance
on
what
should
go
in
the
contract
repo
and
whether
how
to
do
the
release
management,
how
to
do
the
build
pipeline?
B
Everything
for
the
contrib
repo
and
second
is.
We
have
some
breaking
change
from
the
previous
beta
to
the
current
rc,
which
broke
the
concrete
repo
altogether.
So,
second
one
is
we
don't
need
to
wait
for
like
spec,
it's
just
me.
B
So
we'll
come
back
to
it
like
next
week
again,
hopefully,
by
that
time,
the
spec
the
issue
would
be
opened,
I
don't
know
who
wants
that,
but
I'll
try
to
find
the
link
to
it
by
next
week.
B
I
think
this
is
a
question,
any
guidance,
yet
on
timeline
of
one
dot
or
tracer's
release.
Hopefully,
we
should
be
able
to
do
it
before
end
of
month
unless,
like
spec
committee
says
that
you
cannot
release,
but
it
looks
like
every
language
is
trying
to
do
a
one
dot
or
release
really
soon.
So
I
cannot
commit
like
a
particular.
Do
we
have
a
target
date?
I
know
I
didn't
attend
the
maintainers.
B
Any
commit
anyone
asking
about
it.
It's
just
that
like
as
soon
as
the
versioning
dock
in
the
spec
repo
is
like
allowed
to
merge
then
like
there
is
an
official
guidance
on
what
should
be
the
versioning
strategy
overall
for
open
telemetry,
and
then
it's
on
us
to
merge
our
versioning
strategy
and
then
do
the
actual
release.
Do
you
think
we'll
be
able
to
do
that
by
end
of
this
month,
most
likely
yeah?
I
mean
at
least
for
the
ap
and
sdk
I'm
very
high
confidence
that
it
can
be
released.
B
Instrumentations,
it's
still
an
open.
I
mean
low
strike
of
like
what
was
the
final
conclusion
at
the
end
of
spec
meeting,
because
it
talks
about
like
stability
guarantees
for
semantic
conventions.
B
Yeah,
I
mean
it's
still
discussed
here.
It's
yeah.
I
can
see
that
it's
required
as
record
4g,
so
maybe
like
this
would
like
I
mean
this
would
reach
some
conclusion
earlier.
B
There
are
some
more
I'm
alternate
thoughts
as
well
like,
let's
not
make
any
guarantees
about
semantic
conventions,
unlike
the
ap
and
sdk,
but
anyway
like
if
this
gets
blocked
that
will
block
our
release
of
instrumentation
packages.
It
should
not
affect
the
api,
slash
sdk,
so
very
likely,
we'll
have
apa
and
sdk
for
traces
and
context
and
baggage
by
end
of
this
month.
Maybe
earlier
and
instrumentations
would
come
shortly
after
the
experimental
metrics.
C
C
Specs
to
be
understand
by
then
yeah,
I
think,
from
an
announcement
perspective.
I
know
I'd
written
something
earlier
we
kind
of
commented
on
it.
I
think
we
should
bring
that
back
so
that
we
can
at
least
community
can
announce
that
on
medium
yeah.
I
can.
C
B
I
mean
if
I
think
that
instrumentations
are
also
releasing
at
the
same
time.
We
should
refrain
from
doing
that.
B
Oh
by
the
way,
whenever
I
say
like
sdk,
it
involves
like
spec
mandated
things
for
sdk
like
resource
exporters
for
jager
and
zipkin
and
otlp
as
well.
Those
are
all
like,
I
would
say,
like
a
single
bundle
of
all
the
things
which
has
their
spec
written
for
it,
but
for
instrumentation
there
is
no
spec.
There
are
many
conventions,
that's
why
I'm
putting
it
as
a
separate
thing.
So
when
we
say
when
we
release
ap
and
sdk,
it
definitely
involves
like
the
spec
mandated
exporters,
which
are
like
jager,
zipkin
and
otlp.
B
Again,
there
are
like
few
issues
which
are
still
open.
It's
tracked
in
the
spec
committee,
as
required
for
ga,
so
I'm
hoping
that
they
would
also
see
like
some
action
in
the
next
by
the
next
week.
So
specifically
around
like
what
do
we
do
with
resources?
What
do
we
do
with
mapping
of
resource
to
things
like
that?
So
those
are
relatively
small
things,
but
we
need
that
definitely
before
we
can
call
something
1.0
and
have
confidence
that
we
don't
have
to
regret
it
later.
B
B
Okay,
don't
assume
that
it's
this
suppose
we
are
going
because
it's
just
pr!
I
am
hoping
to
get
some
approvals
so
that
we
can
confirm
that
this
is
approach
we
are
taking.
It
looks.
B
Is
using
different
approach?
There
is
no,
there
is
no
commonality,
as
long
as
like
we
are
not
in
violation
of
the
spec
pr.
It's
still
good.
C
Gotcha
yeah
I'll
just
paste.
I
found
the
link,
I'm
just
gonna
paste
the
link
up
in
the
notes,
oh
yeah
and
I'll
change.
Again.
I
haven't
made
edits
since
the
last
time
we
took
this
up
so
I'll
change
things,
probably
by
end
of
day
today,
as
well
or
most
likely
midday
tomorrow.
If
everyone's
okay
with
that.
B
Right
yeah,
since
we
have,
I
mean
I
lost
like,
is
there
any
agenda,
any
questions
to
be
discussed?
Otherwise
we
can
possibly
go
through
like
a
couple
of
issues
which
I
have
in
my
mind.
But
let's
see
if
there
are
any
questions,
any
pr's
which
require
immediate
attention,
they're
like
quite
loud,
we
merged
few
of
them,
but
then
new
ones
came.
B
We
still
have
like
25
plus
same
as
last
week,
or
at
least
some
of
them
were
merged,
but
if
there
are
anything
which
requires
like
sooner
attention,
please
bring
it
either
now
or
in
the
jitter,
because
I
am
essentially
focusing
on
the
washing
dock
trying
to
do
the
logistics,
because
we
have
to
figure
out
how
to
do
the
exact
release
management.
B
So
I'm
less
focused
on
one
issue.
So
please
bring
it
up.
If
you
require
any
code
reviews
or
anything
else,.
B
Okay,
I
suppose
no
question
so
I
just
want
to
ask
like
one
question:
I
think
this
something
like
alain
was
responding
earlier
and
michael.
So
this
is
something
which
would
help
us
with
the.
B
Many
of
you
know
like
this
is
something
which
we
intended
to
support
the
legacy
activities.
They
are
like
special
activities,
which
does
not
use
activity
source,
which
means
they
don't
run
through
the
samplers.
So
we
invented
like
an
activity
source
adapter
which
has
special
access
to
the
processing
pipeline,
so
we
use
activity
source
adapter
to
run
the
sampler
and
kick
off
the
processing
pipeline.
So
this
is
something
which
was
originally
public
so
like
any
one,
could
write
an
instrumentation
based
on
it.
B
But
then
we
decided
to
market
internal
before
we
were
like
trying
to
do
a
one
daughter
release,
so
we're
trying
to
reduce
the
public
apa,
but
obviously
any
any
repo
or
any
instrumentations
which
were
instrumented
with
diagnostic
source
or
the
legacy
way
they
were
affected
and
there
is
no
easy
way.
We
tried
some
alternates
in
the
control
gripper,
but
it
looks
like
they
have
their
own
issues,
so
there
is
only
I
mean
there
is
no
other
way
like.
B
There
is
no
way
like
completely
third
party,
can
write
an
instrumentation
if
the
activity
is
already
created
in
the
legacy
way.
So
we
need
to
do
like
some
hacks
so
that
connective
whenever
an
activity
is
created
in
the
legacy
way,
it
still
flows
through
the
sdk
concept
of
assemblers
and
processing
pipeline.
B
So
my
easy
proposal
is
just
make
this
public
again,
but
then
the
question
is
like:
should
we
make
it
as
part
of
the
sdk,
or
should
that
be
like
a
separate
package?
That's
what
this
issue
is
about,
if
ellen
or
like
michael,
if
you
have
any
thoughts
which
we
want
to
discuss
now,
we
should
do
it
now,
because
the
only
reason.
A
B
I'm
like
trying
to
do
this
earlier
is
this
would
help
us
with
the
control
ripple
status,
because
we
have
like
many
instrumentations,
which
are
not
usable
right
now,
so
this
would
unblock
some
of
that.
So
I
mean,
of
course,
this
alone
is
not
sufficient.
We
have
to
do
the
actual
work,
but
this
would
be
like
good
step,
one
towards
it.
A
Do
we
have
a
good
sense
of
so
it
sounds
like
the
mass
transit
one.
There's
still
some
conversations
happening
there,
maybe
with
the
authors
of
the
library
to
maybe
get
around
the
need
for
this,
but.
D
A
There
other
ones
that
rely
on
this
that
we
know
are
going
to
be
problematic
without
making
this
public.
B
So
we
are
still
asking,
like
all
other
libraries,
to
migrate
to
the
activities
source-based
ones,
but
then
there
is
a
question
of
what
do
we
do
with
the
older
version
of
those
libraries
like,
for
example,
if
it's
a
dotnet
case,
there
is
no
way
they
are
going
back
and
fixing
all
the
3.0
and
2.0
stuff.
It's
never
backported.
B
So
it
will
only
be
good
for
the
next
version
of
dotnet.
That
is
dotnet
six.
So
if
you
are
using
http
client
from
dot
net
file,
you
would
still
need
like
some
sort
of
hacks
to
work
around
it.
Other
language
I
mean
other
libraries
may
not
be
like
a
strict.
B
I
don't
I
don't
know
like
in
general,
like
dotnet,
is
like
very
strict
about
like
backward
compatibility
but
other
language.
Other
libraries
could
break
the
old
pattern
and
move
to
the
activity
source
one.
But
the
question
is:
do
we
want
to
have
offer
a
way
for
the
old
version
of
those
libraries
like
if
mass
transit
fixes
it
in
their
version?
Let's
say
5.0
what
about
those
versions
of
mass
transit
until
five
dollars
released?
B
B
References,
yes,
they
refer,
they
create
an
activity
and
they
inject
that
activity
themselves.
So
if
we
throw
away
that
and
create
a
new
one,
like
the
correlation
doesn't
work
because
on
the
receiving
side
they
would
have
continued,
I
mean
they
would
have
marked
the
thrown
away
activity
as
their
parent.
D
You
know
there
was
somewhere
else
that
came
up,
I
think,
on
jimmy
bogard's
stuff.
We
were
doing
really
early.
It
was
some
kind
of
queuing
system.
B
So
the
main
issue
with
making
it
part
of
the
sdk.
Let's
assume
that
this
is
made
part
of
the
sdk,
which
would
force
any
instrumentations
to
take
a
dependency
on
the
sdk,
which
would
be
like
somewhat
not
in
the
spirit
of
opponent.
Elementary
because
geometry
says
there
is
a
need
for
separating
apa
and
sdk.
So
instrumentation
should
be
only
using
the
api,
because
they're
not
required
to
know
about
sampling
or
processing
so,
but
unfortunately
like
since
the
our
ap
the
activity
source.
B
B
Part
of
the
sdk
package,
then
all
the
instrumentations
would
be
forced
to
like
depend
on
the
sdk
package,
which
is
not
truly
in
the
spirit
of
open,
telemetry
and
alternate
is.
I
think
this
is
similar
to
what
python
has
done.
We
ship
a
new
package.
I
think
that
was
proposed
here
as
well
like
create
a
new
package
which
will
be
like
open,
elementary
dot,
extensions,
dot,
instrumentation
or
something
which
is
which
tells
that
this
is
only
for
like
legacy
instrumentation.
It's
not
like
a
requirement
for
all
the
instrumentations.
B
D
B
There
yeah
it's
partially,
it
is,
I
mean
it
has
a
reference
to
the
sdk
partially,
because
the
diagnostic
source
helpers
are
right.
Now
in
this
page,
like
this
repo
somewhere
here,
there
is
no
reason
that
this
should
be
in
here.
This
can
be
like
shared
file
mark
internal
or
it
can
be
in
the
api
itself,
because
these
are
not
public
anyway.
These
are
just
internal
helpers.
So
that's
part
of
the
reason,
and
the
other
part
is
what
we
just
described,
because
they
need
activity
source
adapter,
which
is
only
in
the
sdk
repo.
B
So
by
the
way,
I'm
also
trying
to
see
whether
we
can
get
rid
of
activity
source
adapter
and
solve
it
in
the
like
sdk
in
a
different
way,
but
I
don't
have
eddie
and
I
would
be
like
doing
a
draft
pr
like
shortly
after
maybe
that
will
eliminate
the
whole
need,
but
it's
too
early
to
say
that
so
I'm
most
likely
we'll
still
need
to
ship
like
a
separate
package.
B
A
You
know
kind
of
yeah
now
that
I'm
hearing
you
talk
more
about
this
issue,
I
think
yeah.
It
seems
like
there's
some
pretty
compelling
reasons
to
pull
it
out.
Even
this
issue
of
the
contrib
repo
aside,
it
seems
that
it'd
be
great
to
decouple
this
from
the
sdk
anyways,
even
for
our
own
instrumentation,
within
the
main
repository.
A
B
It
sure
I
mean
I'm
not
100
sure
that
we
can
like
do
that
clean
cut,
because
activity
is
always
like.
Whatever
is
a
mechanism,
it
needs
access
to
processors
and
samplers,
and
these
two
are
concepts
which
are
only
in
sdk,
so
we
may
be
like
forced
to
still
depend
on
it,
so
we
may
have
like
transitive
dependency
on
the
sdk,
so
we
may
not,
after
all,
solve
that
problem,
but
this
will
be
restricted
to
only
those
instrumentations
which
are
using
legacy
activities.
B
So
it
could
be
like
a
timing
issue
like
let's
say
that
dot
net
and
like
these
libraries,
all
move
to
the
activity
source
approach
in
their
newer
version.
So
in
that
case,
like
going
forward
in
the
real
long
time
future,
we
would
be
only
asking
them
to
depend
on
the
apa
not
on
the
sdk
but
like
for
a
certain
amount
of
time.
B
It
could
be
very
well
like
a
year
we'll
be
having
that
violation
of
open,
telemetry
spirit
of
splitting
ap
and
sdk,
but
only
for
those
instrumentations
which
created
activity
in
the
legacy
way,
but
I
mean
we
made,
I
mean
I'll,
try
to
solve
it,
but
I'm
not
100
sure
that
we
can
solve
it
and
let
me
also
quickly
see
what
do
we
document
in
our
dog
like
did
we
activity?
Yes,.
B
I
was
trying
to
see
like
whether
we
have
an
sdk
dependency
for
like
these
non-legacy
things,
so
yeah
this
one
two
times
yes,
so
this
is
a
good
example
of
like
proper
instrumentation,
where,
like
it's,
we
are
only
accessing
the
api.
There
is
no
connection
to
sdk,
so
this
would
be
the
true
open,
telemetry
way,
but
unfortunately,
due
to
the
legacy
activity,
creation
we'll
have
to
sacrifice
on
that
requirement
for
some
of
the
instrumentation.
B
I
don't
know
whether
legacy
is
the
right
way,
but
like
an
old
way
of
creating
activity,
and
again
it's
still
possible
for
some
of
them
to
use
the
approach
which
we
tried
with
mass
transit,
which
is
to
ignore
the
activity
and
create
a
new
one
that
should
work
as
long
as
the
original
activity
is
not
used
by
the
library
itself
to
do
the
propagation.
So
it's
tricky
like
we
have
to
like
to
cut
individual
library
and
decide
what's
our
approach
to
be
used.
B
So
I
think
we
used
http
client,
b
or
sp,
not
one
of
them.
We
already
tried
trying
to
yeah.
There
is
a
pull
request
where
we
tried.
I
think
this
one
yeah,
so
we
tried
the
asp.net
core.
It
looks
like
it
is
working.
We
were
able
to
like
throw
away
the
existing
activity.
B
I
create
a
brand
new
one
for
sp
net
core
and
it
looked
like
it
worked,
but
there
are
libraries
where
it
cannot
be
like
especially
the
libraries
which
are
doing
the
propagation
it
may
have
already
did
the
propagation
using
the
old
one.
So
it's
still
like
on
a
case
by
case
basis.
We
had
to
decide,
but
there
is
no
better
way
than
this.
B
B
Second,
is
we
would
create
a
brand
new
package,
we'll
decide
the
name
when
I
submit
the
pr
and
expose
activity
source
adapter
from
that
or
like
extreme
case,
we'll
still
keep
it
a
part
of
the
sdk
and
make
it
public.
So
I
mean
I
don't
think
we
have
to
make
that
decision
today,
because
I
still
need
to
ship
ap
and
sdk
as
the
immediate
goal.
B
So
this
can
potentially
wait
a
little
bit,
but
trying
to
see
if
I
can
get
to
it
sooner-
and
there
is
some
interest
as
allen
was
mentioning
like
mass
transit-
has
already
expressed
willingness
that
they
will
be
able
to
migrate
to
activity
source
adapter.
So
I
listed
down
the
steps
somewhere,
but
probably
hard
to
find
it.
B
B
For
some
libraries,
but
they
may
have
relayed
on
activity
being
always
there,
so
we
we
can
do
like
set
up
our
own
dummy
activity,
listeners
which
would
force
the
activity
to
be
created
in
the
propagation
only
mode,
so
it
will
be
created
and
it
will
satisfy
the
backward
compatibility
requirement.
B
But
since
the
actual
sdk
I
mean
without
running
the
actual
sdk,
it
will
not
be.
Like
I
mean
without
running
the
actual
sampler,
the
activity
will
never
be
promoted
from
the
propagation
state
so
that
it
won't
be
seen
by
processor
or
exported.
So
I
listed
on
it
somewhere
in
one
pr.
I
little
bit
lost
track
of
it,
but
it's
the
same
ask
which
we
have
from
dotnet
team.
Also.
B
Linked
okay,
I
need
to
find
that
I
created
like.
Let
me
actually
let
me
share
that
link,
so
everyone
can
take
a
look
at
it.
So
one
second,
let
me
find
that
list
of
issues
which
we
want
fixed
from
the
dotnet
runtime.
So
let
me
get
that
list.
B
Just
one
moment
I
am
just
opening
the
right
window
yeah.
So
this
is
the
issue
opened
in
sp
net
core
to
track
the
migration
from
the
legacy
activity
api
to
activity
source.
So
it's
described
like
how
do
we
want
to
achieve
it?
There
are
some
discussions
on
it
going
on
so
yeah.
Please
share
your
comments
as
well.
So
basically
it
boils
down
to
replacing
all
the
new
activity
api
with
activity
source
and
to
maintain
the
backward
contact
compatibility.
B
It
sets
up
a
like
activity
listener,
which
sets
something
to
propagation
data.
So
when
the
actual
open
elementary
based
listener
is
added,
its
decision
will
get
priorities
like,
for
example,
it's
just
a
accumulative
result
of
all
the
activity
listeners.
B
So
if
there
is
one
listener
which
is
propagation
and
then
there
is
open
elementary,
which
says
like
propagation
and
record,
then
record
will
be
the
one
which
wins
because
that's
higher
than
propagation,
so
it
should
maintain
backward
compatibility
and
like
saurop
from
like
asp.net
core,
he
said,
he'll
give
a
like
draft
pr
trying
to
migrate
sp
net
core,
so
that
could
be
like
used
as
a
reference.
I
I
also
tried
asp.net,
not
esport.
There
is
asp.net
repo,
which
is
independently
managed
and
independently
version,
so
I'm
also
trying
that
one.
B
It's
just
said
it's
lower
in
priority,
because
priority
has
been
to
ship
the
ap
and
sdk,
but
yeah
please
do
like
if
there
are
like
issues
which
you
want
are
trust
in
the
like
dot
net
six
in
the
dot
net
runtime,
please
feel
free
to
open
an
issue
in
the
runtime.
It
looks
like
we
open
like
bunch
of
issues.
B
One
is
this
and
then
there
is
issue
about
exposing
propagated
cpa
in
the
dot
net,
and
then
there
is
aws
ask
now
it's
a
spec
ask
as
well
to
allow
customization
of
trace
id.
So,
although
some
are
tracked
in
the
dot
net,
runtime
repo,
so
it's
still
okay
to
open,
because
we
haven't
left
the
deadline
for
dot
net
six,
it's
still
early
enough,
so
we
can
feel
free
to
open
issues
either
here
and
we
can
transfer
it
or
we
can
directly
open
the
runtime
group.
B
Oh
yeah.
This
is
just
get
posting
the
link
right
here.
Okay,
any
other
topics
to
discuss
and
yeah
get
shared
the
to
be
released,
dot
net
g
announcement,
it's
still
draft.
So
please
share
your
comments
here.
This
is
going
to
be
like
this
is
going
to
be
like
published
in
the
open,
telemetry
medium.
B
B
Okay,
yeah,
we
can
end
early
but
like
just
a
remainder,
please
take
some
time
to
review
the
versioning
dog
and
also
it
has
links
to
the
specification
reports.
Versioning
dog.
We
should
be
in
alignment
with
that.
So
please
do
the
release.
That's
my
major
focus
for
the
next
few
days,
just
to
get
the
one
daughter
out.
B
Okay,
thank
you.
We'll
see
you
again
on
next
week.