►
From YouTube: 2020-09-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
B
A
A
A
Okay,
I
think
we
can
start
looks
like
we
have
a
new
member
here
michelle.
How
are
you
here,
yeah
yeah
hi
hi
welcome.
Well,
would
you
give
a
quick
introduction.
C
Sure
so
yeah
I
am,
mr,
like
I'm
currently
once
again
yeah.
I
just
graduated
from
computer
science
and
engineering
from
an
idea
from
india
and
yeah,
I'm
currently
working
at
cisco
and
looking
forward
to
contribute
to
the
hope
of
open,
telemetry
cpp
group
with
the
community
bridge
program.
That's
it.
A
Yeah
great
welcome,
thank
you
so
we'll
have
this
week.
Yeah
we'll
have
this
weekly
meeting
and
I
am
the
maintainer
here
and
we
have
approvers,
johannes
and
max
here,
also
like
thomas
coming
help.
Here
we
got.
A
We
got
two
interns
from
amazon
karen
and
mark.
B
Wait
riley
her
question:
can
we
shift
the
time
of
this
meeting
to
morning
because
oh
yeah,
I
think
michelle
and
a
couple
other
folks?
They
are
interested
in
contributing
to
etw
exporter
and
they
are
all
in
way
different
time
zones.
So
what
time
is
it
right
now
for
you,
it's
probably
late
night
yeah,
it's
3
30
in
the
morning,
oh
crazy.
A
It's
it's
crazy,
yeah!
Sorry
for
that
I'll
original
yeah.
I
think
we
talked
about
shifting
the
time
like
every
week
will,
depending
on
like
whether
it's
the
primary
one
or
the
secondary
one.
So
primary
wall
this
time
for
the
secondary
meeting
will
shift
to
the
early
morning
like
the
pacific
time,
and
then
it
will
be
a
little
bit
late
night
for
your
guys
at
least
that's
better
than
3am.
A
A
Yes,
the
last
time
I
checked
with
morgan,
I
I
think
we
got
a
conflict
but
I'll
check
today
to
see
if
we
can
move
that.
So
I
have
one
topic.
I
want
to
briefly
update
the
sig
on
the
login
prototype
site,
so
I
have
created
one
issue
and
currently
is
assigned
to
mark
and
karen-
and
here
goes
the
summary
of
what
we
think
we
can
achieve.
A
So
the
high
level
thinking
is
to
have
the
prototype
like
in
the
open,
telemetry
logging
say
there
are
two
work
streams.
One
is
more
like
aligned
with
the
long
term.
We
want
to
explore
whether
we
have
some
new
logging
api
and
build
the
spec
and
sdk
on
top
of
that
or
there's
another
short
term
work
stream,
which
is
saying
for
languages
that,
like
which
already
has
the
the
established
or
famous
logging
api.
We
should
just
go
and
enable
that,
and
currently
the
open,
timesheet
protocol
already
has
a
version
of
the
spec
for
logs.
A
So
one
thing
we're
thinking
similar
like
how
jager
and
deep
king
work
it
gives
people
a
local
experience.
They
can
see
something
very
the
data
flows
in
and
gives
something
better
than
just
a
a
console
exporter
so
for
logs.
A
I
think
aws
is
interested
in
the
elastic
search
story
and
in
general,
in
a
logging
sig
we're
also
seeing
the
the
ecs,
which
is
the
elastic
common
schema,
has
a
big
influence
on
the
the
current
work
stream.
So
here
we
want
to
explore
having
the
logging
api
and
having
the
exporter
story,
sending
data
to
elasticsearch,
so
people
who
have
the
local
elk
stack
running.
They
should
be
able
to
see
the
logs
and
do
some
virtualization
and
there's
some
stretch
goals
for
them.
A
A
A
So
for
the
the
current
internship,
so
I
I've
committed
myself
to
spend
like
one
to
two
hours
a
week
with
our
two
interns
and
we
have
scheduled
the
like
initial
call
and
I
hope
that
can
help
them
to
ramp
up
and
if
they
need
any
help
on
the
pr.
So
please
try
your
best
effort
to
give
them
comments
and
I'll
I'll.
Take
the
major
work
there
to
reveal
and
make
sure
like
they're
heading
towards
the
right
direction.
D
D
A
A
Yeah,
thank
you,
and
I've
also
seen
some
of
the
recent
activities
from
from
lalit.
So
once
we
have
him
joining
the
meeting,
we
can
discuss
more.
So
the
recent
open,
telemetry
spec
has
some
changes
and.
A
Last
time,
I
think
when
we
look
at
the
the
spec
like
feature
matrix,
we've
identified
all
the
gaps
for
the
tracing
part.
Now
there
are
more
changes
coming
so
I'll
I'll
need
to
go
through
that
again
and
probably
file
some
issue
and,
like
I
wonder
like
like
how
how
should
we
manage
the
the
current
github
project.
D
A
D
But
this
week
she's
on
vacation,
so
I'm
not
sure
yet
in
how
far
she
will
have
time
to
help
I
mean
otherwise.
I
will
take
over
the
project.
A
A
And
the
latest
spike
has
a
change
on
the
span
status,
so
it
changed
from
like
the
original
grpc
code.
To
now,
only
like
three
status
either
is
like
onset
or
we
know
it's
a
failure
or
the
customer
can
override
that
to
a
success
if
they
believe
they
don't
they
don't
care
about
the
underlying
details,
I'll
create
that
issue
for
tracking
and
that's
all
the
topics
from
my
side,
any
other
topics,
if
not
I'm
going
to
quickly
look
at
the
pr.
E
A
So
this
is
the
current
policy,
okay,
awesome
and
in
general,
I'm
trying
to
follow
that.
But
there
are
minor
cases
where
we
we
don't
like
it's
hard
for
us
to
wait
for
two
approvals,
I'll
make
some
exception
depending
on
whether
the
pr
is
trivial
or
it's
a
relatively
big
change,
and
normally
I
I
would
wait
for
one
day
just
to
give
you
all
enough
time
to
comment.
So
sometimes
I've
seen
like
people
try
to
ping
me.
I
got
a
pr
and
you
approve
please
go
and
merge
that
I'll,
explain
like
in
general.
A
Yeah
and
if
you
think
this
is
something
that
we
got
to
improve
or
something
really
doesn't
make
sense,
given
the
current
status,
I'm
open
for
changes
and
whatever
thing
we
want
to
change
I'll
I'll
need
to
keep
this
as
a
single
source
of
tools.
So,
if
you
think,
like
you,
have
a
suggestion
how
to
make
this
like
easier
for
us
at
this
stage,
because
we're
not
ga
so
probably
we
can,
we
can
try
to
focus
more
on
efficiency
instead
of
trying
to
put
more
restrictions.
I'm
open
to
that.
D
A
A
D
A
And
for
for
this
one,
johannes,
I
I
think
I
see
a
valid
point
from
tom
that
if
people
make
an
accidental
like
release
of
the
sharepoint,
I
wonder
if
there's
a
special
case,
we
can
make
so
no
matter
how
people
use
the
no
off
span
they're
not
going
to
mess
things
up.
For
example,
if
they
just
call
release,
we
wouldn't
actually
release
the
last
reference
count.
D
If
the
call
released
they
wouldn't
release
the
last
reference
count,
because
the
last
this
this
function
returns
a
copy
of
the
shared
pointer
and
the
last
reference
count
will
also
be
always
be
the
static
yeah
variable
so
yeah.
The
user
should
never
be
able,
with
releasing
the
sharepoint,
to
go
like
below
the
reference
count
of
one
here.
D
A
E
I
don't
know
whether
it
could
happen
like
in
the
user,
get
shared
pointer
code
in
conducer,
free
that
one
more
than
the
account
yeah.
It
gets
right
for
it
gets
one
shutter
point
shut
pointer.
Can
it
release
for
two
times?
Then
it
affects
the
global
variable.
E
D
C
D
E
Okay,
yeah,
I
think
I
I
will
do
some
offline
experimenting,
experiments
today
and
see
yeah
if
the
global
and
the
static
variable
holds
one
reference.
I
think
that's
fine.
Previously
I
thought
the
reference
has
to
be
returned
so
that
may
be
risk
yeah.
The
static
variable
variable
always
holds
one
reference.
I
think
that
should
be
okay.
D
It's
a
function,
static
variable
that
always
should
have
a
reference
one,
and
I
think
this
is
a
really
important
performance
improvement
for
us,
because
I
mean
in
the
benchmark.
It
improves
like
this
noob
span
creation
like
it's
three
times
as
fast
and
that
basically
improves
the
performance
for
customers
who,
just
like,
want
to
disable
open,
telemetry
and
don't
have
any
like
spans
created
at
all.
I
think
it's
an
exp,
important
use
case
that
we
have
just
a
very
minimal
overhead
in
that
cutter
makes
sense
thanks.
A
A
A
A
The
reason
here
is
once
you
create
the
tracer
provider,
the
sampler
has
to
be
assigned
upon
creation,
and
after
that
you
cannot
change
the
sampler.
So
during
creation
we're
saying
oh
we're
using
always
phone
assembler,
let's
just
go
and
call
the
processor
directly.
We
don't
go
through
any
like
virtual
function,
call
into
a
sampler
and
realize
oh,
the
center
is
returning.
True
like
this
is
something
we
can
potentially
explore
in
the
open
country
c
plus
class,
as
well
as
it
saves
two
actual
virtual
function.
Cars.
D
A
D
E
A
It
is
hard,
I
think,
the
logic
of
calling
calling
the
sampler
is
in
one
compilation
unit
where
they,
like,
probably
like
they
even
belong
to
different
modules,
like
the
one
module
is
dynamic
loading
library.
Another
is
the
actual
application
for
the
customer,
and
the
customer
would
specify
the
sampler.
So
underlying
library
has
no
idea,
except
for
the
runtime
and
unless
there's
a
runtime
way
of
doing
rigid
like
generate
the
code
on
the
fly,
there's
no
such
way
or
the
cpu
can
learn
from
that,
but
I'm
probably
too
far
away.
Okay,.
A
Okay,
hey
go
going
back
to
the
github
issues.
I've
seen
like,
based
on
the
last
conversation
that
I
see
johannes,
you
you've
updated
this
pr.
Yes,
you
think
it's
ready
to
merge
right.
D
It
should
be
ready
to
merge.
Okay,
I
have
this,
I'm
not
sometimes
I
I
don't
really
know
how
this
code
coverage
thing
works
because
using
my
two
pr's,
I
get
code
coverage
errors
for
coach
and
I
didn't
even
touch
the
metrics
part,
so
I'm
not
sure
if
there's
some
side
effect
or
if
the
code
cuff-
that
I
owe
thing
it
is.
D
Yeah
then
I
I
wonder
if
we
make
this
like
whether
we
should
make
this
just
an
optional
condition
and
not
make
mark
the
prs
as
failed
just
because
of
code
coverage
failures.
I
can
look
into
the
bit
of
actions
whether
hobby
can
config
figure
that
that
that
just
runs
kind
of.
A
Yeah,
it
is
already
an
optional
thing
and,
and
so
far
like
I,
I've,
never
blocked
a
pr
because
of
the
code
coverage,
but
in
general
we
look
at
the
code
coverage
as
an
input.
So
if
people
just
add
a
lot
of
code
without
having
proper
tests,
well,
we'll
see
like
if
they're
willing
to
add
that,
but
so
far
we
never
enforced
that
yeah.
I
just.
D
Think
it
it
would
be
a
visual
help
for
us
if
even
for
prs,
where
the
code
coverage
fails,
that
we
get
like
a
green
check
mark
and
not
the
red
x,
it
will
just,
I
think,
maybe
which
prs
are
ready
for
merge.
Actually,
because
when
you
just
see
the
x,
you
don't
know,
is
it
the
code
coverage
or
is
it
so?
I
can
look
into
that
and
see
to
make
yeah
ignore
the
basically
outcomes.
A
Function,
we
added
which
it
should
be
tested
for.
No,
the
code
coverage
currently
works
in
two
ways.
One
is,
it
has
a
has
a
bar,
so,
for
example,
mendes
you
have
to
have
at
least
code
coverage
like
75
percent
and
below
that
bar
you
will
get
some
warning
or
error,
and
another
rule
is
based
on
the
diff.
So
if
you're
adding
something
that
changed,
the
code
coverage,
even
if
the
final
result
might
be
higher,
but
a
previously
covered
line
of
code
with
your
change
is
not
covered,
then
it
is.
It
is
considered
as
a
problem.
A
Okay
and
and
that
that
added
some
headache
for
the
donate
project,
for
example,
we
realized.
Oh,
we
got
to
refactor
something
so,
for
example,
we
have
function
a
that
we
realize
is
not
good
enough
and
because
of
the
dependency
we
we
decided.
Okay,
let's
build
a
function
b
and
make
that
a
better
version
and
eventually
migrate,
all
the
features
towards
b
and
then
remove
a
at
the
moment.
We
start
to
migrate
features
to
b.
A
You
start
to
get
complaints
from
the
coverage
say:
hey
some
original,
like
lines
in
function
a
now
is
not
covered
and
what
would
rely
on
the
maintainer
to
make
the
right
judgment
whether
we
want
to
just
make
like
just
to
please
the
code
coverage
or
we
want
to
do
the
actual
value
here:
okay,
okay
and
for
for
all
the
other
like
pending
prs.
I
assume
there's
no
intention,
like
anyone
here
to
work
on
them
and
I'll
I'll
take
a
stab
and
for
some
of
the
small
pr
documentation.
I
notice
there
are
some
comments.
B
Start
as
you
go
down
through
the
list
for
the
http
client
api
yeah,
my
recommendation
would
be
to
add
apache
license
to
copyright,
microsoft.
Copyright
open
challenge
authors
because
it
is
kind
of
based
off
the
original
code
have
elsewhere,
and
my
understanding
I've
already
sorted
out
with
our
legal
team
that
this
other
code
is
a
virtual
license
too.
B
So
I'm
going
to
reset
my
feedback
for
the
changes
requested,
assuming
that
it
refreshes
it.
There
are
some
other
functional
comments
in
there,
like
quite
a
number
of
refactoring
suggestions.
Yeah,
maybe
like
two
approaches:
either
he
resolves
the
refactoring
suggestions
but
adds
the
copyright
or
fully
resets
it
and
does
the
complete
rewrite
from
scratch.
So
whatever
you
listen,
my
personal
recommendation
would
be
just
to
add
the
copyrights
like
respect
the
prior
article.
B
B
It's
been
discussed
in
the
main,
open,
telemetry
repo,
and
what
is
recommended
right
now
is
for
anything
that
is
same
license.
We
highlight
the
name
of
a
company,
but
not
the
name
of
an
individual,
so
we
avoid
promoting
individuals,
because
anybody
can,
you
know,
contribute
and
say
that
this
is
their
code
right,
yeah,.
B
B
I'll
add
it
in
a
chat
window
in
the
moment,
just
let's
continue
yeah.
D
D
So
maybe
there
are
some
different
guidelines
there
in
the
meantime,
but
I
just
remembered
it's
one
case.
B
Yeah,
I
can
show
you
the
interpretation
of
we
had
this
discussed
like
two
weeks
ago.
It's
the
moment.
I
have
too
many
notifications.
A
D
Because
I
think
the
caveat
is
here
when
the
copyright
is
somebody
else
then
like
we
cannot
change
the
license
without
approval
from
those
other
people
who
holds
copyright.
So
if
everything
is
copyright
open
diameter
authors,
it's
easy
to
just
do
changes
on
the
licensing
of
the
whole
project,
but
I
think
if
the
copyright
is
holder
for
some
parts,
it's
somebody
else.
Then
that
cannot
be
that
easily
done.
A
A
B
Think
this
is
the
link.
There
were
two
related
discussions.
Let
me
check
if
that's
the
one,
so
that's
one.
There
was
another.
B
So
my
understanding
was
that
the
issue
is
if
we
are
trying
to
borrow
incompatible
lessons,
but
if
we
borrow
compatible
license
and
right
now
to
the
purchases
too.
We
have
to
quote
the
original
author
and
have
copyrighted
intelligent
authors
as
well.
So
it's
both
records
are
there
and,
from
my
end,
I
discussed
without
illegal,
to
revise
our
code
that
we
really
have
that
we're
kind
of.
D
D
B
A
D
A
B
My
feedback
on
forking
was
that
if
we
have
some
sort
of
common
platform
abstraction
where
we
can
extract
before
this
is
problem,
there
that'd
be
awesome.
Because
then
I
will
have
generic
code
which
doesn't
care
about
working.
Then
there's
a
variable
pace
which
is
unique
to
posix
operating
systems.