►
From YouTube: 2020-11-18 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
B
B
A
Sure
yeah,
I
just
wanted
to
follow
up
with
you
guys
on
good
review
of
my
two
prs.
Both
are
passing
tests.
There
are
some
comments
which
I
will
address.
I
agree
with
most
comments.
Most
of
them
are
documentation
style
comments
like
explaining
how
things
work,
because.
A
A
I
don't
really
have
other
topics
like
I
wanted
to
propose
that
when
we
do
the
release,
we
can
reuse
the
stuff
that
I
did.
I
also
added
the
draft
pc
package
support
which
allows
you
to
like.
We
still
need
to
take
that
file,
integrate
it
in
the
vista
package,
repo
like
sending
in
a
pull
request
for
them
to
accept
it,
and
then
there's
going
to
be
an
easy
and
hopefully
easy
intuitive
way.
A
For
those
who
familiar
with
this,
install
the
sdk
header
source
and
even
compile
it
and
optionally
run
all
the
tests
and
have
it
under
like
build
tree.
A
Right,
yes,
that's
that
we
can
add
that,
because
that's
one
way
to
consume
it
and
I
think
it's
an
easy
way
to
consume
it.
I
have
gotten
some
feedback
from
community
like
from
people
working
in
a
visual
which
seems
like
a
one
way
to
to
use
the
the
results
of
what
we
see
in
visual
studio.
B
I
see
and
okay-
maybe
I
think
we
can
start
today
and
riley-
has
a
has
an
urgent
meeting,
just
yeah
yeah,
so
I'll
help
him
drive
this
meeting
today
and
well.
We
are
we're
going
to
start
yeah
everyone,
please
add
your
your
name
to
the
attendee
list.
Thanks
and
I
will
share
my
screen.
B
Hi
I'm
a
little
raleigh
and
has
an
urgent
meeting
this
morning,
so
we
will.
I
will
help
him
drive
this
meeting.
So,
okay.
D
B
The
first
one
yeah
I
saw
there's
a
big
pr
forum
from
lalit,
which
is
about
the
initial
test
release
and
as
we
applied
and
the
pr
is
under
review-
and
there
are
many
comments,
comments
going
on
and
lalit.
Do
you
want
to
elaborate
a
little
more
on
that
we
can.
F
C
F
Okay,
so
so
just
just
to
give
a
summary
of
what
what
the
pr
is
about,
it's
basically
how
we
are
going
to
do
the
releases
for
open
telemetry
cpp.
So
I
just
jotted
down
the
steps
for
that
I
mean
what
I
was
basically
doing
was
that
we'll
maintain
a
change
lock
that
changelog
would
contain
for
each
of
the
releases
as
we
are
going
to
do
the
release.
F
The
summary,
the
curated
summary
of
all
the
changes
which
have
gone
so
that
would
be
a
responsibility
of
the
developer,
who
creates
a
pr
as
and
when
he
creates
a
pr,
if
that's
a
functionality
which
should
go
in
the
change
log
he's
responsible
to
put
that
in
the
change
lock
under
under
the
unreleased
section
and
after
that,
once
once
the
time
for
the
release,
the
the
person
who
is
going
to
do
the
release
should
basically
modify
the
change.
F
F
It
will
put
a
new
section
beneath
the
underly
stack
with
with
the
the
tag
name
and
the
date
of
the
release,
and
then
once
it's
modified,
he
will
take
the
release,
notes
from
the
current
release
to
the
github
release
ui
and
is
going
to
use
the
tag
he
has
to
create
the
tag
after
that
and
then
you
he
has
to
use
that
tag
to
actually
generate
the
release.
That's
the
standard
process.
I
saw
it
being
followed
in
other
teams.
Also,
there
were
a
couple
of
points.
F
One
was
basically,
we
should
have
a
version.h
which
meant
which
gives
us
information
of
which
version
we
are
going
to
release
that
should
contain
again
the
tag
which
we
are
using,
along
with
the
probably
the
shk
commit
hash.
F
Probably
that
is
something
which
can
be
added,
but
I
think
I
like
to
hear
from
max
because
he
had.
I
mean
quite
a
few
comments
on
that
process.
A
The
next
step
is
usually
and
one
one
minor
feedback
here
is:
can
we
make
this
process
easy
enough
for
a
product
manager
or
a
product
project
or
product
manager
to
not
need
installing
any
scripts,
because
in
running
any
scripts,
especially
shortscript
requires
you
to
have
like
a
unix
machine
or
windows
subsystem
for
linux?
A
We
can
make
it
user
friendly
so
that
technical
community
member
who
doesn't
even
have
to
have
ide
or
build
environment
can
do
the
release,
and
this
is
very
valuable
because
you
can
outsource
the
release
process
to
a
product
manager.
Who
does
not
need
to
do
the
build
themselves.
So
then,
as
long
as
they
can
create
a
change
log
update
with
all
the
items
we
can
jointly
review
and
once
approved,
they
take
that
section
go
to
the
release
management
tab
in
the
github
ui
and
that's
where
they
create
a
tag.
A
Now
I
assume
that
incrementing
assembler
of
a
product
is
something
that
the
product
manager
should
know
how
to
do,
because
they
must
remember
their
previous
product
version
was
1.0
and
we
can
discuss
what
the
next
release
tag
should
be,
depending
on
whether
we
have
any
abi
breaking
changes
or
not.
So
it's
like
my
proposal
in
general,
is
to
avoid
any
scripts,
follow
the
gui
based
process
and
follow
the
github
established
review
process.
A
So
change
love
is
good
release,
tab
is
good
manually,
creating
tags
is
good
and
what
we
are
still
missing
is,
as
you
mentioned,
and
I
think,
as
tom
mentioned
as
well-
the
actual
version
in
header
like
in
code.
Yes,
because
we
need
to
shield
the
code
from
api
breaking
changes,
which
means
that
I
I
looked
at
how
it's
done
right
now
in
our
header.
We
may
improve
it
because,
right
now
we
have
that
api
version
for
the
namespace
name
and
the
sdk
version.
A
Because
then,
when
we
crash
it's
easier
to
group
our
crashes
based
on
complete,
build
id
right,
like
version
and
reference
to
commit
id
at
least
for
our
systems,
we
do
have
that
crash
grouping
analytics
right,
okay,
and
we
have
to
be
very
precise
on
this,
because
if
one
build
is
something
that
is
official
well
official,
I
mean
produced
by
company
from
source,
and
the
other
bill
is
something
that
I
cooked
like
on
the
side.
A
We
should
be
able
to
more
or
less
precisely
tell
in
most
flows.
Even
we
could
report
the
sdk
version
like
in
the
event
itself
like
in
the
exporter,
that'd
be
actually
cool.
If
our
specific
exporters
also
can
populate
the
sdk
version,
at
least
well,
we
do
it
for
our
internal
flows.
We
do
always
report
how
pre-eminent
with
versions
out
in
the
field.
So
these
are
the
missing
features
which
I
think
we
need
to
implement
in
a
separate
pr.
F
Okay,
so
yeah,
so,
just
to
summarize,
we
don't
need
a
script
here.
It
should
be
the
so
if
we,
the
script,
is
doing
some
changes
in
the
change
log.
That
should
be
a
manual
process
which
product
manager
can
do
it.
Do
it
themselves
modifying
I'm
just
thinking
I
mean.
How
will
that
work,
because
we
still
want
to
modify
the
change
lock?
C
Yeah,
I
mean
again
the
so
can.
Can
we
consider
again
next
to
your
point
that
you
know
how
do
we
make
this
easier
for
pms
or
tpms
to
run
and
and
just
you
know,
get
out
of
the
box?
C
One
of
the
things
that
we
found
very
useful
is
obviously
creating
a
sample
app
and
you
know
creating
a
docker
image
or
and
and
and
providing
a
script
to
be
able
to
do
that
into
it
right
and-
and
I
would
suggest
that
that's
something
that
really
would
help
given
that
you
know
the
sdk
is
most
valuable
when
it
is
bundled
with
a
sample
app
and
then
that
gives
clear
instructions
to
a
customer
or
a
pm
room.
You
know
to
be
able
to
use
that.
E
C
Well
well,
the
two
layers
right
one
is
one
is
of
course,
creating
a
change
longer,
actually
having
a
clear
itemization
of
what
types
of
features
constitute
major
minor
versus
patches.
If
we
were
to
follow
somewhere
and
then
and
and
hence
you
know,
how
does
that
affect
the
change
logs
right?
That
is
what
kind
of
information
is
reported
into
the
change
log
and
then
at
a
different
layer
having
an
full
run
running
environment
with
the
artifacts
generated,
which
are
bundled
with
the
you
know,
simple
sample
app,
which
gives
an
instant
usability.
C
If
you
will
to
the
sdk.
A
We
can
fully
automate
the
build
process
like
we
have
cicd,
where
we're
all
like
all
these
different
platform
build
artifacts,
so
that
we
can
cover
as
part
of
the
pr
review
process
and
that's
part
of
the
release
process.
Yeah
on
the
second
thought
I
actually
do.
I
think
that
some
form
of
a
script
is
valuable,
but
with
manual
modifications,
because
sometimes
you
have
all
these
commits,
which
are
building
fraud
which
are
non-essential
which
could
have
been.
You
know,
bulked
up
in
the
single
commit,
but
it
didn't
happen.
A
So
there's
always
going
to
be
some
manual
tweaking
required,
and
sometimes
you
want
to
articulate
that
a
certain
feature
is
added
so
rather
than
reusing.
The
git
commit
message
from
from
github
you'd
have
to.
You
know,
convey
that
technical
understanding
in
a
statement
like
this
is
decay,
adds
a
new
feature
this
this
this.
You
don't
exactly
extract.
This
excuse
me
and
you
don't
extract
it
from
git,
commit
messages.
You
have
to
write
it
down.
C
Yep,
right
and
and,
and
you
know,
generating
decent
release
notes
based
on
again,
I
think
some
of
it
can
be
handled
in
consistent
process
documentation
that
you
know
these
are
the
types
of
comments
we're
recommending
for
each
commit
again.
These
are
for
new
engineers,
but
you
know
having
a
consistent
flow
documented
for
what.
E
A
On
I'm
generally,
I
already
approved
I'm
not
so
here's
here's
what
I
think
we
should
do
it
it's
a
good
script.
We
may
tweak
the
process.
I
don't
want
us
to
treat
this
process
as
final.
It's
a
good
first
step.
Sure
right,
I
don't
want
to
block
the
spr.
I
really,
I
think
I
believe
I
already
approved
it.
Okay,
so
there's
another
minor
piece
of
feedback
related
to
github
utility.
A
A
Release
process
like
publishing,
release,
notes,
adding
a
build
artifact
to
release,
notes
and
a
lot
of
other
useful
things.
It
can
like
link
issues
or
milestones
project
masters
like
everything.
So
I
think
we
should
use
more
of
that,
because
that
gives
us
ability
to
focus
on
our
internal
things
like,
for
example,
generating
a
version
header
with
the
right
api
version.
All
that
the
more
we
use
official
script,
which
already
exists
like
the
official
tool
that
I
will
read
these
the
less
work
we
have
to
do
to
to
to
kind
of
reinvent
the
wheel.
A
So
I
would
encourage
that
if
we,
for
example,
first
of
all,
I
think
we
process
is
normally
fine
for
most
folks
unless
we
want
to
have
certain
like
milestone,
build
like
nightly,
build
tagged,
and
if
we
want
to
have
night
lease,
which
is
a
community
decision,
if
we
are
planning
to
then
this
gh
utility
is
a
good
way
to
automate
it,
because
you
do
gh
release,
that's
where
lalit
scripts
are
coming
into
play,
where
you
can
increment
this
somehow,
based
on
date,
number
for
example,
and
then
you
do
the
gh
created
it
is
published,
nightly
number
this
for
this
day,
yeah.
A
E
Yeah,
I
have
one
one
question
here
that
just
came
to
my
mind
now
for
that.
Let's
document
and
I
see
that
the
workflow
now
seems
to
be
just-
let
me
go
to
the
pr,
the
divine
pre-release
that
is
h,
which
creates
a
branch
modifies
a
change
log,
and
then
we
create
a
pr
for
that,
but
I
think
shouldn't
the
workflow,
the
workflow
be
that
we
modify
the
change
log.
Maybe
we
go
to
the
version
that
is
h,
then
create
a
pr
get
the
armor
and
only
create
the
tag
after
we
merge
the
pr.
E
I
think
we
have
to
switch
this
around
before
we
before
we
merge.
So
this.
F
A
F
F
A
And
what
do
you
guys
think
about
generating
all
these
relevant
fields
like
version?
Like
short
version,
full
semver
version
commit
id
api
version,
I
think,
with
respect
to
abi
version,
we
either
keep
it,
as
is,
which
is
going
to
be
like
some
number,
which
we
increment
always
somehow
can
probably
tie
it
to
a
ver
major.
Where
minor,
like
you
see
what
I'm
saying
like
computing,
a
a
an
abi
version
based
on
two
bytes,
for
example.
Assuming
that
the
verb
major
is
one
byte
verb
minor,
is
the
second
byte.
A
Right
yeah!
No,
yes,
we
are,
we
are
with
respect
to
releases.
There
is
that
another
field
which
we
currently
use
for
namespace
name
and
I
think
in
the
version
that
edge
is
called
abi,
underscore
version
yes,
yeah,
and
I
think
the
intention
was
that
you
can
attach
it
to
namespace
name
so
that
you
can
kind
of.
A
If
something
changes
drastically,
you
can
have
a
totally
unique
different
namespace
for
the
classes.
A
I
think
this
is
done
for
with
with
goal
in
mind
so
that
you
can
mix
and
match
different
versions
of
open
telemetry
in
one
process
right
so
like
we
might
need
to
tune
it
like
clarify
how
exactly
that
works.
At
least
I
see
this
in
the
version.h
file
right
now,
yeah.
A
Work,
we
need
to
do
a
bit
of
reverse
engineering
and
document.
E
Yeah,
I
think
the
need
for
this
api
version
is
when
you
have,
I
mean
this
practically
enables
you
in
one
process
to
use
different
libraries
that
use
different,
open,
telemetry,
zippers
plus
apis.
A
Yeah
yeah:
this
is
like
the
non-standard
classes,
but
when
we
build
with
the
known
like
v1
v2
v3,
I
think
maybe
the
intention
was
to
just
sequentially
increment.
That
number.
E
C
Yep
I
mean
having
maybe
max
a
compatibility
matrix
is,
is
you
know
a
good
thing
and
and
it
can
be
generated,
but
still
you
have
to
have
it,
because
if
abi
you
know
compatibility
is
a
breaking
change
and
security
vulnerabilities
is
another
category.
C
So
again
determining
you
know
what
are
the
dependencies
which
are
breaking
considered?
Breaking
changes
and
maintaining
compatibility
would
require
a
matrix.
A
We
can
probably
either
reserve
the
third
tuple
of
december
or
the
dash
portion
of
the
assembler
for
the
patches
like
for
the
security
patches
riley
had
that
use
case
when,
for
example,
there's
a
vulnerability
in
one
of
the
dependencies,
but
there's
no
like
prometheus
exporter,
for
example.
We
we
are
already
using
this
prometheus
cpp
client.
Let's
say:
there's
a
bug
in
it
right,
but
there's
no
bug
in
our
code.
We
would
need
to
bump
it
up.
Yep
rebuild
and
the
dash
portion
reflects
exactly
like
what
was
the
source
of
truth,
which
was.
C
C
But
I
mean
we
should
publish
clear
guidelines
on
you
know:
when
does
vendors
the
some
you
know
minor
version
get
bumped
up?
How
does
it
look
and
what
gets
tagged
based
on
the
changes.
A
B
A
It
will
be
incompatible
and
I
think
the
scripts
that
would
be
compatible
with
like
ci
process
to
regenerate
this,
then
there's
another
question
which
I've
personally
faced
in
one
other
project.
Are
we
checking
in
the
generated
files
because,
for
example,
what's
the
benefit
of
gen
checking
in
the
generated
file?
You
generated
it
once
you
checked
it,
then
you
have
a
snapshot.
You
have
tarball
a
zip
file,
you
download
it
and
it
can
be
indexed
and
users
immediately
see
what
version
was
where
they
got
it
from.
A
You
do
not
need
to
rerun
that
regeneration
script.
It's
like
on
just
the
editor
setup.
You
can
still
see
everything
and
everything
is
kind
of
compilable.
That's
the
benefit
of
checking
in
the
generated
file,
and
usually
we
can
say
hey
this
file
is
auto-generated.
Please
don't
edit
that
file
manually,
it's
regenerate
as
part
of
our
like
build
process.
B
Okay,
I
think
this
one
we're
good
right.
Well,
we'll
follow
up
and
merge
the
current
pr
okay.
So
then,
okay,
thanks
and
we
can
move
to
the
next
item
in
agenda
which
is
update,
login
sdk,
I
think
part
of
the
pr
was
merged
and
mark
or
currently
would
you
like
to
give
us
an
update.
G
Yeah
sure
so
it
was
merged
two
days
ago
into
the
main
upstream
and
so
the
pr
that
got
merged.
It
just
contained
the
logger
logger
provider
and
a
like
the
in
the
interface
for
the
processor
and
we're
planning
on
printing
another
pr
today
that
contains
this
simple
processor
and
maybe
later
in
the
week,
the
batch
processor,
and
so
hopefully,
within
the
next
couple
weeks,
we'll
have
all
the
components
of
that
of
the
sdk
upstream
and
like
ready
to
work
and
yeah.
B
Okay
thanks,
so
today
there
will
be
a
new
vr
and
for
you,
elastic
is
logging
the
it
will
not
be
our
terminator.
G
Later
this
week
for
elastic
not
later
this
week,
sorry,
the
batch
processor
will
come
later
this
week
for
elastic
and
the
simple
ostrom
exporter-
that'll-
probably
come,
maybe
next
week
or
the
week
after
that,.
B
Okay
sounds
good
thanks
and
yeah
thanks
for
the
update,
so
I
think
we
can
move
to
the
next
one,
the
next
one
and
it's
from
max
and
about
beauty,
tuning
stuff,
yeah.
So
there's
also
the
appears
and
which
many
comments
there
yeah
max.
Do
you
want
to
elaborate
more.
A
A
A
I
would
like
to
get
the
build
tooling
pr
merged
first,
because
that
will
make
the
second
the
other
seder
lib
pr
much
smaller,
and
then
we
can
proceed
with
the
the
std
lib
pr,
I'm
also
thinking.
A
Perhaps
I
should
send
in
separate
just
the
documentation
to
elaborate
on
all
the
tools
available,
because
what
that
gives
you
the
easy
command
just
one
liner
to
build
everything,
including
setting
up
all
the
dependencies
just
build
shell
or
build
cmd
on
windows.
A
Visual
studio,
2019
build
for
cmake
with
multiple
configurations,
because
visual
studio
2019
already
has
built-in
very
good
support
for
cmake
and
for
google
tests
I'll
actually
explain
how
to
use
it.
So
one
does
not
need
the
command
line,
which
is
a
neat
thing,
because
I
have
seen
folks
who
would
prefer
using
just
the
id,
and
it's
all
part
of
the
tooling
that
I
have
vc
package
support
is
very
preliminary.
A
What
it
does
it
can
install
and
build
and
put
it
in
the
build
tree
like
it
works,
but
it's
not
done
the
best
way
because,
ideally
for
cmic,
we
need
to
export
the
variables
like
open.
Elementary
underscore
include
d
or
open
telemetry
underscore
libs.
Something
like
this.
A
So
I
can
add
that
separately,
because
I
think
it's
gonna
be
good
for
cmake
customers
to
have
find
package
open
telemetry,
which
defines
where
the
package
is
what
it
provides
and
then
they
can
compile
their
exporters
or
sample
ups
outside
of
our
source
tree
to
play
and
kind
of
try
things
out.
B
Let's
find
the
package
required
for
vc
package,
I
think
when
you
install
vc
packs
your
the
consumer
project
will
use
friend
underscore
package
to
like.
A
A
So
that
way,
if
you
have
complex
dependencies,
like
our
project,
does
like
on
google
test
or
benchmark
or
something
treat
this
package
similar
to
bazel,
where
you
can
actually
script
certain
things
being
fetched
and
installed
in
your
build
tree
and
then
cmake
itself
is
blissfully
unaware
of
that,
whether
there's
vc
package
or
not,
it
just
sees
the
cmak
packages.
A
So
it's
like
vc
package
is
more
like
a
helper
and
then
the
build
process
on
windows.
It
you
may
use
vc
package
for
simplicity
or
otherwise
you
don't
have
to
use
it.
If
you
have
your
own
means
of
figuring
out
how
to
install
cmake
packages,
which
is
a
bit
problematic
for
some
users
and
that's
why
people
prefer
vc
package
can
I
think
I
need
to
do
the
write-up
on
this.
B
I
see
and
for
vc
package.
Actually
I
have
a
one
question
like
I
saw.
There
are
many
various
projects
for
which
portrait
to
be
supported,
vista
package
to
make
the
build
work.
It
tries
to
apply
maybe
some
patch
yes,
and
how
can
we
see
that
patch
is
correct,
like
I
think,
there's
no
release
validation
for
this
factory
yeah.
A
Let
me
explain
so
there
is
a
known
bug,
feature
missing
feature
in
dc
package:
it
cannot
pin
easily
to
precise
package
version
and
which
is
a
bit
ridiculous,
because
I
I
have
seen
interesting
comments
on
that
issue.
People
having
a
lot
of
fun
about
it.
What
is
the
package
manager
that
cannot
pay
into
exact
package
version
right?
A
There
is
a
workaround
where
you
can
overlay
your
local
port
files
and
we
use
that
workaround
right
now
in
our
repo
you
can
pin
to
exact
patch
set,
you
can
pin
to
exact
commit,
but
it's
like
you
have
to
create
your
own
subtree
with
all
these
port
and
control
files
and
say
use
my
files
instead
of
the
mainstream
vc
package
and
the
the
main
idea
of
vc
package.
It
always
moves
on
to
latest
to
let
us
stable
with
somebody
who
is
maintaining
the
control
and
portfolio
considers
stable.
A
A
It's
like
we
have
to
contribute
that
control
input
file
to
the
vc
package
repo,
and
we
have
to
tell
like
right
now,
version
1.3
is
the
current
stable
and
these
are
all
the
patches
we
use
to
compile
it
on
windows,
linux
and
mac.
Well,
hopefully,
we
won't
need
patches,
everything's,
just
going
to
compile
from
our
source
tree
and
then
consumers.
A
A
It
already
gives
you
that
ability
to
specify
the
feature
set.
So
from
that
perspective,
I
think
it's
like
one
option
to
deploy
easy
option.
I'm
not
saying
that
this
is
the
only
option.
This
is
not
so
I
think
what
I
would
like
to
contribute
is
separate.
The
documents
blazer
bill,
okay,
cmake
and
vc
package,
plus
cmake
and
c
mac-
build
with
visual
studio
bui,
just
because
visual
studio
gui
now
has
that
beautiful
support
for
that.
A
F
I
mean
probably
I
was
I
was
not
present
in
the
last
meeting,
so
if
it
has
been
already
discussed,
I
mean
we
can
just
skip
it.
I
mean
I
just
wanted
to
understand.
I
mean
why
we
selected
the
vc
package.
I
know
we
need
to
probably
it's
good
to
have
one
source
package
manager,
so
I
mean
which
can
package
the.
F
F
A
Have
you
seen
any
other
community
member
coming
in
and
committing
apr.
F
No,
no,
I
mean
I
I
know,
I
know
this.
Somebody
come
commented
on
the
pr
and
then
then
how
it
all
started,
but
we
just
wanted
to
understand
whether
it
was
discussed.
Whether
vc
package
is
the
right
tool
or
we
should
use
the
other
conan
is
there.
I
mean
there
are
other
tools
also.
I
know
I
know
right.
A
So
this
is
like
day
zero
decision-
bazel,
okay,
cma,
right,
okay.
So
then,
if
I
use
c
mic,
I'm
not
really
happy
with
how
c
maker
runs
it's
a
steep
learning
curve.
That's
why
there's
simple
way
of
consuming
c
mic
packages,
which
is
vc
package,
which
microsoft
is
maintaining.
B
F
I
mean
I
understand
that
I
mean
there
are
other
other
package
managers
like
conan
is
there,
which
is
also
cross
platform
for
c
plus
plus.
It
supports
multiple
versions
of
the
same
package.
I
mean
I
just
wanted
to
understand.
It
has
same
number
of
repositories,
number
of
packages,
as
we
have
for
vc
package.
You
just.
A
F
It
so
we
are
community.
George
can
help.
D
With
bazel
yeah.
A
D
I
have
a
I
have
to
leave
in
five
minutes,
so
I
want
to
ask
one
question,
so
the
I
think
it's
fine
to
have
more
than
one
package
published
from
c
plus
plus,
given
I
don't
think
c
plus
plus,
has
a
canonical
package
manager.
It's
not
like
java,
where,
like
you,
hit
maven
and
you
hit
100
of
java
users,
somehow
right,
there's
not
that
in
c
plus
plus,
so
I
think
the
reality
is
we're
going
to
have
multiple
packages
being
distributed.
My
question
around
this
is:
is
this:
like?
D
D
Well,
there's
also
how
much
we
can
afford
to
support
as
a
community
and
given
that
you're
an
expert
in
cmake
and
I
I
will
bring
and
help
with
bazel
awesome
like
like
that's
good
as
long
as
we
have
the
support
in
the
community
to
support
the
packages.
There
is
a
question
you
know
like.
If
someone
were
to
come
in
and
say
I
wanna
bundle
a
debian
build
of
this
right.
D
What
do
we
do
there?
That's!
That's!
That's!
That's
what
I'm
throwing
out.
I
unfortunately
can't
listen
to
the
end
of
this
discussion.
I
gotta
drop
in.
I
have
a
thing
to
do
so.
I.
A
B
And
josh,
I
think
that's
one
more
question.
Maybe
we
need
your
help.
Let
me
could
you
take
a
quick
look
like
the
next
item
is
face
off
base
list
version
upgrade
yeah.
D
Yeah
yeah
like
okay.
I
am
happy
to
help
with
that
upgrade.
If
anyone
has
a
pr
that
already
does
it
I'll
review
it
awesome:
okay,
okay,
thanks
cool
and
and
I'll
I'll,
follow
up
on
the
community
tomorrow.
So
thanks
everyone!
Sorry!
I
have
to
fail.
H
Yeah,
so
why
I
was
I
had
like
put
in
the
agenda
for
the
update
was
yeah.
We
are
still
using
the
1.1
version
of
bazel
list,
whereas
the
latest
is
1.7
and
there
are
certain
upgrades
and
how
you
can
remove
certain.
So
in
our
ci
there
are
certain
files
that
we
are
not
including
because
they
are
just
some
os
specific.
H
Like
someone,
some
for
specific
to
windows
or
some
specific
2s,
there
are
certain
capabilities
added
in
the
latest
version
of
bezel
that
you
just
specify
in
the
build
file
which
you
create
for
each
direct
or
for
each
exporter
or
api
sdk.
H
You
can
just
specify
that
particular
thing
so
that
the
that
file,
or
that
particular
folders
or
files
which
you
have
mentioned,
will
build
only
for
those
os,
so
that
will
make
things
cleaner
and
even
the
ci
builds
where
we
have
so
we
are
using
hyphen
hyphen
to
remove
it
from
the
build
actually.
So
it
would
make
sense
to
use
that
so
things
will
get
more
cleaner
and
things
will
get
more
clarity.
That's
why
I
proposed
for
this.
H
So
I
was
not
actively
working
on
it
but
yeah.
If
there's
a
if,
if
no
one
like,
if
that's
anyone
I
am
like,
I
will
surely
be
sending
a
pr
if
I'm
assigned
yep.
B
Okay,
I
think
the
next
item
is
out
of
outstanding
prs.
We'll
go
through.
Go
show
that
you
know
the
past
vrs.
B
Quickly,
okay,
the
next
one
and
I
added
it.
I
saw
the
there's
comments
from
johannes
and
yeah.
Well,
I
will
address
the
comments.
The
exporter
yeah.
I
looked
at
it
a
little
bit
yeah
I
saw
like
export
function
also,
but
maybe
I
need
to
add
a
test
and
test
in
test
case
to
to
say
creator,
creator
create
spam,
processor
or
with
smart
pointer
and
call
export
on
it
to
see
it
should
trigger
access
violation.
So
yeah.
E
E
B
E
We
just
basically
use
this
explicit
dog
string
without
doing
any
testing,
but
I
think
the
tests
here
are
not
I'm
fine
with
adding
the
narcs
like
you
did
with
just
then.
If
we
do
it,
we
just
have
to
make
sure
that
we
add
it
in
order
necessary.
B
B
Okay,
thanks
our
take
more
look
at
your
comments
and
address
it:
yes,
okay,
the
next
one
yeah
from
israelite
and
then
we
I
think
we
discussed
it
in
in
the
meeting.
It
is
a
there's,
a
noun
thread
in
the
pr,
and
now
I
think,
waffan.
Are
it
right?
B
And
the
cure
based
implementation
of
http
client
api.
What's
the
status
of
this
one.
F
Yeah,
I
think
I
resolved
all
the
comments.
There
was
a
issue
with
the
code
coverage.
I
mean
because.
F
B
B
A
What
I
did
I
added
comments,
so
if
you
go
through
the
view
of
files
changed,
you
would
see
specifically
like
the
moments
I
wanted
to
highlight.
I
will
tag
my
own
comments
as
a
result,
but
it's
more
like
to
explain
what
I'm
doing
yeah
so
see.
I
can
added
the
reasons
certain
practical
reasons
why
exactly
the
change
is
made.
B
Okay
looks
good,
looks
good
and
I
I
will
take
some
time
to
review
here
and
over
here.
Please
take
time
to
review
yes,
according
to
max,
it
is
ready
for
merchant.
So.
A
Yes,
there
are
a
few
minor
things.
I'm
still
going
to
address
a
few
comments,
like
mostly
questions
like.
Why
is
this?
Why
is
that
or
where
is
it
documented
and
it'd
be
nice
to
create
a
matrix
of
what
we
support
like?
I
will
handle
it,
but
I'd
like
to
get
the
essential
feedback
at
rest
as
well,
so
take
a
look
guys.
B
A
Yes,
so
we
are
still
discussing
this
with
michelle.
There
are
a
few
changes
that
need
to
be
done.
How
it's
done
right
now,
it's
a
complete
implementation
of
sdk.
It
doesn't
actually
implement
the
exporter,
it
just
implements
the
tracer
okay,
so
we
wanted
to
it.
It
works.
It
just
doesn't
follow
the
the
best
practices.
A
Okay,
this
there's
still
a
question
a
little
bit
of
performance,
because
we
do
all
these
transforms
and
locking
in
environment
where
otherwise
we
don't
need
to
do
it.
As
I
say,
etw
already
provides
all
the
necessary
locking
and
api
surface.
It
is
designed
to
be
used
concurrently
by
multiple
processes.
A
So
there's
a
bit
of
an
overhead
of
opening
telemetry
exporter
model,
because
we
have
that
log.
We
have
that
voucher
and
all
this
which
is
unneeded
in
ecw
environment
but
anyways,
I
think
it'd
be
good
for
if
we
show
how
to
do
it
properly
through
the
exporter
model,
and
we
can
see
how
to
you
know
fix
this.
If
we
see
any
imperfections.
B
Okay,
okay,
I
think
we're
good
on
this
one
and
for
the
next
one
have
we
looked
at
it
in
the
last
meeting,
the
std
library,
for
example,
for.
A
This
one,
if
we,
if
we
merge
the
build
tools
first,
my
ask:
is:
we've
merged
the
build
tools?
First
and
then.
E
A
So
it's
just
gonna
be
much
easier
when
we
merge
the
build
tools,
this
is
gonna
be
much
smaller.
B
E
B
I
think
I
look
at
this.
We
are
mostly
good,
so
yeah,
johannes.
Please,
take
a
take
a
look
and
to
see
whether
the
latest
comments
addressed
your
feedback.