►
From YouTube: 2021-11-17 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
A
C
C
A
Okay,
then,
let's
get
started
so,
let's
start
with
the
ceremony.
So
let's
start
with
the
pull
request
review,
so
we
have
a
bunch
of
them
right
now.
Is
there
anything
in
particular
that
I'm
going
to
start
on
or
should
we
go
from
the
top
to
the
bottom.
E
All
right
anyway,
so
basically
the
guys
released
the
server
version
5.1,
but
there
is
actually
no
c-sharp
driver
for
that
version.
That's
pretty
interesting
issue.
A
A
E
E
So
there
I
think
there
is
a
action
template,
but
I'm
not
sure
if
it
takes
care
of
it
or
not.
B
So
I
I'm
missing
something
in
my
understanding
here.
I
thought
for
the
windows
run
of
the
pipeline.
It's
still
launching
the
container
because
we're
not
spinning
up
anything
directly,
no.
B
A
B
Nope,
just
looking
for
feedback,
I
threw
out
some
questions
that
to
try
to
jumpstart
some
of
the
discussions.
So
as
you
have
time,
please
take
a
look.
B
And
I'll
I
plan
on
having
a
follow-up
of
this,
where
I
want
to
experiment
with
trying
to
enable
the
startup
hook
from
the
profiler
to
see
if
that
gets
us
around
some
of
the
assembly,
loading
issues
that
I'm
seeing
when
using
the
profiler
to
bootstrap
everything.
But
it
will
not
work
for
dotnet
framework
right
correct,
but
I
haven't
seen
this
issue
happen
in
that
framework.
D
One
question
here:
I
I
missed
one
of
the
meeting:
did
david
come
back,
how
to
use
the
enable
the
startup
from
the
managed
code
did
he
like
profiler
did
the
answer
that
question?
We
had
a
question
for
him
earlier.
D
B
B
A
So
next
one,
so
this
is
only
for
the
pandabot
and
we
should
we.
A
B
Right
so
I've
just
been
keeping
it
around
for
now
until
we
update
the
sdk
dependencies
so.
D
So
this
has
the
additional
depth
support,
for
example
like
if,
if
you
try
to
load
a
dotnet,
sorry
system.diagnostic
source
six
version
to
a
3.1
app,
it
will
immediately
crashes
the
moment
we
provide
additional
depths
and
the
assembly
probing
happens
through
that
way.
It
won't
crash
the
application
in
those
scenarios.
D
So
you
know
it's
a
workaround
for
that.
If
you,
if
you
could
go
to
the
files
changed
and
we
had
a
sample
already
in
our
project,
I
think
that
cs
project,
if
you
look
at
it
and
the
one
above
that
the
sample
one
mvc31.cs
approach
this
one
yeah.
D
D
So
I
did
some
changes
to
the
test
projects
also,
and
I
removed
it
because
I
wasn't
like
sure
whether
that,
because
this
all
worked
locally
and
it
failed-
so
I
was
wondering
like
it
was
my
problem
or
that
that's
why
I
removed
the
test
changes
from
this.
So
I
can
get.
There
are
few
other
changes.
I
did
I'll
revert
back
those
once
the
other
testings
is
fixed.
A
D
So
I
think
we
need
to
it's
going
to
change
the
tracer
like
if
you
go
and
look
at
the
the
image
which
I
have
attached
in
the
summary
it's
going
to
change
the
tracer
home
directory
a
little.
We
are
going
to
add
additional
two
folders
in
the
tracer
home,
like
if
you
look
at
it
in
the
tracer
home
the
image.
If
you
look
at
it,
the
tracer
home
has
a
folder
already
called
this
netcore
app
3.1
within
that
we
have
32
files
already.
D
So
what
we
are
going
to
do
is
we
are
going
to
add
an
additional.
This
pr
is
going
to
add
that
store
folder
and
the
additional
depth
folder
to
the
the
tracer
home
and
like
we
need
to
use
that
two
different,
like
environment
variable,
which
is
provided
by
the
dot
net
to
point
to
those
locations.
D
So
that's
how
this
magic
happens.
So
this
and
this
pr
brings
the
the
folder
structure
creation-
whatever
has
happened
over
in
this
place,
so
even
the
logging,
whatever
we
are
speaking
right
like
we,
we
had
an
issue
like
to
bring
the
open,
telemetry,
logger
library.
Also,
there
are
a
few
projects
we,
where
we
have
the
logger
library
package
also
referenced.
We
can
add
that
also
to
this
additional
dependencies
and
we
can
remove
all
those
from
that
actual
project
that
will
be
one
line
of
code
changes.
D
We
just
need
to
add
a
package
reference
to
the
additional
dips
cs
approach
in
the
which
is
bought
off
in
this
pr.
D
D
It
uses
two
different
concepts:
one
is
the
additional
dependencies
and
the
like
runtime
package
store
of
the
dotnet
like
the
latest.net
versions,.
D
But
still
it
does
not
resolve
one
per
one
thing:
for
example,
if
I
have
a
dot
net
3.1
app
and
if
I
have
a
reference
of
system
diagnostic
source
to
5o,
and
if
I
still,
if
I
use
a
additional
dips,
it
won't
upgrade
me
to
the
latest
version,
because
if
someone
has
a
library
which
is
go
which
goes
to
the
bin
folder,
we
don't
upgrade
auto
upgrade.
In
that
scenario,
and
in
those
cases
we
need
the
diagnostic
proxy
which
is
proposed
in
the
other
yeah.
A
D
But
this
should
cover
like
if
we
have,
like
I
heard
from
like
dot
net
team,
I
had
a
discussion
with
them.
They
said
if
there
are
hundred
percent
of
apps.
90
of
them
are
of
framework
dependent,
apps
and
10
percent
are
self-contained,
so
this
is
not
going
to
help
the
self-contained
place
and
in
that
90
percentage
this
whatever
we
are
doing.
This
approach
should
solve
issues
in
60
percent
of
the
case
in
that
90..
D
One
yeah:
it's
not
complete,
I
just
provided
a
skeleton.
It's
a
this
work
is
going
to
take
a
long
time
for
us
to
complete
it.
It's
not
a
very,
simpler
proposal,
so
we
just
added
a
structure
because
we
are
going
to
have
whatever
the
instrumentation
that
we
are
going
to
support.
We
are
going
to
have
a
listener
for
that
and
just
there
do
you
think
that.
A
Because
I
look
at
the
pr
and
for
me
it
will
look.
I
understand
also
thanks
to
the
chris
comment,
that
this
is
important
for
a
use
case
when
someone
does
not,
for
example,
do
not
want
to
use
that
dotnet
profiler
right,
correct,
just
to
use
the
hook
even.
D
With
yeah,
even
with
dot
net
profiler,
this
code,
whatever
the
code
we
are
going
to
write
in
this-
can
be
used
within
the
dot
net
profiler
and
the
startup
hook.
So
this
is
common
for
both
of
it.
D
D
A
Correct,
maybe
I
told
it
wrongly
because
I
had
a
proposal
to
make
a
bad
code
instrumentation
of
you
when,
when
someone
is
using
diagnostic
source,
but
then
this
would
not
work
for
startup
hook.
Only
and
the
only
problem
I
personally
see,
but
maybe
my
eyes
are
wrong-
is
that
it
will
be
a
very
a
burden
for
maintenance.
D
That
is,
it
is
difficult
for
us
to
maintain
it.
So
this
is
a
general
structure.
We
need
to
come
up
something
generic,
so
I
ran
this
through
the
with
the
dotnet
team
internally
also
like
like.
D
The
main
the
question
that
is
put
forward
to
us
is
like
two
things:
one
is
creating
that
the
diagnostic
listener
and
second,
is
like
the
maintainability.
D
So,
whatever
the
approach
we
are
going
to
take,
all
of
that
is
going
to
have
the
same
problem,
because
there
is
some
because
open,
telemetry
sdk
is
not
going
to
listen
directly
on
these
things
because
it
won't
load
in
that
context.
So
we
need
something
else
to
listen.
Even
now
the
earlier
vendored
approach
or
the
I
reviewed
that
even
before
this
proposal-
and
there
are
other
proposals,
so
I
reviewed
all
of
them
in
all
of
them.
D
We
need
intermediate
guy
to
listen
to
the
diagnostic,
the
activities
created
in
the
legacy,
dot
net
versions,
and
then
we
have.
We
need
to
take
that
and
convert
into
a
new
legacy
activity
and
in
those
cases
we
also
should
be
loading
our
like
open,
telemetry
sdk
in
the
instead
of
now
we
are
loading
it
in
the
app
context.
In
those
scenario,
we
don't
load
in
the
app
context.
Rather,
we
will
have
in
our
own
context
that
change
will
also
come
in
this,
I'm
also
pushing
like
the
dot
net.
D
Runtime
team
like
there
is
a
conversation
going
on
from
my
aim
to
check
if
they
can
provide
additional
depths,
make
it
a
real
like
it's
a
little
better.
So
we
don't
need
to
do
this
at
all.
So,
for
the
time
being,
we
will
have
this
and
once
like
the
dotnet
matures
at
least
in
dot
net
seven.
We
don't
need
to
do
this.
We
can
a
diagnostic
source
or
any
up
like
library.
D
A
D
Same
yeah,
we
even
microsoft,
want
to
support
for
all
the
dot
net
version,
so
if
we
say
all
dot
net
version,
even
dot
net,
six
is
not
going
to
get
that
change.
So
whatever
we
are
planning
the
dot
net
team
is
planning,
it
will
be
from
dot
net,
seven
and
onwards
and
dot
net.
Six
is
a
long
time
supported
dot
net
version.
So
we
need
some
approach
like
this
like
to
take
this
forward.
B
Yeah,
so
when
I
looked
at
this
approach,
one
of
the
things
that
stood
out
to
me,
maintenance,
wise,
was
having
to
define
the
individual
proxies
and
perhaps
that's
something
that
the
the
source
generators
might
be
able
to
help
with
some
of
that
burden.
If
we
were
able
to
to
have
one
that
could
auto
generate
some
of
that.
For
us.
D
So
the
only
problem
is,
I
did
reviewed
like
the
open,
telemetry
sdk,
how
their
the
diagnostic
listeners
has
written,
that
they
have
done
an
in
on
start
and
on
in
for
each
and
everything
for,
for
example,
if
they
listen
on
asp.net
core,
they
have,
they
are
creating
a
specialized
activity
within
the
onstart.
The
open,
telemetry
sdk
creates
a
activity
there,
so
it
just
don't
listen
on
what
is
being
provided
by
an
app.
So
that
does
not
happen
with
the
http
client.
D
So
that's
the
reason
for
us
to
do
this
if
they
have
like
a
common
approach,
maybe
I
like
I'm
just
taking
a
closer
look,
and
there
is
a
plan
in
open
telemetry
to
move
to
the
completely
to
the
active
source
instead
of
using
diagnostic
listener,
when
once
they
move
there,
we
might
not
need
this
many
diagnostic
listeners
if
we
have
a
some
one
diagnostic
listener,
that
would
be
enough
to
call
all
the
onstart
and
on
end
method
in
the
sdks.
For
us.
D
I
think
this
requires
a
lot
of
brainstorming
from
all
of
us,
but
I
I
feel
the
additional
depth
is
far
more
simple,
and
that
does
nothing
apart
from
creating
some
folder
structure
and
putting
some
libraries
there,
which
enables
the
lot
many
applications
to
get
benefited
without
any
of
these,
like
impact
like
using
proxy
or
any
of
these.
F
G
I
have
one
question
that
I
didn't.
I
didn't
have
a
chance
to
look
at
this,
yet
I've
been
swamped
with
other
things.
I
understand
the
procs
for
different
versions,
but
how
we
deal
with
the
following
that
these
statics
for
activity
are
going
to
be
different
for
each
version
of
the
library.
G
So
when
you
are
creating
children
activity,
how
how
that
is
gonna
be
covered.
D
We
need
to
clone
the
entire
activity
id
like
even
the
ids
and
everything
should
match
whatever
we
are
going
to
create,
because
we
have
an
activity
which
is
from
the
diagnostics
source,
lower
version
and
we
are
going
to
create
an
activity
in
the
diagnostic
source,
higher
version.
So
when
we
create
an
activity,
we
need
to
create
in
such
a
way
it's
going
to
have
all
the
ids
and
parent
id
in
the
same
way.
So
it's
going
to
be
a
clone
over
there,
but
we
are
creating
in
the
higher
version
and
open
telemetry.
D
G
D
I
had
a
like
a
discussion
with
the
endeavor
like
that.
Like
tariq,
I
don't
know
you
guys
he
joins
this
meeting.
I
joined
yeah
he's
the
developer
of
the
diagnostic
search,
so
I
had
a
discussion
with
him
like
about
like
I
was
speaking
about
it,
the
performance
constraint
of
creating
a
new
activity.
He
does
not
see
that
as
a
like.
A
big
perf
concerns
that
we
are
going
to
like
hit
that.
G
Yeah
for
me,
actually
I
at
this
stage,
I'm
more
concerned
about
losing
the
contacts.
Let's
say
if
a
lower
version
creates
a
span
based
on
its
current,
how
that
is
gonna
work
like
think,
okay,
we
have
three
versions
very,
very
worst
case
scenario
and
we
have
the
lower
version
and
something
is
instrumented
with
that
activity
and
it
creates
based
on
the
context
of
whatever
is
on
that
version.
You
know,
so.
Basically
we
have
to
ensure
that
all
these
contacts
are
keeping
kind
of
in
sync.
G
D
D
The
thing
is
that
like,
if
you
look
at
the
issue
which
I
proposed
with
the
diagnostics,
I
have
an
issue
also
created
for
this.
So
there
are
two
things
I
propose
in
that
issue,
so
one
is
the
workaround
to,
for
this
is
used
to
do
the
additional
dips,
which
is
a
simpler
thing,
which
is
like
say,
which
I
said
we
have
an
android
app
60
apps.
It
takes
cares
of
that,
so
only
for
the
40
apps.
We
need
that
this.
D
D
D
We
have
a
one
single
problem,
but
that
can
be
like
solved
in
two
different
ways.
The
first
pro
like
solution
is
additional
dips,
but
that
is
not
going
to
solve
our
problem
hundred
percent
of
the
times
it
will
solve
it
like
to
the
sixty
percent
time.
So
that's
what
the
additional
depth
is
and
remaining
forty
percent.
We
need
to
have
a
different
approach
to
cover
it,
so
that
is
what
it
will
be
covered
by
the
diagnostic
source,
proxy.
G
So
from
your
perspective,
which
of
the
two
paths
should
be
kind
of
priority,
if
you
had
to
choose
one
kind
of
which
should
come
first.
D
Additional
hundred
percent,
because
that
is
not
going
to
have
any
perf
impact
during
the
like
run
time
before,
like
the
app
even
gets
started
the
startup
book
or
the
like
the
profiler
gets
invoked.
We
will
have
this
probing
path
set,
so
app
will
feel
that
it
has
its
own.
It
has
everything
to
load
the
open,
telemetry
sdk
with
the
latest
diagnostic
source
into
the
its
context.
So
no
overhead
at
all.
There.
D
It
is
still
not
a
blocker
yeah,
but
if
you,
if
you
look
at
it,
if
we
have
a
cases
like
in
which
is
running
serverless
environment,
you,
we
cannot
definitely
ask
like
most
of
the
customers
who
use
like
the
instrumentation
may
not
own
their
project.
You.
D
It
is
based
on
our
experience.
It
is
not
actually
okay.
D
D
D
A
So,
do
I
understand
correctly
that
right
now
the
plan
is
to
like
the
proposal
is
to
like
merge
and
use
these
additional
adapts
and
then
follow
up
and
maybe
build
this
pro
and,
in
the
background,
do
something
for
the
proxy
correct.
D
So,
like
additional
depth
says
like
it's
completely
ready
and
we
can
take
that
and
use
it
now.
The
other
proposal
needs
a
brainstorming
from
us
to
take
it
and
we
need
to
go
slower.
D
D
No,
I
just
wanted
like
like
moving
the
additional
depths
to
like
towards
the
closure,
will
benefit
us,
so
we
will
get
that
reviewed
if
possible.
A
B
Yeah
my
only
question
for
this
one.
I
would
have
hit
the
merge
if
it
wasn't
for
the
mongodb
failures,
and
so
I
just
wasn't
sure
if
we
just
wanted
to
merge
it
anyways
or
hold
off
until
we
get
the
mongodb
stuff
resolved.
E
A
Okay,
so
that's
all
for
dprs
next
next
step
is
the
project
board,
so
in
pro
in
progress
we
have.
We
were
talking
about
this
issue
already,
so
I
want
to
talk
right
now,
a
little
bit
about
this
one,
and
basically,
I
had
also
described
notes
even
for
myself
here.
There's
one
thing
I
want
to
discuss
or
basically
simplify
or
to
be
more
effective
in
the
initial
proposal
here
I
propose
to
support
the
auto
propagators
and
otl
trace
exporter
and
vmf
variables.
A
A
Sdk
first
is
that
the
problem
is
that
this
will
require
some
registration
for
propagators,
some
probably
additional
nougat
packages
to
not
tightly
couple
the
sdk
to
the
propagators
and
the
otlp
exporter,
which
is
the
default,
etc
and
there's
one
problem
so
like
technically
two
week.
Long
second
problem
is
that
december,
a
lot
of
guys,
especially
in
u.s,
usually
take
a
break
and
also
it
might
be
not
the
number
one
priority
right
now.
A
G
Just
to
confirm
one
thing
just
to
I
think
confirmed
and
everybody
gets
on
the
same
page,
the
audio
exporter,
by
default,
it's
grpc,
but
is
configurable
to
be
over.
A
Correct
by
even
even
without
changing
yeah,
so
even
with
hard
coding,
these
two
values,
the
otlp
exporter-
is
already
configurable.
I
just
need
to
document
it.
It's
already.
The
version
from
this.
The
exporter
from
the
sdk,
already
supports
the
environmental
variables.
I
think
it
was
implemented
by
david.
B
A
Could
repeat
you
mean
which
part
or
maybe.
E
Rephrase
I'm
not
should
find
understanding,
I
mean
like
for
how
the
guys
are
doing
so.
Basically,
if
you
want
to
have
like
two
different
exporters,
then
you
need
to
reference
two
different
nougat
packages,
exactly
which
means
they
don't
have
any
point
to
implement
multiple,
proper,
this
kind
of
multiple
properties
they
want
to.
I
they're
open
to
that.
A
Is
also
bad
yes,
so
there
I
was
discussing
with
cgo,
so
we
could,
for
example,
have
some
nougat
additional
nuget
package,
which,
for
example,
contains
some
exporters,
or
you
know
some
api
to
register
to
like
to
have
something
like
you
know,
like
you
have
like
dependency
ejection,
that
you
register
some
exporter,
that
if
an
environment
environment
variable
will
set
a
value,
then
this
exporter
will
be
loaded,
etc.
So
there
are
some
ideas:
how
to
implement
it
still
in
the
sdk
and
implement
this
plug-in
architecture
but
yeah.
A
I
know
it
will
it's
not
simple
and
I
don't
know
how
fast
it
will
be
to
you
know,
have
an
agreement
on
sdk.
That's
why
I'm
proposing
this
and
postponing
it,
but
they're
open
basically
to
to
have
it
in
the
sdk.
Even
they
want
to
have
it
in
the
sdk,
because
I
was
asking
directly
do
they
want
to
support
such
environment,
very
business
decay
and
that
service?
Yes,
they
want.
A
And
so
so,
basically,
probably
I'll
be
able
to
even
refine
this
issue,
and
this
will
mean
that
the
issue
of
using
mock,
zip
king
collector,
which
was
created
recently,
which
I
will
just
maybe
show
right
now,
will
be
like
mandatory
for
the
beta.
A
So
I
will
just
quickly
open
it
and
tell
what's
the
setup.
What
is
it
about
so
right
now
the
the
integration
tests
are
using
the
zipkin
exporter
and
we
have
a
mock
zip
in
collector
to
validate
this,
the
the
exported
spans.
A
Okay,
if
nobody
interrupts
I'm
going
to
the
next
issue,
the
next
issue
was:
is
this
one
is
about
setting
this
trade,
this
w3c
propagators
right
now,
there's
none.
So
I
think
in
my
perspective,
we
should
have
some
propagators
from
the
beta
still
because
it's
a
very
useful
or
you
think
it
could
be
done
after
the
beta.
G
A
Yep
so
putting
it
here,
support
4.6.
I
also
created
this
one
just
before
the
meeting,
and
I
think
it
should
because
dotnet
6
is
lts
and
I
think
that
the
the
most
recent
the
release,
which
is
not
yet
for
the
open,
telemetry
support.6
right
now.
I
think
that
the
sdk
does
not
support
dotnet
six,
but
questions
may
be
to
others,
maybe
to
data
doc
and
neuralic.
Is
there
anything
the
profiler
that
had
to
be
changed
to
to
work
with
dotnet
six
or
it
was
just
working.
H
It
should
just
work,
although
if
there's
some
by
code
stuff,
but
if
there's
bicone
instrumentation,
that
has
like
an
assembly
version
range
that
could
be
affected
because
we
have
that
datadog,
where
we
were
like
very
specific
on
what
assembly
versions
to
instrument.
So
we
we
have
to.
We
had
to
upgrade
that
to
six
versus
just
include
like
five
inclusive.
B
An
issue
was
discovered
where
at
least
for
http
client
instrumentation,
depending
on
how
you're
accessing
response
headers-
and
I
don't
know
if
this
instrumentation
is
dealing
with
response
headers
at
all,
but
there's
some
issues
with
accessing
them
in
an
async
fashion,
which.
H
H
Okay,
that's
good
to
know,
I
don't
think
in
this
repo
there's
anything
affecting
response,
headers
nope
datadog.
We
do
have
one
feature
to
do
that
so
I'll
be
sure
to
take
a
look
at
that.
So
thanks.
B
H
B
Want,
I
want
to
say,
the
yarp
team
discovered
it.
G
G
This
tool
should
not
have
the
instrumentation.
As
far
as
I
remember,
the
bytecode
doesn't
have
directly
dependence
on
anything
from
the
framework
they
depend
on
other
libraries,
so
I
I
think,
as
long
as
the
packages
that
we
are
getting
from
the
sdk,
we
should
be
good,
but
I
like
to
have
the
thing
there.
So
we
add
specially
tests
for
that.
B
B
A
G
I
I'm
I'm
gonna
say
that,
as
let's
switch
from
the
five
to
six,
when
you
do
this
because
of
the
falling
people
that
are
going
to
be
trying,
these
are
the
brave
people
anyway.
So
it's
much
more
like
that
they're
on
six
than
they
are
on.
G
A
A
B
Something
I
I
don't
really
have
anything
to
add
there.
A
B
Do
we
want
to
have
an
issue
for
updating
the
sdk
dependencies.
A
G
I
I
think
we
should
talk
about
the
the
holidays,
I'm
I'm.
I
have
a
bunch
of
vacations
because
of
pandemic
that
I
didn't
take
yet
so
to
not
let
them
go
away.
G
I
gonna
take
a
bunch
of
vacations
this
end
of
the
year
so
next
week
I
won't
be
here
then
I
think
I'm
here
for
one
or
two
weeks,
the
first
two
weeks
of
the
last
week
of
the
first
few
weeks
of
december,
and
then
I
I
just
come
back
in
january,
so
I
think
we
need
to
communicate
just
to
avoid
if
people
show
up
for
the
meeting-
and
there
is
nobody
you
know
so.
G
G
B
G
So
I
think
then
we
should
communicate
that
we
will
have
the
meeting.
Let
me
just
double
check
here.
G
We
skip
next
wednesday,
the
24th,
and
then
we
have
december
1st,
8th
and
then
and
then
that's
it.
For
the
year
we
come
back
on
the
january
5th.
G
All
right,
are
you
I'll
put
some.
I
I
update
calendars
and
do
this
stuff
to
to
be
sure
that
everyone
gets
a
notification,
be
careful
because
I
just
have
access
to
the
open,
telemetry
calendar
and
once
I
do
that,
if
you
create
your
own
on
your
own
calendar
property
is
not
going
to
be
cancelled.
It's
going
to
still
be
there,
but
I
have
put
perhaps
a
notes
in
the
docker
somewhere
that
we
are
just
going
to
have
that
and
that
meeting
until
the
end
of
the
year.