►
From YouTube: 2021-01-26 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
A
A
B
So
I
just
put
a
note
in
the
password
is
now
triple
seven.
I
mean
five
sevens.
B
B
So
I
think
we
can
start
now.
I
do
have
a
issue
with
internet
since
morning,
so
in
case
I'm
not
able
to
be
orderable
like
I
try
to
join
worst
case
I'll
have
to
take
any
questions.
Offline.
B
Okay,
we
can
start.
I
have
a
very
small
agenda,
so
we'll
cover
any
other
questions
which
are
not
listed
in
the
agenda,
so
basically
an
update
so
about
1.0
release.
We
got
a
confirmation
that
spec
is
very
close
to
marking
tracing
as
1.0.
If
you
open
this
issue
in
the
spec,
it
contains
the
actual
list
of
issues
which
are
required
to
be
resolved
before
1.0,
and
there
are
only
two
or
three
issues
and
there
are
already
pr's
addressing
it.
B
So
it
should
be
like
fairly
so
like
before
the
end
of
this
week,
we
should
see
tracing
markers
which
work
us
from
releasing
one
daughter.
For
that
thing,
I'm
not
sure
like
whether
any
other
language
is
planning
to
do
along
with
us,
but
might
be
java
java
is
also
considering
like
a
one
door
release
so
process
size
will
do
an
rc2
release
and
take
to
the
final
one.
B
It
should
happen
most
likely
next,
like
week
february,
first
or
second,
that's
my
current
summer
again,
this
is
subject
to
traces
actually
being
marked
as
1.2.
B
Apart
from
that
on
a
later
topic
on
the
versioning
here,
which
I
made
in
december,
and
I
asked
a
community
to
vote
on.
B
Hello
again,
can
anyone
hear
me
yeah?
I
I.
B
B
So
I
was
just
talking
about
the
versioning,
so
we
caught
enough
approval
for
approach
three
where
we
would
be
releasing
1.0
without
matrix
and
all
the
matrix
code
would
move
into
a
separate
version
of
the
package.
Let's
call
it
like
one
dot
one.
It
could
be
like
one
do
two
or
one
port
three,
and
once
the
metrics
are
ready,
we
will
release
again.
B
Let's
say
it
is
one
one
dot
one
so
we'll
release
one
dot,
one
dot
zero,
which
would
contain
traces
and
matrix-
or
this
is
the
plan
which
we
are
taking.
The
implementation
of
that
like
sergey,
raised
a
conditional
compilation
method
to
achieve
it
instead
of
creating
and
maintaining
different
branches.
B
B
So
my
personal
preference
is
still
get
branch
likely
tried
it
out
in
a
fork
where
we
can
have
multiple
branches,
and
we
can
version
things
accordingly,
using
the
tool
which
we
are
currently,
which
is
meanwhile,
but
using
conditional
compilation,
it's
a
little
bit
tricky
to
get
the
versioning,
because
the
minerva
tool
does
not
look
at
the
code
to
get
the
version.
It
purely
looks
at
git
tags,
so
I'll
see
if
like
sega,
has
something
else
in
my
mind
about
conditional
compilation.
B
But
this
is
just
like
logistics
on
how
we
are
going
to
achieve
achieve
the
already
agreed
strategy.
So
it
could
change
it's
fine
and
also
I'll
be
releasing
different
packages
with
different
version
numbers.
So
we
we
would
have
this
ability
in
meanwhile
already
so
that
means,
when
we
do
the
release
of
1.0,
we
will
be
only
releasing
the
api
sdk
and
the
required
exporters.
B
So
that
ends
the
updates
from
me
looks
like
we
have
topics
so
prashant.
Can
you
summarize
your
like
concerns
and
proposals.
D
Yeah
yeah
so
before
that
procedure
on
your
last
point
of
the
instrumentation
version,
does
that
apply
to
all
the
instrumentations
like
from
third-party
sources
as
well?
B
Yeah,
I
think
I
think
like
if
the
semantic
convention
conventions
are
not
marked
as
1.0.
We
cannot
technically
release
a
instrumentation
because
instrumentation
does
depend
on
semantic
conventions,
so
get
a
place
to
all.
Irrespective
I
mean,
if
there
is
a
company
like
which
has
their
own
repo,
which
wants
to
release
1.0,
that's
their
choice
but
yeah,
but
from
the
open
telemetry.
B
Something
which
is
pre-release,
I
don't
know
whether
it
will
be
called
rc,
1
or
rc2,
but
definitely
not
1.0,
and
I
don't
think
like
anyone
asking
the
question
like
when
would
we
get
semantic
conventions
marked
as
1.0?
Sorry,
I
didn't
ask
it
either.
So
it's
unknown
to
me
like
when
would
that
be.
D
Okay
yeah,
so
so,
for
example,
I
can
if
an
instrumentation
is
for
tracing
and
the
tracing
is
in
1.0,
then
that
that
instrumentation
can
be
marked
as
1.0
right
and,
if
there's
some
instrumentation,
which
is
for
metrics,
which
is
an
alpha,
then
that
instrumentation
would
still
need
to
be
marked
as
alpha.
B
No,
actually,
the
instrumentation
for
tracing
cannot
be
marked,
as
one
daughter
is
my
understanding.
So
let
me
I'm
trying
to
look
at
like
let's
say,
let's
take
asp.net
instrumentation,
which
instruments
asp.net
and
it
produces
spam
based
on
the
semantic
convention,
so
it
has
like
a
dependency
on
the
semantic
conventions.
B
So
that
is
the
reason
why
I
said
like
unless
semantic
conventions
are
marked
as
stable
in
the
spec.
We
cannot
guarantee
that
it
won't
change
so
okay,
because
of
that
I
want
to
make
sure
we
do
not
release
1.0
until
we
get
a
confirmation
that
semantic
conventions
are
not
going
to
be
broken
or
we'll
be
like
in
trouble,
because
we
have
to
like
if
we
find
that
some
convention
changes
we'll
be
forced
to
populate
both
to
maintain
accurate
compatibility,
yeah
and.
B
Uses
some
semantic
convention,
some
connections
yeah,
including
like
what
should
be
the
name
of
the
span
that
itself
is
coming
from
the
conventions
and
all
that
pretty
much
all
the
tags
are
also
coming
from
semantic
right.
So
yeah
I
mean
I,
I
was
a
bit
surprised
that
no
one
asked:
when
would
we
see
semantic
conventions,
markers
stable?
So
I
don't
know
the
answer
myself,
but
since
you
asked
I'll,
definitely
ask
it
in
the
next
sig
meeting
for
the
spec
and
try
to
get
a
firmer
date.
D
Thanks
yeah,
so
for
my
agenda
of
the
contrib
repo,
I
think
we
discussed
it
during
previous
few
seg
meetings
that
the
contract
report
right
now.
It
builds
with
a
single
targeted
version
of
the
base
open,
telemetry.
D
D
So
I
was
kind
of
like
playing
around
and
had
some
very
basic
like
approach,
which
I
just
wanted
to
share
to
see
if
I'm
like
thinking
in
the
right
direction
or
if
there
are
any
problems
that
we
can
foresee
with
that
approach
right
away.
So,
like
my
high
level,
pro
proposal
would
be
to
not
have
the
single
directory
build
props
file.
D
Rather,
every
project
should
target
a
version
of
open
telemetry
within
the
cs,
proj
file
of
that
project,
and
with
that
in
the
workflow
for
the
build
and
release
that
some
maintainer
has
to
definitely
take
up
the
job
of
getting
the
release,
request
and
clicking
on
the
workflow
button
for
the
release
that
can
have
like
the
the
project
name
and
the
version
that
project
wants
to
release.
So
we
can
target.netbuild
and
dotnetpack
commands
on
a
particular
project,
so
that
should
be
able
to
be
built
and
released
separately.
D
D
B
I'm
I'm
like
very
eager
to
see
that
and
because,
as
of
now,
it's
not
maintained
in
a
way
where,
where
it
is
easy
for
each
individual,
let
me
call
folder
owners
yeah.
It's
not
easy
for
individual
folder
owners
to
worsen
and
release
independently,
because
it's
tight
too
much
it's
okay,.
E
B
D
On
that
would
be
so
every
project
if
we
call
it
as
a
folder,
will
have
some
maintainers
who
would
do
code
reviews
or
who
are
the
subject
matter
expert
of
that
particular
project
and
for
the
release
of
any
project
or
I
independently,
or
they
contribute
as
a
whole.
There
has
to
be
like
one
high
level,
at
least
one
high
level
maintainer,
who
has
the
access
to
click
the
workflow
button,
so
yeah.
E
So
so,
just
to
give
the
experience
that
we
had
on
the
collector
control
contrib
folder.
It
really
needed
to
happen
that
way,
because
there
is
many
much
more
contributes
there
and
it's
hard
to
for
even
for
a
maintainer
kind
of
to
know
of
specifics
of
let's
say
exporter,
so
there
are
kind
of.
As
you
said,
there
are
kind
of
approvers
that
the
maintainer
knows
that.
E
Okay,
for
for
this
feature
here
for
this
contrib
here,
this
person
is
the
one
that
review
so
the
the
maintainer
basically
ping,
the
appropriated
per
people
and
kind
of
delegate
to
then
the
review.
Although
the
maintainer
is
the
one
that
does
the
merge
and
this
kind
of
thing,
but
it
was
the
only
way
to
manage
that
on
the
collector
contribute.
D
Yeah,
so
that's
something
that
I'm
suggesting:
what
about.
B
The
release
is
the
release
also
like
done
by
like
let's
say
there
is
a
exporter
which
want
to
go
to
do
the
release.
They
would
still
have
to
go
through
the
like
overall
maintainer
of
the
report
to
do
the
release.
He
said.
E
The
thing
is
that
doesn't
have
a
thing
like
nougat
to
publish
that
way,
so,
but
the
the
the
official
builds
with
label
kind
of
are
for
the
maintainer.
You
know,
but
you
you
can
have
there.
One
thing
that
we
have
is
one
release
of
the
collector
and,
for
instance,
if
you
one
of
the
let's
say,
exporters
is
not
updated
to
the
latest
version.
We
can
exclude
that
from
the
release
of
the
the
collector,
but.
E
It
it
depends
on
the
people
that
are
interested
on
that
specific
one
to
to
the
release
with
no
new
get.
The
thing
gets
a
bit
different,
because
I
I
would
say
that
we
want
to
automate
that,
but
we
wanted
something
like
a
label
for
the
the
whole
repo
should
trigger
the
release
of
new
stuff
if
they
have
new
stuff.
But
but
for
that,
I
think
we
need
to
kind
of
plan
how
that's
going
to
be
made
for
4.3.
B
I
see
yeah
I
mean
I
can
easily
say
it
will
be
a
little
bit
more
more
than
trivial
job
I
like
to
individ,
independently
and
parallely,
or
like
completely
different
version
release
at
different
cadence,
each
folders
or
each
components
and
yeah.
It
cannot
be
like
from
a
like
single
git
tag,
which
marks
the
overall
repos
like
1.0
or
2.0,
because
each
components
could
be
on
different
stages.
D
B
I'm
not
sure
like
how
the
workflow
itself
like
would
you
imagine
like
there
will
be
a
separate
workflow
per
a
folder
or
you
would
have
a
single
workflow
which
by
releases
all
the
folders,
but
you
can
selectively
turn
on
and
off
certain
components
from
your
release.
E
Yeah
we
could
have
a
list
of
kind
of
the
things
that
are
red,
that
should
be
automatic
released
and
as
we
approach
each
release,
we
can
kind
of.
Oh,
this
branch
was
not
updated
yet
so
we
can
remove
that
and
do
the
release.
You
know
yeah.
B
Okay,
yeah
so
prashanth
like
can
you
like
describe,
I
mean
open
an
issue
with
this
proposal,
saying
how
to
organize
the
repo
in
such
a
way
that
we
can
do
independent,
versioning
and
like
like,
we
just
discussed
like
independent,
releasing
as
well,
so
that
like
each
component,
can
move
at
their
own
pace
rather
than
being
blocked
on
each
other.
So
could
you
like
make
this,
like
writing
I'll?
Take
the
action
item
down
on
the
dock.
B
And
ideally,
I
would
like
expect
to
get
like
a
spec
recommendation
on
how
to
organize
the
contribute,
because
it
looks
like
every
language.
Different
language
is
doing
different
approaches
and
there
are
open
issues
in
the
spec
to
make
a
official
suggestion
on
how
should
this
be
handled?
That
hasn't
been
resolved,
and
I
don't
know
whether
anyone
is
actively
working
on
that
proposal.
B
And
like
this
is
like
a
prerequisite
for
like
releasing
anything
from
the
contributor,
because
at
this
stage
I'm
like,
I
already
had
excited.
E
B
Aws
components
are
not
like
blocked
on
the
activity
source,
adapter
issue,
but
other
components
are
so
like.
They
are
basically
two
stages
of
development.
Technically
aws
can
move
to
the
newest
version,
but
other
components
cannot
and
if
you
try
to
upgrade
one,
there
is
no
way
like
it's
all
common,
so
the
cas
would
fail.
So
once
we
like
arrange
this
in
a
better
way.
B
Ideally
following
the
spectrum
recommendation
or
like
whatever
percent
like
you're,
going
to
write,
we
should
be
able
to
like
unblock
each
and
e
into
each
individual
instrumentations
slash
each
individual
folders
one
by
one.
D
Okay,
so
should
I
open
this
issue
within
the
dot
net
contra
repo
or
in
this.
B
B
If,
if
not
possible,
we
can
try
to
do
like
solve
it
in
the
dot
network.
But
then
again
the
question
is
we
probably
will
be
inconsistent
with
other
reports.
So
ideally,
if
we
can
open
like
a
proposal
in
the
spec
repo
saying,
there's
already
an
issue
open
about
like
asking:
where
should
the
non-core
components
be
placed
and
how
should
the
releases
be
handled
etc?
D
B
B
B
Okay,
yeah.
I
think
we
can
move
to
the
next
topic.
F
Hi
it's
my
first
time
in
this
meeting.
I
was
pointing
to
you
ned
sig,
from
after
after
addressing
some
questions
to
the
amazon
team.
Scopely
is
a
mobile
game.
F
Developer
publisher
and
we've
been
looking
pretty
closely
at
open,
telemetry
and
particularly
as
potentially
using
it
for
doing
client
analysis,
basically
analysis
of
how
basically,
we've
been
looking
at
using
open
telemetry
for
doing
analysis
of
mobile
game
performance
in
the
wild
through
collecting
spans
inside
the
unity
game,
engine
and
leaning
on
the
stack
that
open
telemetry
has
and,
after
speaking,
some
with
open
telemetry
folks
within
aws
on
this
front,
because
we're
not
a
best
customer
point
us
maybe
to
this
group
to
see
if
the
sig
thinks
that
we're
crazy
and
to
see
whether
there
there's
any
other
awareness
that
you
might
have
from
the
other
members.
F
The.Net
community
and
open
telemetry
of
people
looking
at
using
this
outside
of
sort
of
the
pure.ecosystem,
as
well
as
outside
of
more
server
context
and
just
sort
of
float
that
trial
balloon.
Is
that
something
that
other
people
have
considered?
We
know
that
it's
probably
meaningfully
different
in
terms
of
what
we'd
want
to.
We
would
want
to
go
with
the
sdk,
because
there's
some
differences
in
terms
of
how
actually
you
would
want
to
collect
spans,
potentially
because
it's
more
for
a
more
performance
constrained
environment
than
the
server.
F
But
that's
you
know
I'm
here
basically
to
ask
whether
they're
any
this
is
something
that
others
have
considered
has
come
up
before.
We
start
experimenting
with.
What's
what
this
will
look
like.
B
Independently,
so
we
do
have
like
a
couple
of
examples
which
are
like
console
apps
not
really
tied
to
like
web
server
or
anything.
That
would
be
like
good
starting
point,
but
from
a
like
bigger
usage
perspective,
I
have
seen
like
c
plus
plus
sdk.
They
have
help
like
most
mostly
matching
the
same
person
which
you
are
asking
like.
They
are
using
open,
telemetry
c,
plus
plus
sdk,
to
instrument
like
game
engines
and
like
client
side
applications.
F
So
you're
saying
that
the
simplest
plus
sdk
team
has
solved
some
of
these
concerns.
Potentially
that
would
need
to
maybe
be
resolved.
That
is
it.
B
E
I
one
thing
I
I
didn't
work
with
this,
and
but
I
I
could
do
do
a
a
look
for
that.
That
I
think
is
related
is
not
directly
gaming
engines,
but
kind
of
client
experience
run
in
general
there
there
have
been
people
working
with
open,
telemetry
and
run.
So
I
think
that
fits
the
picture.
E
I
I
can
try
to
dig
who
have
worked
on
this
or
have
tried
something
and
kind
of
try
to
to
put
in
contact
or
bring
perhaps
to
the
next
meeting.
I
don't
know
what
works
better.
F
I
mean
I
would
definitely
appreciate
pointers.
I
mean
this.
People's
plus
sdk
team
is
a
great
direction.
I
hadn't
thought
to
look
there,
but
if
we
definitely
see
what
we're
doing
as
basically
rum-
and
we
also
are
in
the
same
boat
that
we
believe
that
rum
probably
ought
to
be
solved
with
up
until
much,
at
least
as
the
you
know,
the
wire
format.
So
why
reinvent
that?
F
But
I
yeah
I
don't
know
who,
within
the
open,
telemetry
community,
is
really
doing
rum,
so
whether
yeah,
whether
via
the
sig
or
or
separately,
be
interested
in
in
that
intro.
If
you
have
it.
F
Actually
was
directed
to
you
via
via
janna
at
aws.
We
actually,
she
put
us
in
touch
with
basically
pointed
us
to
the
sig
saying
that
you
know
we
asked
this
question
of
amazon
and
she
said
basically
well.
This
is
probably
more
of
a
sig
question
and
maybe
not
direct
the
part
of
amazon's
investment
in
open
telemetry,
but
we
also
are.
I
guess
she
also
has
our
contacts.
F
C
I
think
I
I
don't
so
I
don't
think
open
telemetry
has
a
full
matrix
of
which
sdk
is
more
performant,
which
sdk
is
less
performant
from
an
instrumentation
perspective.
So
I
don't
think
that
data
is
available,
but
I
think
what
you're?
What
you're
being
pointed
to
is
the
standard
way
that
most
game
developers
look
into,
which
is
c
plus
plus
sdk?
F
We
are
open
to
doing
a
lot
of
this
from
scratch
ourselves.
We
just
would
like
to
you
know
we
would,
to
the
extent,
I
guess
this
is
interesting
to
the
sig
more
broadly
and
to
the
community.
F
More
broadly,
you
know
we
would
like
to
not
be
operating
fully
solo
and
aligning
how
we
look
at
this
with
the
the
sig
with
other
language
groups,
but
I
also
I
understand
that
probably
the
way
that
a
game
engine
is
in
in
the.net
ecosystem
sees
the
sdk
is
probably
different
from
the
way
a
web
application
sees
it
in
terms
of
what
they
want
out
of
it.
C
Yeah
for
sure,
I
think
to
be
even
more
honest,
like
the
c
plus
plus
from
my
understanding.
Sdk
is
a
little
behind
compared
to
other
sdks,
so
the
c
plus
plus
space
is
a
little
bit
behind.
So
it'll
be
probably
be
a
good
time
to
go
in
there
and
contribute
and
look
at
what
sort
of
alignment
you
want
from
a
game.
Engine
perspective:
okay,
okay,.
B
C
Sorry
I
had
one
topic
I
wanted
to
make
sure
so
I
think
from
the
looks
of
it,
we
are
aligning
towards
january
31st,
first
of
feb,
as
spec
closing
marking
as
1.0
correct
as
a
release
candidate.
C
So
I
think
I
wanted
to
make
sure
that
we
are
doing
our
usual
medium
post
kind
of
announcing
that
from
a
net
community
perspective,
I
the
the
last
post
that
I
wrote
it
did
not
follow
the
1.0
conventions,
but
if
everyone's
okay
with
the
last
post,
I
can
go
ahead
and
just
change
ga
wording
to
1.0
and
get
that
up
and
going.
C
B
B
It's
if
it
happens
like
let's
say
this
friday,
then
we
are
unblocked
from
expert
perspective
on
releasing
so
it
could
be
like
next
monday.
We
can
do
the
release
okay,
but
like
the
blog
post,
contents
can
be
like
made
ready
with
the
assumption
that
it
it's
not
assumption.
It
is
the
fact
that
it
is
not
a
ga
release.
It
is
a
one
dot
or
release
yeah.
Let's.
C
Maybe
like
yeah
yeah,
can
you
go
down
to
the
blog
post
and
if
everyone
can
just
leave,
I
think
it's
in
the
notes
itself,
like
one
below,
if
everyone
could
just
read
through
it
and
ignore
the
ga
wording
over
there,
I'll
change
it
to
1.0
and
probably
just
give
me
a
thumbs
up
thumbs
down
on
gator
by
thursday.
I'd
appreciate
that
so
that
we're
ready
by
friday
on
the
tracing
spec
closing
down
this.
B
Okay,
in
fact,
please
go
ahead
and
change
the
ga
to
one
daughter,
because
that
is
already
defined
and
merged
in
the
spec.
We're
not
calling
the
one
dot
or
releases
ga,
because
ga
definition
is
now
tracing
plus
matrix
in
at
least
four
languages.
That's
when
open
telemetry
would
call
itself
ga,
which
means
this
is
a
1.0
release,
like
some
companies
call
it
ga
but
like
from
open
telemetry
perspective,
it
is
tracing
1.0
release.
So
let's
refactor
the
wordings
accordingly,
yeah,
okay,.
A
B
B
Which
we
would
do
like
as
soon
as
possible,
like
probably
tomorrow,
because
I
want
to
finalize
on
the
versioning
aspect,
which
we
were
still
not
sold
last
meeting,
but
now
that
it's
sold,
I
don't
have
any
blocker.
I
can
just
like
actually
execute
the
plan
and
release
an
rc
2,
because
we
already
released
an
rc1,
so
I
can
release
an
rc2
and
give
it
like
three
four
days.
Hopefully,
in
that
time
the
spec
would
stabilize
I
mean
spec
would
mark
itself
as
one
daughter
and
we
can
do
one
daughter's
full.
C
So
I've
gone
ahead
and
changed
the
actual
blog
post
and
I'm
just
going
to
post
in
getter
now
as
well,
okay-
and
please,
I
think
I
just
wrote
a
few
quick
two
paragraphs,
please
feel
free
to
add
to
it-
change
to
it
and
make
sure
that
I've
covered
whatever
you
guys
feel,
is
important
to
highlight
the
post,
and
I
think
we
can
set
a
date
as
thursday
as
marking.
This
is
more
final,
so
I
can
post
this
on
medium.
Whenever
you
know
a
ready
state.
C
B
So
I
want
to
I
mean
if
there
are
no
other
questions
I
want
to
ask
like
follows
like,
since
you
are
representing
the
auto
instrumentation
say:
would
we
want
like
anything
to
be
included
or
mentioned
in
the
blog
post,
about
auto
instrumentation
efforts,
or
should
we
just
like
be
silent
about
it?.
E
Yeah,
for
now
we
we
should
be
silent.
We
we
have
some
progress
there,
but
this
is
still
dealing
with
the
kind
of
more
basic
implementation
internal
stuff.
So
I
I
think
it
better
right
now
not
not
do
announcements
about
that.
B
Okay,
got
it
yeah,
okay,
so
one
final
thing
is
about
metrics,
so
people
who
are
actively
following
metrics.
You
know
that
there
was
a
metrics
workshop
two
weeks
back
and
a
lot
of
discussion,
points
and
action
plans
coming
out
of
that.
So
one
of
the
thing
which
we
are
doing
from
dotnet
side
is:
it's
like
riley
has
opened
a
tr
in
open,
elementary.net
repo
seeking
feedback
from
like
from
a
dot-net
perspective.
Like
do
you
like
this
api?
B
B
B
So
there
are
already
a
few
comments,
so
please
feel
free
to
go
ahead
and
riley
would
be
presenting
them
in
the
matrix
meeting
as
well
like
just
from
a
dotnet
perspective.
These
are
the
issues
we
see
and
making
sure
that
the
overall
spec
addresses
them.
So
please
go
ahead
and
look
at
that
as
well.
B
Any
other
topics
to
discuss,
I,
I
cannot
see
the
one,
no,
I
mean
the
document,
but
I
think
that
we
are
at
the
end
of
the
dog.
So
no
other
question.
So,
okay,
we
can
see
again
next
week,
hopefully
by
that
time,
we'll
have
like
form
like
1.0
released,
but
anyway
thanks.
Everyone
see
you
next
week.