►
From YouTube: 2021-04-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
B
Yeah
I
was
trying
to
sort
out
a
few
things
with
different
compilers
like
it's
interesting,
because
we
have
to
support
c,
plus
plus
11,
14,
17
and
possibly
the
latest
and
on
api
surface.
B
Even
when
I
take
the
etw
exporter,
not
even
going
deep
into
sdk,
but
just
api
headers,
we
have
all
those
features
like
variant
as
well
as
the
span
so.
B
Our
two
bleeding
edge
features
which
are
technically
not
there
in
older
in
older
standard
right
yeah.
That's
true,
and
there
are
a
few
flags
which
are
not
default
in
visual
studio,
for
example
the
flag
that
detects
the
language
standard
like
underscore
underscore
c,
plus
plus,
you
actually
have
to
turn
on
a
compiler
flag
to
start
reporting
what
language
star
and
their
radius.
And
while
we
deal
with
many
of
these
aspects
in
our
standard
build
when
it
gets
to
the
actual
customer,
build
especially
different
flavors,
it's
becoming
a
lot
of
fun.
B
Sorry
for
derailing
this
I'll
mention
it
later
in
the
call
hi
guys.
B
B
Yeah
sure,
because
we
sh
definitely
need
some
document
which
kinda
describes
compiler
language
standard
dependencies
and
maybe
even
if
we
go
with
like
standard
library
like
implementation
of
spam
and
variant,
what
is
needed
because
some,
the
the
funniest
part
is
suppose
plus
17,
where
you
don't
have
span
yet,
but
you
do
have
variant.
So
it's
like
you
can
reuse
the
standard
variant,
but
you
need
to
borrow
the
span
implementation
from
elsewhere.
B
That's
it
so
c,
plus
20
is
the
best
because
it
already
has
all
the
features
which
are
required
for
for
the
api
surface.
That's
best
or
the
oldest
is
the
best
like
c
plus
plus
11,
where
we
take
the
entirety
of
nominated
classes,
but
something
in
the
middle
half
half
that's
becoming
a
bit
more
fun.
I'll.
Add
this
to
my
channel.
B
B
A
C
A
A
A
A
Okay,
I
think
we
we
can
start.
My
first
question
is
about
the
treasure
provider
get
tracer,
remember.
Member
function.
This
function
is
in
in
is
a
virtual
function
from
the
twister
provider
from
api
and
sdk
implements
it.
But
sdk
returns
the
the
get
tracer
retains
sdk
tracer
object,
but
it
retains
it
as
a
pointer.
I
think
it's
unique
ptr
as
a
unique
ptr
to
the
bay
to
the
base
base
base
class,
which
is
tracer
from
api.
A
So
this
is
a
problem
as
when
we
return
a
pointer
to
the
base
object
and
for
the
tracer
that
destructor
is
not
virtual
and
and
also
the
sdk
tracer
object
inherits
from
enable
enable
shared
from
base
class,
I
think,
and
for
this
class
it's
it's
disrupt.
Disruptor
is
also
non-virtual
seems
by
purpose
on
purpose
for
performance.
A
So
this
I
think
this
could
cause
problem
that
if
the
trees
provider
releases
the
tree
or
the
trees,
but
the
user
still
holds
a
reference
to
the
tracer
object
and
then
it
releases
it
after
the
tracer
provider
is
destructed,
then
it
could
be
released
as
a
base
class.
Then
could
it
cause
memory
memory
leak?
Because
because
the
destructor
is
not
is
not
virtual
right,
because
just
because
we
return,
we
return
our
base
base
class
pointer.
So
it
doesn't
call
the
derived
destructor.
B
Tom
can
we
get
back
to
the
performance
part
part?
You
mentioned
that
maybe
it's
intentional
because
of
the
performance
consideration.
A
That's
for
the
tracer
object.
It
inherits
from
the
enable
shared
from
this.
That's
a
that's
a
generic
class
from
provided
by
sstr
right
for
that
one.
That
class
also
has
its
own
destruction,
but
it
doesn't
mark
it
as
virtual,
which
means
the
rsdk
tracer,
which
inherits
it.
Also.
I
can't
doesn't
declare
the
destructor
as
well
as
virtual
right.
Well,
we
can't
override
it
because
the
base
is
not
virtual.
A
Currently
seems
we
try
to
return
to
return
a
pointer
to
the
user,
so
the
user
can
can
release
it.
Somehow
I
think
the
return
type
is
share.
The
ptr,
rather
than
unique,
p,
typically,
because
unique
peter
has
has
only
one
owner.
Let
me
double
check
the
signature.
I
think
that's
it.
Yes,
it
returned
get
tracer
returns,
no
std
share
the
pointer
so
since
it
tries
to
share
the
ownership
with
within
the
caller,
who
calls
sketch
tracer.
A
Yeah
I
found
this
problem
when
making
a
change
of
instrumentation
library.
Currently
this
is
not
a
real
problem,
because
our
tracer
provider,
the
sdk
tracer
provider,
always
distracts,
I
think,
after
the
last
which
in
which
so
it
distracts
people
after
the
germ
pointer
return
it
to
user.
So
that's
fine
because
your
trees
are
provided,
earn
points
to
the
real
sdk
tracer.
So
it
calls
the
right
destructor.
A
B
I
I
can
comment
on
on
similar
ratio
which
we
hit
so
a
little
bit
of
history
like
we
have
another
sdk,
which
we
often
use
in
microsoft,
internal
products
everywhere,
and
it's
a
common
issue
where,
for
example,
you
obtain
a
tracer
or
logger
whatever
you
name
it
and
you
operate
on
it,
whereas
the
system
is
being
shut
down.
B
For
example,
user
end
forcibly
terminates
the
app
like
force,
squid
up
and
there's
a
single
point
where
the
app
knows
that
it's
about
to
die
right,
but
there
are
some
unjoint
threads
which
are
still
referring
to
those
tracer
objects
right.
So
technically,
then,
the
ideal
answer
is
the
single
main
thread.
That
actually
knows
the
application
stage
should
signal
somehow
to
all
the
unjoint
threads
and
say:
hey.
B
You
guys
cannot
log
anymore
because
I'm
about
to
die
right
now
and
I
need
to
shut
it
down
so
then
reusing
the
object
after
the
shutdown
of
general
elementary
system
is
a
user
error
and
the
best
we
can
do
is
to
turn
that
somehow
into
zombie
a
tracer
which
doesn't
effectively
nothing
if
we
ever
can
do
that
at
all,
and
in
that
case
the
side
effect
is
user
loses
telemetry,
some
of
them
might
scream.
Because
of
that
they
say
hey.
I
cannot
lose
my
telemetry
because
I'm
logging,
some
security
audit
related
events.
B
Well,
the
answer,
then,
is:
you
should
immediately
interrupt
the
operation
and
say
I'm
about
to
die.
I
cannot
block
telemetry
anymore
and
maybe
describe
the
behavior
if
you
continue
using
it
in
that
state
is
undefined
that
be
more
honest
than
trying
to
do
anything.
At
this
point
I
mean
just
say
that
you
cannot
do
that.
Don't
do
that.
B
I
don't
know
what
you
guys
think
we
just
document
a
misbehavior
or
yeah
at
first.
If
we
have
better
options,
we
can
remove
that
blurb
and
provide
an
answer,
but
for
now
we
can
say:
don't
do
that.
Can
we.
C
B
So
if
there
is
a
single
place
like
in
the
main
thread
that
terminates
or
destroys
or
unloads
the
tracing
providers,
the
behavior
of
what's
going
to
happen
to
the
treasures
could
be
non-deterministic
so
avoid
doing
that.
I
guess
right
or
what
other
answer
can
we
give,
because.
C
I
went
to
tom's
initial
description
of
the
problem.
Well,
I
don't
100
understand
because
I
mean
we,
we
hold
a
shared
pointer
to
the
tracer
in
the
tracer
provider.
We
return
this
to
the
user
and
basically
the
the
memory
will
to
for
the
tracer
will
be
freed
when
the
last
instance
of
this
shared
pointer
goes
out
of
scope.
So
if
that's,
if
the
user
keeps
under
the
shared
pointer,
the
tracer,
the
tracer
will
not
be
freed
by
our
by
our.
A
But
the
problem
is
the
pointer:
will
return
to
the
user
points
to
the
base
class.
So
when
swing,
if
the
user
frees
the
sdk
at
last,
then
it
will.
It
could
leak
memory
because
the
destructor
is
not
virtual
right,
so
the
user
just
calls
the
base
destructor.
A
Yeah
because
get
the
tracer
that
the
function
is
defined
in
the
api,
so
I
think
it
makes
sense
to
to
return
a
shared
pointer
to
the
base
class.
It
doesn't
see
that
derive
the
one
or
it
just
returns
a
row
pointer,
so
it
doesn't
take
any.
C
Just
another
just
a
look
at
the
source
code,
and
it
seems
that,
even
even
when
we
construct
this
point
that
we
construct
also
in
inside
the
tracer,
provided
a
pointer
that
the
shared
pointer
is
a
shared
point
to
do
the
base
gas
so
wouldn't
then
even
like
if
the
user
doesn't
keep
on
just
wouldn't
every
ordinary
shutdown
of
the
tracer
provider
also
calls
this
leak.
You're
talking
about.
C
Because
also
the
point
that
the
sharepoint
in
the
tracer
provider
in
the
sdk
tracer
provided
a
shared
point
that
the
tracer
provider
keeps
track
of.
It
is
a
shared
pointer
to
the
base
class
of
the
tracer
in
the
tracing
rider.
Like.
A
C
A
C
A
C
A
Yeah,
and
one
thing
I'd
like
to
confirm
is:
is
it
a
supported
scenario
for
the
user's
code
to
to
distract
or
choose
a
provider
and
create
oh
yeah.
B
B
Only
the
cases
like
abnormal
termination
is
when
we
need
to
see
where
there
might
be
a
thread
running
and
you
are
terminating
the
main
forcedly,
but
then
you
still
want
to
log
something.
Like
those
cases
you
know
I'd
rather
see
this
happening.
A
lot
in
clients,
scenarios
and
lessen
the
cloud
services.
B
It's
like
in
the
cloud
service,
you
start
and
run
forever
until
you
crash
and
you'd
probably
try
to
never
crash
now.
D
I'm
just
thinking
about
scenarios,
I'm
not
sure
how
how
important
are
those
at
the
moment
when,
when
someone
is
trying
to
use
like
a
valgrind
or
any
memory
tool
for
his
own
program
to
check,
does
it
have
any
memory
leaks
at
all?
A
My
apparently
we
will
not
hate
the
issue
even
in
some
instrumentation
tool
like
walgreens,
because
I
think
from
our
current
test
case,
trees
provider
will
always
be
distracted
at
last
or
at
process
for
process
exit
time.
So
that's
fine
because
we
implicitly
force
the
order
and
asked
only.
D
A
A
But
the
letter
that
should
retain
the
tracer
object
still
be
being
used
and
if
this
scenario
is
valid,
I
think
this
will
trigger
the
memory
leak
or
any
validation.
B
B
Okay,
and
maybe
in
the
api
description
of
the
provider-
lifecycle,
something
like
that,
like
in
the
base
class
provider
life
cycle
added
statement
that
if
the
program
are
terminating
abnormally
and
somehow
the
trace
provider,
implementation
goes
out
of
scope.
B
C
A
C
C
A
C
C
C
I
see
okay,
you
know
I
think
we
should
have
to
also
I
mean
to
completely
understand.
I
would
have
to
look
at
this
enable
charge
from
this
implementation
because
that's
kind
of
might
might
be
possible.
There
are
some
magic
involved
there,
but
yeah.
I
understand
understand
the
point
you're
making.
A
A
A
A
C
Yes,
I
just
quickly
looked
something
up
bomb
regarding
the
inevitate
from
this,
I
will
also
put
something
into
chat,
and
basically
it
says
in
the
chat
is
that
in
this
article,
what
it
says
is
that
you
need
a
virtual
destructor
in
the
in
a
certain
base
case
if
you
wanna
delete
the
object
with
a
pointer
to
this
base
class.
C
So
if
we
have
a
pointer
to
the
api
tracer
class
and
we
delete
this
pointer,
then
we
need
a
virtual
structure,
so
the
order
bases
are
called,
and
the
lack
of
this
destructor
in
every
shared
pointer
from
this
case
would
only
be
a
problem
if
the
user
would
kind
of
cast
the
point
or
that
we
return
to
this,
enable
shared
pointer
from
this
class
and
then
delete
that
pointer.
A
C
So
it's
also
described
in
this
article
that
I
that
that
I
put
into
chat-
maybe
this
that's
that's
at
least
so
I
understand
it.
Maybe
we
all
can
look
into
this
and
make
sure
that
well,
the
understanding
is
correct.
A
I
think
I
because
I
I
assumed
it
is
memory
leak
because
actually
making
my
pr
I
I
changed
the
co
part
of
the
code
to
ask
the
to
distract
tracer
provider
before
the
the
user's
tracer
tracer
object,
because
before
it
and
then
get
some
access
violation,
yeah
in
the
code,
so
yeah.
Let
me
dig
this
deeper
and
yeah
put
the
data
into
into
the
ticket.
B
Yeah,
so
this
is
not
directly
my
question,
but
I
saw
that
there's
a
good
discussion
going
on
about
the
issue
is
that
as
we
upgrade
our
dependencies-
and
I
have
seen
this
in
the
past,
we
end
up
sometimes
having
to
upgrade
the
tooling
as
well.
So
it's
like
on
old
gcc
4.8.
We
have
one
set
of
dependencies
that
are
working,
but
then
one
of
our
dependencies
decides
to
stop
support
for
an
older
compiler
and
then
what
exactly
do
we
do?
B
Do
we
just
say
we
froze
that
dependency,
only
for
the
old
compiler
combo
and
on
latest
build.
We
allow
to
build
with
something
more
recent
like
in
grpc
case,
for
example.
B
I
don't
know
what
do
you
guys
think
it
seems
like
also
this
specific
issue
was
only
the
problem
for
bazel
built
somehow,
and
there
was
also
another
good
question
about
vc
package.
Technically,
we
don't
have
to
require
it.
We
see
packages
more
like
convenience
layer,
because
users
may
manually
provide
all
their
dependencies
paths
to
dependencies
to
cmake
without
needing
vc
package.
So
that's
where,
for
example,
a
question
like:
oh,
we
upgraded
vc
package
to
something
more
recent,
and
now
we
require
gcc6.
B
Well,
that's
bad
answer,
because
vc
package
itself
is
an
optional
dependency
and
it
should
not
dictate
what
compiler
we
need.
So
it
seems
like
it's
all
like
a
long-term
maintenance
pain
because,
as
we
committed,
for
example,
4.8
holds
us
back
then
we
have
to
say:
yes,
we
are
still
supporting
it,
and
these
are
the
only
depths
that
would
work
with
it,
including
this
is
the
last
version
of
grpc,
for
example,
that
works
for
it
or
we
make
that
call
and
we
say
hey.
B
Finally,
we
can
we
don't
support
gcc
four
anymore.
We
require
classic
cc
whatever
six
right,
I
mean.
How
do
we
tackle
this
in
general?
What's
your
opinion?
My
feedback
right
now
is
for
that
build
failure
that
we
are
encountering
with
bazel.
B
Can
we
get
a
confirmation?
Is
that
bazel
users
still
need
4.8
or
from
the
companies
represented
in
this
forum?
Can
we
just
say:
stop
supporting
bazel
legacy
based
off
4.8
and
requires
something
more
recent
I
mean
like.
I
don't
need
basil.
I
don't
need
4.8
who
needs
bazel
and
who
needs
bazel
with
4.8.
A
B
C
B
And
I
think
this
is
fun
because,
as
we
get
to
support
more
exporters
standard
exporters,
we
would
encounter
this
issue
again
with
other
scenarios.
Like
I
don't
know,
lib
curl,
for
example,
because
it's
like
a
tree
growing
in
different
directions
and
see.
We
have
all
these
stars
aligned
in
a
way
that
if
it
is
basal
and
if
it
is
otlp
and
if
it
is
4.8,
then
we
have
a
problem
on
this
path.
Only
like
then
somebody
who
needs
it
should
appear
to
downvote
or
say
yes,
I
still
need
it.
B
B
In
my
opinion,
let's
just
remove
that
from
ci
loop
and
let's
just
integrate
the
change
and
be
done
with
it,
and
we
say
that
for
this
path
you
still
have
an
option
of
manually
building
with
manually
specifying
an
older
version
of
grpc
and
manually
building
with
cmake
only
and
you
cannot
use
vc
package
and
there
used
to
be
a
build
script.
That
is
doing
it.
So
if
you
need
that
specific
build
combo,
you
can
get
that
and
if
you
are
running
into
problems,
feel
free
to
contribute
a
patch
to
keep
that
same
right.
B
D
B
Compiler
works
and
I
think
the
issue
was
that
the
latest
package
that
we,
that
is
known
working
with
older
bazel,
was
jrpc
one
point,
thirty
three
or
something
then
it's
captured
in
the
ticket.
So
it's
like.
If
we
take
a
dependency
on
a
newer
version
of
the
package,
then
we
also
need
the
newer
bazel
and
we
need
a
newer
package
version
and
it
seems
like
we
end
up
needing
a
new
compiler
as
well.
So
it's
like
the
whole
set
of
depths
now
requires
more
modern
things.
D
B
D
B
Yes,
but
extended
security,
maintenance
and
new
instrumentation
are
probably
two
different
things.
It's
like
when
we
release
how
we
give
recommendations
and
guidelines
how
to
instrument
some
more
modern
products.
With
that
I
mean
legacy.
Products
would
probably
not
be
instrumental,
I
don't
know,
and
for
the
legacy
products
they
can
still
so
just
a
moment
in
2020,
okay,
eight
yeah,
it's
still
about
a
year,
okay,
so
for
14.4,
14.04
long
term
support
is
until
april
2022.
B
Let
me
actually
capture
that
I'll
I'll
capture
that
in
the
the
document,
it's,
I
guess,
the
only
so
ubuntu
4.4
comes
with
gcc
4.4
by
default.
You
can
still
install
more
recent
compiler
on
it
right
and
supported
until
april
1922.
B
So
if
we
are
planning
to
release
something
that
compiles
with
the
default
set
of
dependencies
in
the
image,
without
installing
any
updates
like
more
recent
compiler
updates
like
on
that
clean
all
the
original
image,
then
I
think
the
issue
is.
We
can
tell
how
to
build
with
planes
he
make
and
the
no
bazel
it's
only
if
somebody
also
wants
to
build
with
bazel
on
that
they
will
run
into
problems.
A
B
Tom,
when
I
initially
integrated
the
docker
image
and
the
build
script,
I
only
used
protobuf,
I
used
protobuf3
and
I
think
back
then,
four
months
ago
we
did
not
have
the
fully
working
or
tlp
with
grpc.
B
So
I
must
admit
that
I
have
not
actually
tested
it
on
latest
code
base.
I
don't
know
the
answer,
and
maybe
it's
a
valid
point
that
we
can
say
that
now
for
the
otlp
protocol
and
for
the
recent
grpc
we
cannot
support
supported
like
I
can
take
an
action
item
and
try
compiling
the
latest
code
base
with
grpc
using
the
docker
image
setup
that
I
had
four
months
ago
and
give
an
answer
to
you.
If
I
run
into
problems
or
not
okay,
if
that
works.
B
So
I
can
take
an
action
item
to
try
that
docker
image
with
the
c
make
build
and
the
grpc.
A
Yeah,
I
think
once
this
is
confirmed
like
the
gcc
4.8,
I
think
it
only
supports
c
plus
plus
11
range.
So
if
c
plus
14
is
required,
probably
we
can
just
remove
the
width
underscore
otrp
in
our
yes
4.8
support
right
for
all
others.
It
should
still
be
good.
B
But
then
what
then,
what
transport
we
recommend
is
it
going
to
be
like?
Is
there
otp
gesturing
protocol,
or
are
we
even
gonna
support
it
well
like,
if
not
yeah,.
B
B
Because
if
we
had
json
support
then
do
we
still
need
jpc
for
that?
How
does
that
work?
I'm
not
sure.
So,
originally
we
were
only
using
protobuf
and
protoc,
and
I
had
it
working
before.
A
Or,
like
you
you
mentioned
previously,
if
any
user
has
had
a
requirement
on
gcc
4.8,
okay
need
to
tweak
the
build
script,
to
specify
an
old
jrpc
to
use.
C
B
For
anything
that
comes
pre-built
like
for
pre-built
sdks,
not
for
products
but
for
sdks,
usually
I
think
there's
that
freedom,
where
we
say
no,
you
guys
have
to
use
at
least
gcc
six,
for
example,
and
this
is
the
article
how
you
install
it
and
how
you
compile
it.
It's
more
like
the
original
product
that
is
shipped
with
the
distro,
that's
been
built
with
the
old
compiler,
and
that
is
loading
some
runtime
library.
B
A
Yeah
and
I
think,
provide
the
option
to
customize
grpc
makes
sense,
as
I
think
I
worked
with
some
some
customers
and
I
think
who
has
some
requirement
on
specific
jpc
which
may
pass
the
internal
review,
so
they
don't
just
upgrade
to
the
latest
branding,
so
they
have
at
least
which
dependencies
they
can
use.
B
So
I
think
it
makes
sense.
So
what
I'm,
what
I'm
trying
to
understand
so
for
the
next
long-term
supported
version
of
ubuntu,
for
example,
1604,
and
it
does
come
with
the
new
compiler,
which
I
think
7.1.
B
So
it's
like
there's
a
huge
leap
in
between
14
and
16..
So
the
issue
of
formally
supporting
gcc
point
for
4.8
is
only
for
the
next
one
year,
one
full
year.
B
B
B
I
don't
know
like
since
we
are
releasing
this
year
and
since
there's
another
distro
prominent
distro,
which
has
long-term
support
policy
of
4.8
for
another
year.
I
don't
think
we
can
break
it
right
now
and
I
think
we
need
to
have
some
write-up,
but
if
you
have
that
that
that
you
can
use
this
build
script
to
build
open
telemetry
with
an
older
jrpc
version,
something
like
this.
B
So
let
me
try
tom.
Let
me
try
the
latest
codebase
with
the
older
image
and
without
nc,
where
I
can
get.
Maybe
my
immediate
proposal
would
be
to
remove
basel
gcc48
from
ci,
okay,
that
shouldn't
block
that
pr
at
least
okay
thanks
yeah
sounds
good.
Maybe
george.
Can
we
can?
We
are
saying
that
action
item
on
josh
to
give
his
feedback
like
from
google's
site?
Do
they
require
bazel
ngcc
4.8?
A
That's
a
good
question
max:
do
you
know
the
history
of
the
gcc
4.8
ci
circuit
or
this
yeah.
A
B
Open,
I
think
it
was
needed
for
light,
step
and
void
and
might
be
mistaken
guys.
C
B
And
I
think
it
was
reasonable
extreme
well,
it
was
reasonable
a
year
ago,
more
than
a
year
ago,
because
again
there
were
distrusts
that
were
out
there
with
long
term
support
as
of
that
moment
for
another
two
and
a
half
years
right.
So
when
you
do
something
and
you
plan
for
that,
yes,
I
guess
you
have
to
support
it
now
as
those
vanish
over
time
and
as
we
move
on
maybe
at
some
point
next
year,
maybe
mid
next
year.
B
C
I
mean
customers
out
there,
the
use
of
old
systems
and
I
can
see
them
using
gcc,
for
they
don't
even
older
versions.
But
I
think
that's
a
question
we
have
to
answer
before
our
1.0
release,
because
I
think
that
maybe
it's
the
ideal
point
to
drop
any
for
the
date
support,
because
it
previewed
if
you
release
1.0
with
for
the
date
support
and
then
a
few
months
or
half
a
year
later
we
gonna
drop
support.
I
think
that's
a
situation.
We
should
avoid,
if
possible,.
B
I
think
from
the
commercial
standpoint
yeah
there's
a
cost
maintenance
cost.
So
if
there's
a
company
that
sells
a
product
for
the
customers
who
run
on
that,
we
would
expect
contributions
from
those
companies
in
open
source
to
keep
that
thing
running.
So
if
we
don't
have
interest
in
maintaining
that
within
that
community
of
regulars
right,
we
can
say
hey.
We
have
that
item
on
the
agenda
proposal
to
drop,
bazel,
4.8
and
then
like
who
showed
up.
They
would
who
didn't
show
up.
They
don't,
and
that
should
be
fair.
I
hope
so.
C
A
B
D
D
B
B
I
needed
some
help
from
open
telemetry
organization
admins
to
create
that
repo
and
the
folks
who
helped
me
back
then
sergey
kangelev,
for
example,
they
do
have
access
to
security,
searchings
and
additional
settings
like
who's
admin
or
not.
I
checked,
I
cannot
add
people
myself
can.
B
Send
me
his
name
on
slack.
Please,
yes,
I'll,
send
you
his
name.
I
remember
sergey
definitely
participated.
You
actually
find
his
name.
If
you
look
at
the
history
of
the
rico,
he
is
one
of
the
contributors,
one
of
the
first
contributors
who
created
people
he
has
one
single
commit
and
that
single
commit
was
enable
cla.
B
A
I
think
the
now
apr
is
a
grpc
upgrade
jrpc.
A
A
A
B
A
Valid
said,
it
will
take
some
too
some
time
to
review
it,
but
thomas,
could
you
also
help
review
this
part?
I
think
you
are
interested
in
this
one
right.
B
I
I
actually
remembered
something
if
you
guys
don't
mind
real,
quick,
so
fluent
fluent
d,
there's
a
scenario
where
I'd
be
needing
potentially
a
fluent
forward
protocol
exporter,
and
I
was
wondering
like
I'm,
going
to
send
a
pull
request
for
the
country.
People
because
fluent
my
understanding
is
not
in
the
list
of
standard
exporters
required
by
spec.
B
But
if
there's
some
community
interest
in
supporting
various
layers
like,
for
example,
this
unix
domain
socket
tcp,
udp,
http
receivers
in
the
fluent
itself,
and
all
of
them
may
accept
that
fluency
forward
protocol
by
default.
I
think
it's
message
pack
and
code,
so
I'm
gonna
contribute
a
unix
domain
circuit
transport
channel.
Only
not
gonna
cover
the
other
transports,
for
example
http
client
layer.
B
But
if
there's
an
interest
in
community
in
maintaining
fluent
exporter,
I'd
be
glad
to
share
some
of
that
and
I'm
gonna
commit
a
pr
with
the
code
owners
specifying
like
me
as
the
code
owner
right
now.
But
I
do
not
claim
that
I'm
the
only
code
owner
because
I
think
there
might
be
others
interested
in
interested
in
fluent
export.
If
that
makes.
B
B
That's
a
that's
about
it.
Just
heads
up
that
I'm
planning
to
submit
a
fluent
exporter
to
contribute.
A
B
There
are
flows
where
we
need
this
exporter
and
since
it's
an
open
standard
and
an
open
protocol,
it
be
much
easier
for
us
if
we
democratize
that
and
share
the
code
and
get
some
community
feedback
and
make
it
better.
Based
on
community
feedback.
A
Okay
and
for
for
our
message
pack
exporter,
I
remember
you
mentioned
that
we
have
some
private
extension
right
or
how
do
you
handle
that.
B
That
was
the
case
for
etw.
It's
no
longer
the
case
so
for
etw.
By
default,
I
already
finished
the
proper
legal
process
to
open
source
the
trace
logging
dynamics
framework
we
merged
it.
What
it
gives
is
that
all
the
existing
tools
on
windows
like
for
event
tracing
for
windows
can
now
receive
open,
telemetry
events
through
the
etw
exporter
and
I'd
rather
use
that
flow
instead
of
message
pack
encoding
of
the
actual
event
payload,
so
that
discovered
I'm
more
interested
now
in
proper
fluent
exporter.
B
A
Okay,
I
think
if
we
don't
don't
have
other
topics,
I
think
yeah
we
can.
We
can.
I
will
return
six
minutes
to
two.