►
From YouTube: 2021-06-07 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
I'm
just
wondering
for
the
first
item
on
the
agenda.
If
we
should
have
johannes
johannes
to
chairman
on
that,
but
the
shirt
be
charging
okay.
A
A
When
we
say
we
have
something
that
is
v1
and
release
candidate,
how
drastic
how
we
want
to
go,
because
that
probably
means
reinstrumenting
everybody
who's
already
tried
using
it.
B
A
So
like
we
need
a
quorum
to
make
a
drastic
big
change.
Change
like
this.
A
I
generally
like
the
idea
of
having
like
a
simple
value,
object
which
inside
which
maintains
the
the
shared
ptr
and
all
the
complexities.
A
So
the
easier
the
object
is
the
easier
it
is
to
interact
with
it
at
the
same
time
as
I
look
at
it
like
c
plus
plus,
has
the
auto
keyboard
and
when
we
do
auto
span,
it's
just
marginally
harder
to
use
it.
A
A
A
For
this
week
I
don't
really
have
much
items
to
discuss.
I
mean
I'd,
follow
up
with
a
bit
of
cleanup
and
licensing
documentation,
because
the
change
to
introduce
abseil
variant
is
now
merged,
and
I
think
I
can
prepare
a
document
with
the
list
of
licenses.
We
now
removed,
removed,
mpark
variant,
so
one
less
piece
that
depended
on
boost
license,
but
at
the
same
time
I
see
that
we
still
need
boost
for
a
few
core
exporters.
I
think
for
thrift.
A
A
They
can
avoid
including
components
that
they
don't
need
that
way
avoid
including
the
licenses
or
code
path
that
they
are
not
friendly
to
certain
environment.
For
example.
Only
those
who
really
need
jagger
would
would
would
have
to
mention
that
they
depend
on
code.
That
requires
like
boost
license
right.
Something
like
this.
B
A
Three
and
I
I
I
looked
at
how
it
builds
in
windows
with
vc
package
and
it
pools
dependencies,
so
it's
like
when
we
built
the
final
binary.
We
would
pull
thrift
and
that
itself
pulls
boost.
A
A
Need
my
understanding
is
when
you
ship
a
commercial
product
that
includes
some
dll,
for
example,
you
actually
have
to
give
credits
to
those
components
and
licenses
which
you
utilize.
So
even
if
there
is
a
small
piece
which
uses
boost
license,
you'd
have
to
mention
it
in
a
very
long
list
of
licenses
used
by
your
product.
A
A
Source,
yes,
I
think
the
issue
here
is:
we
were
talking
about
api
compatibility
for
version
like
1.1,
which
means
that
we
give
some
build
recipe
for
the
entire
system
and
you
can
kind
of
swap
or
mix
and
match
exporters
or
somehow
specify
at
runtime
that
you
want
to
plug
in
a
certain
exporter,
so
companies
that
build
their
products
from
this
source.
A
They
need
to
know
what
dependencies
require.
What
licenses,
because
they'd
be
shipping
commercial,
build
or
commercial
products.
So
it
would
be
helpful
from
our
end
if
we
create
a
document
that
lists
this
component
like,
for
example,
etw
doesn't
depend
on
anything.
It's
all
copyright
open
to
elementary
authors
and
apache.
A
Now
this
component,
like
jager,
depends
on
thrift,
which
in
turn
depends
on
boost
which
pulls
this
this
and
this.
So
you
need
to
mention
licenses
for
these
components,
because
you're
composing,
something
like
a
binary
that
includes
all
this
junk
and
in
their
commercial
license
like
license
agreement
when
they
ship
binary
they'd
have
to
mention
all
that.
B
A
A
That's
right!
That's
yes!
Yes
exactly!
So,
if
it's
only
for
the
test,
then
we
don't
need
to
mention
it
or
we
can
have
like
there's
an
item
on
me
about
describing
licenses
for
each
component
I'll
send
in
the
pr.
Perhaps
we
can
use
rewarding
that
it
only
used
for
the
tests
and
then
basically
something
like
commercial
product
developers
have
to
use
their
best
judgment
to
determine
if
they
need
to
list
that
a
license
in
their
list
of
licenses
or
not
because
ultimately,
it's
a
guideline
only
and
the
actual.
A
Legal
side
is
on
those
who
shape
it
commercially.
Those
would
have
to
disclose
what
licenses
are
being
used
by
their
shippable
binary,
artifact.
B
B
B
B
A
If
that's
the
case,
then
we're
good,
I
didn't
again,
I
didn't
dig
deep.
I
just
looked
at
what
it's
pulling
and
I
saw
that
it's
been
pulling
a
bunch
of
boosts
from
that.
I
made
an
assumption,
but
I'll
double
check.
B
A
Sense
yeah.
I
I
can
probably
copy
some
of
their
statements
into
our
document
to
make
sure
that
it's
in
alignment-
and
we
are
telling
you
exactly
what
the
other
projects
are
telling.
A
I
don't
have
many
items
on
agenda
for
this
week
honestly.
I
think
that
on
this
one,
that
about
shared
ptr
johannes,
said
that
he
is
also
kind
of
supportive
of
this
idea.
He
has
some
concern
about
it,
but.
B
A
Yeah
this
would
require
a
bi
change.
This
would
also
require
examples
change,
so
I
don't
think
it's
a
small
change.
B
Yeah,
I
agree,
and
also
the
pr
and
the
issue
mentioned
this
pattern
may
apply
to
some
other
other
open,
telemetry
objects,
like
baggage,
I
think
which
currently
we
try
to
use
sharepoint,
as
for
as
far
as
we
can.
A
A
Of
course
we
can
try
to
do
synthetic
benchmark
on
shared
ptr
and
while
loop
and
see
what
we
get
with
that
versus
it's
like
if
we
are
going
to
wrap
it
in
a
value.
Object
is
still
a
shared
ptr
within
like
a
pointer
to
implementation
pattern,
and
that's
not
going
to
give
better
because
we're
still
doing
all
this
locking,
I
mean
it's,
maybe
a
path
to,
as
he
mentioned,
synchronous
exporters
that
just
like
pass
through
like
in
atw
scenario,
for
example.
A
I
don't
really
need
to
do
much
aggregation
and
bashing,
because
I
I
simply
pass
through
everything
in
scope
on
on
user
thread.
I
never
run
a
background
thread
at
all,
so
in
that
scenario
I
think
it
makes
sense,
and
then
I
can
say
that
there's
no
locking
needed,
but
I
I
need
to
understand
this
a
little
bit
better.
I
don't
exactly
buy
into
performance
argument.
Honestly,
I
mean
any
performance
argument
has
to
be
measured
before
we
say.
Oh
it's
going
to
be
best
for
performance.
A
I
agree
yes
because
otherwise
it's
like
it
looks
nicer
on
surface
I
mean
to
me
it
looks
easier
to
deal
with
value
object
but
at
the
same
time
there's
auto
keyword
and
when
we
go
with
auto,
I
don't
even
have
to
know
what
that
exact
type
is.
I
do
auto
spam
equals
whatever
and
operate
on
that,
and
my
immediate
concern
is
that
I
do
have
two
customers
using
the
current
api
surface.
A
A
I
see
yes,
it's
a
bit
of
like
I
think
it's
a
reasonable
change,
and
maybe
we
should
be
able
to
handle
that
it's
just
a
change
and
sometimes
telling
people
hey.
You
need
to
change,
maybe
taken
with
a
bit
of
questioning.
Why
did
you
guys
do
this
in
the
first
place
and.
A
Yeah,
I
guess
so,
but
even
if
we
are
saying
that
once
we
refer
to
pointer
to
implementation
paradigm
under
under
the
food,
it's
still
same
walking,
I
mean
it's
not
going
to
buy
extra
perfect.
Just
maybe
looking
nicer.
A
Many
classes
how
many
default
exporters
that
we
operate
with
require
this
I
mean
require
this
locking
and
if
all
of
them
all
of
the
defaults
require
this
logging,
then
we
are
not
improving
anything
for
the
standard
set
of
of
our
exporters
yeah.
A
Only
for
the
custom
that
allow
to
stream,
which
may
not
be
one
of
the
defaults
that
we
have,
we
may
get
a
better
curve,
but
then
I
would
argue
that
there
are
some
other
things
that
we
could
have
improved
even
better
with
respect
to
structured
data
like
for
ad
event
on
spam.
A
Maybe
we
should
have
avoided
the
mem
copying
to
own
the
attribute
value
and
all
that
it's
like
there's
a
few
other
things
which
maybe
could
have
done
better
if
we
were
concerned
about
that
immediate
streaming,
exporter
that
wasn't
even
in
the
list
of
our
default
things,
that's
why
and
I
I
would
like
to
hear
other
people
opinion.
I
do
have
some
doubts.
A
B
A
A
Using
some
of
these,
it's
just
feature
plugs
that
we
had
for
the
adding
and
duplicating
features,
because
what
I
see
is
going
to
happen.
Let's
say
we
refactor
this,
which
means
that
our
contributor
stuff
for
the
engines
and
the
httpd
is
also
going
to
change
most
likely
and
perhaps
some
of
why
ongoing
custom
exporter
your
closing
needs
to
change.
So
it
implies
that
not
only
we
do
scan
refactor
and
change
all
the
examples,
but
there's
also
some
external
changes
as
well
as
alpha
and
beta
trial.
Customer
called
changes.
A
Yes,
that's
the
moment
which
is
a
bit
of
a
question
mark
and
unknown,
because
I
I'm
talking
about
at
least
two
customers
trying
things
out
right
now.
A
If
we
agree
here,
I
have
to
go
back
to
them
and
say
hey
now.
You
also
have
to
change
your
code,
whereas
we
were
kinda
passed
that
release
candidate
label
where
we
said
now,
it's
1.0
rc1
and
all
major
api
changes
have
been
addressed
and
even
for
very
minor
api
changes,
we
were
very
conservative
to
allow
any
minor
api
change,
and
this
is
this
proposal
is
a
major
breaking
api
change.
So,
that's
why
I
I'd
like
to
get
opinions
and.
B
If
I
think
you
have
a
few
customers
already
adopted
in
the
open
telemetry,
yes,
that's
plus,
and
I
think
that
that's
one
in
azure
cognition
team,
who
already
adopted
our
latest
version
so.
B
B
A
Yes
and
azure,
yes,
other
a
compute
other
than
other
teams,
they
would
use
existing
structure
and
existing
api
and
most
changes
that
I
expected
to
deliver
to
them
were
rather
incremental.
Not
breaking
so
breaking
change
is
going
to
be
a
bit
fun
to
explain
and
deliver.
A
Maybe
we
could
have
done
something
like
version
1.1,
which
adds
this
easier
value
object,
or
rather
than
shared
ptr,
do
staged
approach
rather
than
irreversibly
refactoring
that.
A
Anything
that
is
right
now
asynchronously
by
chain
requires
that
visitor
pattern
through
transforming
to
owned,
attribute
value
which
implies
mem
copy
and
then
in
the
streaming
case,
or
I
would
say
in
synchronous,
exporter
scenario,
where
we
do
all
that
we
work
one
user
thread.
That's
where
I
think
coming
back
to
common
attribute
value,
which
we
accept
on
the
api
surface,
how
to
efficiently
transform
that
without
mem
copy,
maybe
by
serializing,
into
whatever
object
on
user
thread.
A
The
pattern.
The
whole
pattern
of
synchronous
exporter
is
a
topic
and
I'd
say
that
this
proposal
falls
into
that
category
of
optimizing
for
the
synchronous
export
optimizing
for
the
streaming
exporter.
A
I
I
I
totally
understand
the
reason
you
know
here
and
in
some
cases
like
sharing
some
of
our
other
open
source,
sdk
experiences
like
microsoft,
client,
telemetry
sdk.
A
We
do
most
of
that
serialization
on
user
thread
and
it's
not
that
expensive,
but
obviously,
once
we
are
done
with
that,
we
kind
of
pass
over
the
content
of
the
message
or
event
to
whatever
background
batcher
as
well,
but
including
less
of
the
mem
copy,
because
we've
already
compactified
it
and
we
did
not
have
to
do
for
each
key
value
copy
into
another,
similar
structure.
A
If
we
are,
if
we
started
talking
about
that,
real-time
synchronous
streaming
export
and
I
also
want
to
know
more
from
bogdan
what
concrete
exporter
he
has
in
mind,
like
I
think
he's
at
splunk.
Do
they
have
some
concrete
examples
or
templates
of
a
custom
exporter?
A
Maybe
something
that
we
can
learn
from
and
is
this
something
that's
gonna
go
to
country
brepo?
Because
I
guess
we
add
all
these
non-standard
exporters
to
the
country
repo.
I
believe
unless
it's
a
proprietary
code
base
somewhere
else.
B
A
Because
then,
if
we
are
talking
about
this
model,
then
I
could
have
said
okay.
We
can
also
use
open,
telemetry
api
surface
to
invoke
or
async
like
pass
through
to
another
api,
for
example
like
a
random
microsoft,
client
element.
A
So
it's
like
you
can
still
use
the
same,
familiar
open
to
open
telemetry
api
surface.
But
then
there
is
no
exporter
per
se.
There's
no
there's
only
api
and
there's
no
exporter
that
follows
this
current
present
model,
but
anyway
streaming
exporter.
I
think
they're
also
assuming
that
it's
like
real
time,
not
streaming
non-batching
thing.
A
I
would
love
to
learn
more
about
this,
because
in
many
scenarios
we
also
want
that
and
we
want
to
optimize
for
that-
and
I
I
don't
disagree
with
what
they're
saying,
but
I
think
it's
a
bigger
topic
that
we
need
to
very
carefully
agree
on
and
maybe
in
incremental
fashion.
I
agree
with
you.
Maybe
it's
something
that
needs
to
be
1.1
rather
than
you
know,
sudden
refactor
before
release
it's
a
business
ritsky.
B
Do
a
quick
look,
I
think
we
just
released
rcoi
right
yeah,
any
new,
the
first
one
sugar
exporter
underneath
I
just
fixed
it
yeah,
that's
good!
That
should
be
fine
building
warning.
Okay.
The
second
one
is
the
grpc
example
introduced
added
by
our
university
students,
which
doesn't
apply
our
open,
telemetry
protobuf
or
the
compiler
warning
patch.
So
I
fixed
this
sounds
good
yeah
because
you
need
to
introduce
per
photo
buff
other
than
otop,
so
yeah.
A
Sounds
good,
the
third
one
we
just
discussed
and
I'll
add
some
comments
of
the
fourth
one
I
actually
merged
the
patch
workaround
patch
in
google
protobuf.
They
accepted
it.
They
already
merged
it
in
the
master,
yeah.
B
A
I
also
sent
the
same
similar
patch
for
the
slightly
older
release
to
dc
package.
They
also
approved
it,
but
I
don't
know
if
they
follow
some
release
cabins
and
I
don't
know
when
they're
gonna
officially
release
my
part
like
if
you
contract
with
us
master
branch,
we
have
to
track
to
some
of
their
release
labels
and
it
might
be
like
june
end
of
june
or
july
when
they
release
it.
That's
why
I
sent
this
patch
for
us
just
as
a
temporary
overlay.
A
Let's
see
to
make
sure
that,
for
example,
if
we
build
stdlib
with
c
plus,
plus
20
and
now
we're
built
with
the
latest
released
compiler,
it's
all
gonna
pass.
Okay,
so
that
one
should
hopefully
be
being
later
this
week,
I
see
late
already
approved
yes
now.
B
A
We
have
to
revert
that
yes,
so
it's
like
there's
that
vc
package
install
dash
dash
overlay,
so
we
will
need
to
remove
that
dash
dash
overlay
and
we
need
to
delete
that
local
local
overlay
patch.
That
way,
we
would
pull
the
the
latest
one,
because
the
main
line
already
has
the
fixes
slash
patches.
Yes,.
B
And
I
have
one
more
question:
could
could
there
be
any
problem
if
I'm
using
the
latest
vc
package,
not
using
the
one
under
our
ripple
sub
module,
I'm
using
a
separate
clone
and
I
think
the
latest.
A
A
With
the
latest
patch
on
older
vc
package,
but
I
don't
know,
what's
going
to
happen
because
see
for
the
benchmark,
we
also
use
overlay
right
now
for
bc
package
benchmark.
We
use
slightly
older
benchmark
and
there's
there
were
some
build
issues
which
I
work
around
it
in
that
one.
I
didn't
change
any
of
the
source
code.
A
Much
it
was
like
a
one-liner
fix
and
benchmark
has
been
fine
for
like
a
few
months
now,
I
would
say
that
custom
overlay
for
protobuf
is
probably
gonna,
be
fine
for
another
few
months
like
three
four
months,
and
I
hope
that
in
three
four
months
we
should
be
able
to
just
delete
that
okay
yeah
it's
a
bit
hacky
way,
but
it's
a
way
to
customize
and
apply
our
real
local
patches
until
these
patches
get
merged
in
mainline.
B
A
Yeah
yeah
I'll
I'll,
add
that
to
the
I
I
did
the
link,
the
the
protobuf
and
this
one's
called
merged.
All
good
yeah.
A
Vc
package,
so
I
followed
all
their
process,
but
they
also
upgraded
their
compiler
to
1610,
ironically
just
just
recently,
and
they
had
some
other
unrelated
packages
build
failures
in
ci.
A
Like
three
totally
different
unrelated
to
protobuf,
so
I
I
can
check
I'll
update
the
the
issue
to
refer
to
the
main
vc
package.
Pr-
and
I
also
indeed
include
that
reference
to
my
mvc
package.
B
B
A
Default,
I
think
11
and
we
are
not
setting
it
to
20
or
I
think
default
is
maybe
c17,
because
when
we
build
with
no
with
no
std,
we
don't
enforce
20.
Okay,.
B
A
If
we
try
to
build
with
st
with
stl
it
forces
and
on
latest
compiler,
when
c
plus
plus
latest
flag
is
passed,
it
enables
that
feature
new
feature
that
they
added
constant
it
and
the
way
how
google
uses
that
const
in
it.
For
some
reason,
I
don't
know
who's
whose
bug
it
is,
if
it's
improper
usage
of
the
feature
or
if
it's
a
gap
with
the
way,
how
latest
compiler
msvc
implements
that
constant,
but
either
way
it's
one
of
these
things.
A
A
A
Plus
plus
latest
that
enables
questing
in
feature
and
there's
that
check
feature
check
has
feature
whatever
costing
it.
So
then
that
gate
works
because
compiler
reports
that
it
supports
that
feature
and
then
protobuf
defines
a
macro
which,
in
a
bunch
of
places,
tries
to
apply
that
attribute.
A
A
A
A
A
See
what
happens
is
we
had
this
discussion
before?
Somebody
was
telling
me
that
instead
of
checking
language
standard,
we
have
to
be
doing
feature
checks
cool.
So
if
we
do
feature
checks,
is
there
a
way
for
me
to
keep
language
standard
in
general
at
20,
but
then
selectively,
toggle,
just
one
feature
off.
Yes,
that
was
an
idea,
was
that
creatures
bro
well
either
broken
or
not
being
used
properly
by
protobuf,
and
I
didn't
find
so.
A
I
was
just
thinking
like:
let's
just
do
a
simple
hack
and
fix
it
in
the
the
actual
code
in
protobuf
glad
that
they
accepted
the
patch
yeah.
B
A
Yeah
thanks
and
for
the
for
the
last
one
that's
been
food
with
stl.
I
did
did
add
some
check
for
to
address
that
report.
It's
about
gta
gsl
span,
so
in
short,
quick,
quick
recap.
Gsl
span
is
the
only
I'd,
say,
standard
compliant,
implementation
of
std
spam
back
ported
for
all
their
compilers
and
there's
that
document
cpp
core
icpp
core
guidelines,
icpp
core
guidelines
refer
to
gss
spam.
They
can
endorse
and
recommend
it
as
the
only
compliant
implementation.
A
A
We
do
different
things
and
that's
why,
when
I
was
looking
at
initial
comparison
which
span
I
want,
I
took
gsl
span
and
it
also
included
this
part
of
c
mic,
build
and
a
sub
module
right
now.
So
technically
we
always
have
it
in
the
build.
Now.
My
worry.
A
I
still
have
that
worry
and
I
need
to
think
a
bit
more
when
we
build
the
sdk
and
we
install
it
on
the
linux
machine
and
let's
say:
if
we
build
with
gsl
spam,
does
it
mean
that
we
somehow
also
have
to
install
the
gsl
span
on
that
system
or
do
we
need
to
copy
gsl
spam
as
part
of
our
api
headers
and
it's
becoming
a
bit
messy?
B
This
gsl
span
has
a
large
code
base
or.
A
Not
really,
I
think
it's
a
single
header
or
two
headers,
so
it's
definitely
way
lesser
than
upsell,
because
for
upsell
I
had
to
shred
two
pieces
to
to
fit
it
in
jail
cell
span.
I
think
it's
just
one
header.
A
Hoping
should
work,
I
I
need
a
bit
more
time
to
think
about
it.
Okay,
yeah
thanks
and
the
next
one
I
think
lalit
is
gonna
cover,
so
we're
good.
B
A
And
I'll
add
my
comments
about
the
span
like
concerns
and
I
in
general
I
kinda
agree,
but
I
see
some
issues
with
moving
too
fast
with
this.