►
From YouTube: 2021-08-11 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).
C
C
A
Screaming
yeah,
so
let
me
ping,
I
think
josh
wanted
to
join
today.
Let
me
ping
him:
if
he's
not
he's
going
to
join
or
what's
the
status
because
he's
just
paying
me
some
time
back
that
he's
going
to
join
the
meeting
today,
the
meeting
link
was
correct.
Right,
I
mean.
B
D
D
A
A
A
Okay,
I
think
the
basically
we
can
start
with
the
agenda
for
which
you
join.
So
basically
we
had
a
release.
Rc4,
that's
that's
a
candidate
release.
I
mean
we
are
proposing
it
as
a
release
for
the
review
for
the
technical
committee.
So
I
think
this
is
a
release.
Probably
you
can
start
looking
into,
and
probably
this
is
something
which
has
to
be
reviewed
in
com
for
the
compliance
with
the
open,
telemetry
specs.
A
A
D
D
Well,
you've
done
a
lot
of
work
in
the
past
few
months
and
I'm
a
little
stale,
but
there's
a
lot
that
I
am
familiar
with
so
hopefully
you're
going
against
spec
1.0.
I
can
look
at
the
compliance
matrix
and
start
from
there
and
just
go
piece
by
piece
with
comments.
D
We
can
start
talking
about
like
how
do
you
want?
How
do
you
want
feedback?
How
do
you
want
to
do
the
process?
What
do
you
want
this
to
look
like?
Let
me
know.
A
I
mean
I
don't
have
anything
particular
in
my
mind.
I
mean
it's
probably
the
best
way.
You
think
you
really
want
to
start
looking
into
that
compliance
is
definitely
probably
a
good
good
place
to
start
with,
just
to
ensure
that
we
are
compliant
with
all
the
features
which
are
part
of
that
matrix
and
probably
we
are
meeting
all
the
api
requirement
as
per
the
specs,
so
just
to
give
a
bit
of
idea
when
the
last
time.
A
When
you
were
working
in
that,
I
mean
mostly,
the
api
part
has
not
changed
drastically.
It's
still
the
same.
We
do
have
added
more
features
in
terms
of
number
of
exporters
like
jagger
exporter.
That's
something
we
added
both
for
http
for
udp.
We
did
add
the
otlp
http
exporter.
We
did
add
something
called
a
semantic
convention
for
what
resources
and
places.
So
it's
more
of
an
add-on
on
the
new
feature.
A
A
The
problem
here
right
now
is
that
the
grpc
version
which
we
are
using
is
for
the
bazel,
build
somewhat
old,
and
even
the
bazel
version
which
we
are
using
for
build
is
also
be
told.
So
we
do
need
somebody
some
help
for
upgrades
on
those
areas,
and
I
think
we
have
been
asking
for
that
in
the
maintenance
meeting
for
quite
a
couple
of
months,
but
I
think
we're
not
getting
a
good.
I
mean
good
help
from
on
that
front,
so
that
that.
B
A
That's
a
good
point
because
we
are
releasing
a
source
package.
We
are
releasing
the
source
packages,
we
don't
really
so
when
we
say
the
launch,
we
don't
really
release
any
build
packages,
so
it
would
be
source
packages
with
cmake,
build
configurations
and
bazel
built
configuration
in
place.
D
Okay,
so
the
way
there's
two
things
here,
one
is,
I
feel,
a
little
guilty
because
I
should
be
helping
with
basil.
I
just
don't
have
I
got
I.
I
have
a
new
position,
so
I
I've
been
trying
to
get
ramped
up
in
the
past
few
months.
It's
been
fun
the
so
so
I
think
it's
totally
fine
for
your
1.0
to
not
include
bazel
it
I
mean
I
I
would
prefer
if
it
did,
because
I
think
there's
a
class
of
users
who
will
want
that.
D
But
that
said,
if
you're,
if
your
1.0
is
only
the
cmake,
build,
that's
fine,
but
we
just
need
that
to
be
clear,
like
the
the
the
key
here
is
what
you
know
making
sure
the
specification
version
you're
against
is
clearly
documented,
making
sure
the
supported
consumption
model
is
clearly
documented
and
then
making
sure
that
things
that
are
experimental
are
appropriately
annotated
as
experimental
or
require
some
sort
of
like
user
touch.
That's
that's
that's
what's
important
here.
D
So
if
you're
like,
we
can't
do
basil
just
yet
and
we
don't
have
enough
basal
support,
that's
fine!
I
feel
guilty
about
it,
but
that's
fine
we'll
see.
Maybe
I
can
do
some
fixes
there,
quick
and,
if
not
like,
we'll
we'll
see
how
it
goes
but
yeah
that
that
that's
let
me
let
me
add
this
to
notes
so
that
I
remember
these
things
so
dude
can
it
for
tc
wait.
Why
is
it
not?
Do
I
have
to
click
this
button?
D
Oh
weird!
Oh,
okay!
Okay,
it's
not
giving
me
bullet
points
here.
So
tc
review
notes,
specification,
1.0,
visit
dot.
D
Right
because
there's
components
that
don't
have
basal
builds,
so
I
should
not
use
bazel
to
try
this
out.
I
might
have
to
get
a
get
a
cmake
build
going
for
myself.
Then
what
else
did
we?
We?
There
were
three
things
we
just
discussed,
and
I
only
remember
these
two.
So
the
specifications
1.0.
D
Are
ready
for
you
about
well
yeah,
so
the
other
thing
is
that
just
so
you
know,
you
know,
metrics
metrics
api
is
is
feature
freeze,
but
not
ready
for
eval
either,
so
we
can't
evaluate
it.
All
we
need
to
do
is
make
sure
that
it's
marked
as
experimental.
Okay,
any
other
any
other
notes
here.
A
Not
really,
I
think
that's
that
should
be
good
enough
to
start
with,
I
mean
I'll
say
that,
probably
if
you
need
something
more
information
feel
free
to
ping
us
on
me
or
top
on
slack.
I
think
we
can
help
you
out
on
those
areas.
I
mean
if
you
feel
something.
If
something
is
not
very
clear.
Probably
you
just
fingers
on
slack.
I
think
that's
should
be
fine
and.
D
D
I
mean
they're
just
early
feedback
because,
because
we
just
talked
about
it,
this
is
this
is
an
example
of
the
kind
of
bug
I'll
open
or
I
can
make.
I
can
make
pull
requests
for
this
directly
too.
The
install
document
right
says
that
bazel
and
cmake
are
officially
supported.
D
All
we
have
to
do
here
is
a
cmake
is
officially
supported.
Bazel
is
experimental
and
may
or
may
not
work
for
some
modules
right,
yeah
yeah,
so
so
that
yeah,
if
you
want
that
feedback
in
slack,
if
you
want
me
to
just
open
a
pull
request,
I
don't
know
what
the
easiest
is
there,
but
that's
that's
probably
mostly.
A
D
Okay,
should
I
make
a
overall
tc
review
bug
and
then
I
can
like
link
the
bugs
that
we
open
inside
of
that
and
and
so
you
get
a
notion
of
my
progress
and
when
I'm
done,
because
I
can
close
that
bug
when
I
say
hey,
this
is
good
to
go.
You
know
what
I
mean.
D
No,
so
what
I'm
thinking
is,
I
will
open
a
bug
around
tc
review
for
1.0
when
I
close
that
bug
as
resolved.
That's
everything's
good.
C
Okay,
but
how
can
we
know
their
progress
like
50
or
reviewed.
D
What
my,
what
I
hope
to
do
in
that
bug
is,
I
can
do
either
put
the
feature
matrix
in
or
put
bullet
points
of
tasks
that
I'm
planning
to
do
so
that
you
can
see
the
progress
as
it
goes.
That's
what
maybe
alpha
yeah
and
we
can
attach
bugs
to
that
bug.
So
you
can
see
status
of
you
know,
follow-ups
and
that
sort
of
thing
yeah
yeah.
My
goal
here
is
to
not
have
this
take
forever
to
be
very
responsive
as
much
as
possible.
D
So
you're
gonna
have
my
dedicated
open
source
attention
right
now
and
then
to
make
sure
that
nothing
here
is
like
surprising,
you
know
like
it
should
be
yeah.
All
of
this
should
just
be
like
simple,
I
hope,
but
most
of
it
is
just
you
know,
last
minute,
polish.
So,
for
example,
the
bazel
thing
I
think
that's
going
to
be
relatively
simple-
to
go
fix
up
in
docs.
The
specification
1.0
is
your
target.
D
I
I
need
to
go
check
and
see
how
other
cigs
have
denoted
what
they're,
targeting
just
to
be
so
that
it's
clear,
but
we
just
have
to
make
sure
it's
called
out
somewhere.
If
it's
not
already
called
out
so
I'll,
just
look
for
that
in
your
docs
and
probably
suggest
a
location
where,
like
other
cigs,
have
put
it.
D
If
you
do
that
in
anticipation
of
me
looking
at
it,
that's
fine
too,
but
it's
mostly
that
kind
of
stuff,
just
you
know,
are
users
able
to
figure
out
what
in
open
telemetry
will
work
and
are
they
when
it
comes
to
the
specification,
it's
okay
to
deviate,
but
when
you
deviate,
is
it
like
a
c
plus
plusism,
or
is
it
something
that
we
should
try
to
correct
and
be
more
uniform
with
the
spec
and
to
to
that
extent,
I
think
I
know
a
lot
of
how
c
plus
plus
works
internally
already
for
the
trace
sdk.
D
A
B
A
D
A
D
B
A
B
D
D
Again,
these
are
all
things
that
I'll
do
as
part
of
the
the
due
diligence
check
out
the
feature
matrix.
You
know
that
sort
of
thing
open
bugs
appropriately
yeah
to
the
extent
the
other
thing
is,
if
something's,
really
small
I'll,
send
a
pr
as
long
as
that's
okay,
if
it's,
if
it's
tiny
and
easy
to
fix
in
the
in
in
the
moment,
if
it's
contentious,
then
then
that's
fine.
We
can
have
like
a
major
discussion
but
yeah
this
shouldn't
the
goal
is
this
shouldn't
be
onerous?
D
C
C
B
D
Yeah,
it
looks
like
you,
0.9
was
released
on
may
12th
yeah.
This
man,
0.10,
I
think,
is
where
logs
becomes
beta,
is
that
right,
yeah,
so
0.9
was
where
metrics
is
now
considered,
stable
and
0.10
is
where
logs
will
be
considered
beta
or
like
relatively
stable.
That
I
don't
know
when
that
one's
going
to
come
out
but
yeah
if
you're
on
zero,
nine
you're,
totally
totally
up
speed.
A
D
Cool
all
right,
so,
let's
see
any
any
other
things
that
I
should
know
before.
I
start
looking
into
anything
that
you
think
will
be.
That
would
be
easier
to
talk
about
now
versus
later.
A
D
Okay,
there's
one
there's
one
oddity
here:
what
are
going
to
be
the
po,
so
I
forgot
you're
you're,
doing
source
distributions
right
of
the
api
in
the
sdk,
the
plug-in
loading
mechanism
and
like
the
no
no
std
library
that
are
exposed.
D
What
is
what's
the
current
plan
there
that
that's
that
that's
part
of
the
public
api,
that's
part
of
what
you're
exposing
to
users,
so
that's
that's
actually
going
to
be
included
in
the
evaluation
of
like
it.
Are
we
exposing
too
much?
You
know
what
what
does
this
look
like?
What
kind?
I
guess,
what
I'm
asking
is?
What
are
the
compile
time
options
you're
exposing
to
users
that
we
need
to
evaluate.
A
Okay,
so
it's
it's
documented,
but
we
do
support
in
combined
compile
time
option.
We
do
support
the
customer
to
use
their
own
htl
library,
not
just
the
center
template,
so
we
have
our
own
internal
or
for
most
most
of
the
stl
features.
We
do
have
our
own
internal
implementation,
which
we
have
copied
from
somewhere,
but
we
do
provide
flexibility
for
customers
if
they
want
to
use
their
own
implementation,
not
their
own,
but
if
they
want
to
use
standard
library
for
something
or
upsell
or
jsl.
A
D
Where,
in
the
is
that
in
the
install
doc,
I
know
I
remember
when
that
was
getting
added,
I'm
just
curious,
where
it
where
we
actually
have
that.
A
Yeah,
I
think
it's
it's
not
something
which
can
be
searched
through
install
dock.
It's
it's
one
of
the
document
in
docs
directory.
Probably
if
you
want
it
to
be
tracked
to
install
you
can
do
that,
but
we
don't.
The
reason
why
we
don't
really
want
to
add
it
in
the
install
dock.
Is
that
that's
not
recommended
to
use
those
options
to
use
their
own
table
their
own
specifications,
because
that
breaks
the
api
compatibility.
A
So
we
really
don't
want
them
to
you.
Do
that,
so
it's
not
documented
in
the
install
documentation,
but
if
they
really
want
to
see
in
go
to
the
docs
directory
and
they
can
figure
out
how
to
really
use
use
those
cmake
options
to
build
using
other
standard
libraries,
but
that's
something
which
we
don't
want
to
recommend
it
because
of
avi
compatibility.
D
Yeah,
you
know
that
that's
totally
fine,
so
then
we
won't
look
at
that
right
like
again
the
so.
The
only
thing
I
might
ask
is,
if
you
have
it
documented
somewhere,
just
to
make
sure
that
that
document
denotes
like
an
experimental
feature
like
one
of
the.
The
key
thing
here
is
before
you
go
1.0
just
to
make
sure
everything
that
people
can
rely
on.
That's
stable,
that
won't
change
is
very
clearly
or
or
is
implicit
right
and
everything
you
can't
rely
on.
That
could
break
that.
D
That
can
change
is
just
clearly
labeled
as
experimental,
so
anything
that's
not
fully
supported
should
be
clearly
labeled
experimental.
Everything
else
is
basically
going
to
be
implicitly
something
that
we
expect
people
to
depend
on
and
use
and
all
that
kind
of
joke.
So
that
that's
great,
like
I
remember
when
all
that
was
getting
added,
I
didn't
follow
the
doc
status
and
I
think
it's
good
you
have
it.
I
also
think,
as
long
as
it's
clearly
outlined
as
experimental,
no
problem
good,
okay.
D
So
I'll
only
review
the
standard,
build
process
and,
and
then
the
install
document
and
and
from
that
view
and
all
those
other
docs.
As
long
as
they're
clearly
marked
you
know,
experiments
or
whatever
totally
fine
cool.
A
Yeah-
and
there
is
another
feature
which
we
do
have
it
it's
implemented,
but
I
think
we
don't
really
want
it's
not
yet
documented
and
we
don't
really
want
customers
to
use
it.
That's
basically
time
loading
of
the
sdk
library,
it's
kind
of
dynamic
loading
of
the
sdk
library,
so
that,
because
we
don't
have
right
now
fully
implemented
how
to
really
set
the
configuration
that
the
runtime,
because
most
of
the
configuration
had
to
be
set
as
part
of
build
time.
So
that's
that's
something.
Probably
it's
not
yet
fully
usable.
D
I
see,
let's
see,
okay,
that's
also
good
to
know
those
the
runtime
loading
apis.
Are
they
also
clearly
marked
as
kind
of
experimental
in
the
in
the
header
files,
or
are
they
exposed
kind
of
publicly?
But
we
just
don't
document.
A
We
do
plan
to
make
it
usable
over
the
course
of
time,
as
we
are
going
to
provide
the
support
for
setting
the
configuration
to
environment
variables,
we
don't
really
support
as
of
now
specifically
setting
so
once
once
that
subport
is
there.
I
think
this
could
be
fully
usable,
but
yes,.
A
Provide
support
for
that
for
most
of
the
exporters,
it's
something
which
is
not
usable.
D
Yeah
yeah,
so
I
think
I
think
in
that
case
the
the
ask
is
gonna,
be
to
have
it
clearly
marked
experimental
in
the
header
file,
so
I'll
probably
open
a
bunch
of
of
bugs
around
this
for
those
kinds
of
features,
but
anything
that's
a
header
file
that
is
in
the
includes
directory
that
is
publicly
visible
to
somebody
consuming
this
library
and
isn't
like
doesn't
have
an
internal,
only
tag
or
some
sort
of
documentation
saying
that
it's
not
public
we're
gonna
treat
as
part
of
the
public
api
and
so
to
the
extent
that
that
header
file
says
this
is
an
experimental
thing.
D
Great
some
some
sigs
have
got
like
java,
for
example,
they
actually
have
separate
packages
for
experimental
things
completely
separate,
so
you
could
even
have
a
separate
name
space.
I
think
that's
going
possible
like
I.
I
don't
think
you
have
to
go
that
far
here.
As
long
as
the
header
file
is
marked
experimental,
but
it's
just
as
long
as
users
have
a
very
clear
expectation
of
which
pieces
of
the
api
will
be
compatible
and
are
okay
to
take
a
dependency
on
and
if
they
pull
in
one
of
those
things.
D
It's
very
clear
to
them
that
it's
not
stable
right
yeah,
that's
that's
the
key
so,
unfortunately
like
we
need
to
go
down
to
the
the
header
level
here,
because
if
they
have
access
to
that
header
and
they
can
depend
on
it,
it
doesn't
matter
what
we
say
or
what
we've
documented
their
expectation
might
be.
Well,
it
was
there
use
it,
so
we
have
to
very
clearly
put
it
on
those
header
files.
D
I
don't
know
how
many
of
them
are
marked
that
way
yet,
but
we'll
that's
that'll
be
that'll,
be
one
thing:
I'm
looking
at.
A
D
So
it
will
there's,
there
will
be
sdk
headers
that
users
have
access
to
right.
So
there's
public
headers
that
people
need
in
the
sdk
to
do
configuration
and
so
I'll
also
be
looking
at
the
sdk
and
to
the
extent
we
can
hide
the
headers
that
users
don't
need
to
see
in
some
fashion.
Let's,
let's
do
that.
You
know
like.
D
I
know
that
at
one
point
in
time
there
were
there
was
there
were
some
headers
for
like
internal
classes
that
didn't
live
in
the
headers
directory,
but
there's
like
beer
build
oddities
there
as
long
as
it's
clear
to
users.
What
apis
in
the
sdk
are
stable
and
exposed
to
them
and
which
ones
are
internal
only
and
they
shouldn't
be
touching.
D
A
D
D
D
That
also
are
not
meant
to
be
used
by
users,
and
so,
as
long
as
it's
very
clear,
that's
an
internal
header
file
that
people
should
not.
You
know,
leverage
their
understanding
of
it.
You
know
yeah
and
then
any
header
file
you
have
that
exposes
methods
like
helper
methods
will
probably
get
a
comment.
D
That
was
the
the
one
big
thing
in
java
as
well
or
in
you
know
the
the
javascript
review
helper
methods
that
are
publicly
exposed
right,
we'll
take
a
look
at
those
and
we'll
we'll
comment
on
those
and
try
to
get
those
somewhere.
That
is
clear
that
it
shouldn't
be
something
you
do.
You
know.
Users
depend
on.
B
C
So
even
we
put
the
helper
methods
under
our
namespace,
like
declared
for
open.
D
Yeah
yeah,
if
it's
hidden
behind
a
namespace,
that's
fine,
it's
the
the
key
here
is
that
users,
you
know
the
underlying
question
is:
do
users
understand
what
they
can
depend
on
or
not
what
will
remain
stable
and
what
won't
remain
stable
and
there's
components
of
the
sdk
they
will
have
to
depend
on,
and
so
we
just
want
to
make
it
very
clear
like
what
components
we
want
them
to
depend
on
and
which
ones
we
don't
want
them
to
depend
on
and
that
second
bit's,
the
the
most
important
bit
here
of
making
sure
users
don't
take
a
dependency
on
some
internal
detail
that
you
need
to
change
to
fix,
bugs.
A
I
see
yeah,
but
I
mean
yeah,
that's
a
good
point,
but
as
long
as
we
are
not
documenting
them,
I
think
because
there
will
be
lots
of
place
lots
of
these
kind
of
header
helper
methods,
which
could
be
there
in
the
internal
sdk
headers
for
sure
which
yeah,
which
I
think
definitely
should
not
be
usable
outside
the
api.
D
What
in
every
other,
sig
we've
required
explicit
documentation
that
this
is
internal
and
you
shouldn't
depend
on
it.
Okay,
so
like
the
only
documentation
you
need
is
that
this
is
internal
and
you
shouldn't
use
it.
So
it's
not
just
that.
It's
not
documented.
It
needs
to
explicitly
tell
the
user.
Okay
don't
depend
on
this
yeah.
C
D
We
have
to
provide
it
exactly
yeah
and
if
you,
if
there's
some
reason,
you
can't
put
it
in
an
internal
namespace,
you
can
also
just
document.
This
is
for
internal
use.
You
shouldn't
call
this
like.
That's
that's
fine
too
again
it's
as
long
as
it's
very
clear,
very,
very
clear.
If
a
user
depends
on
an
implementation
detail
that
they
know
they're
depending
on
the
implementation
detail,
yeah,
that's
right.
A
A
D
Like
I
said,
there's
there's
a
crop
ton
in
the
java
in
the
java
world.
There's
I'm
pretty
sure
javascript
may
have
done
a
packaging
fiasco
thing
where
they
actually
basically
use
a
namespace
called
internal
that
they
move
things
into.
So
it's
actually
completely
namespace
separate
and
I
python
might
have
this
I'll
have
to
take
a
look
as
well.
D
A
lot
of
a
lot
of
sigs
went
with
trying
to
to
package
separately
for
most
of
this,
but
I
you
know
that's
impractical
for
for
every
everyone,
so
anyway,
I'll
I'll
try
to
get
some
examples.
A
Yeah
I
mean
I
can
tell
you
an
example
here
in
our
case,
like
global
error
handler:
that's
that's
a
complete
all
header
implementation
and
that's
something
which
is
used
it's
supposed
to
be
used
internally,
only
only
for
the
ex,
and
that
still
should
be.
For
that.
That's
that's!
That's
not
the
right
example
that
still
should
be
usable
because
because
customers
can
use
their
customer
handlers
and
they
have
to
use
this
global
error
for
that,
so
not
what
that
should
still
should
be
visible
outside
sorry
yeah.
A
Now
let
me
go
through
some
to
the
code
and
try
to
figure
out
what
all.
What
all
are
those
internal
helpers
and
probably
actually
yeah.
D
That's
still
a
good
example,
though,
like
that's
that's
an
example
where
you
might
have
pieces
of
global
error
handler
that
you
don't
want
customers
to
touch
yes
and
then
there's
pieces.
You
want
them
to
touch
and
it
has
to
be
public
and
header
only
and
so
make
just
making
sure
those
pieces
are
very
clear.
D
A
That
is
there
yeah.
That's
that's
what
I
was
thinking.
I
mean
when
I
was
talking
about
this,
so
there
are
some
pieces
which
they
have
to
which
they
have
to
override
in
terms
of
customer
in
custom
implementation.
But
there
are
some
pieces
they
should
not
use
it.
So
that's
probably
we
need
to
really
document
that
here.
D
All
right
so
with
the
when's,
the
next,
the
next
cig
is
next
week
right,
but
so
in
terms
of
getting
back
to
you,
my
hope
is
to
get
a
first
pass
at
this
with
a
bunch
of
comments
and
things,
at
least
by
the
next
sig
that
we
can
talk
through.
If
we
need
to
talk
through
any,
I
hope
again,
hopefully,
nothing's
contentious,
that's
basically
the
types
of
comments
I
plan
to
make
that
I
think
from
what
I've
seen
from
other
review
processes.
D
That's
that's
probably
what
you
should
expect
I'll
come
to
the
next
sig
with
a
bunch
of
things.
I
think
I
need
to
check
and
make
sure
I
don't
have
a
conflict,
because
you
you
flip-flop
times
right,
yeah,.
C
D
Yeah
yeah
cause
that
one
I
I
I
actually
can't
do
mondays
at
6
p.m.
Most
of
the
time
my
I
have
to
take
my
daughter
to
a
writing
lesson
thing.
So,
okay,
I
I
like
I
said
as
of
the
fall
like
once
we
hit
august,
I
just
had
no,
it
wasn't
august.
It
was
like
anyway
in
the
summer
and
going
forward
through
the
fall.
I
have
a
permanent
conflict
on
mondays,
so
I
can
never
make
that
time.
D
This
is
the
only
time
that
I
have
a
chance
of
making
so,
but
we,
if
we
can
find
another
time
to
me
or
we
can
just
do
it
in
slack-
that's
fine
too.
I
will
try
to
make
sure
that
I
have
something
done
by
monday,
so
you
can
discuss
it
in
the
sig
if
you'd
like
and
if,
if,
if
we
need
to
discuss
in
person,
we
can
find
a
one-off
time.
Does.
C
D
Yeah
that
sounds
good
and
but
we'll
try
I'll
try
to
have
everything
reviewed
by
two
weeks
yeah.
I
think
I
can
do
that,
but
yeah
we'll
see
how
slow
I
am
by
next
week.
Thank
you.
A
And
most
probably
the
next
25th
I
mean
25th
august
meeting
I
may
be
taking
from
redmond.
Hopefully,
if
all
goes
well,
I
mean
I'll
be
moving
to
redmond,
so
I
think
hopefully
we
can.
We
can
work
on
the
timings
also
in
that
case,
going
forward.
Wow.
Are
you
going
to
ride
them
under
this
weekend?
A
A
Okay,
yeah,
I
think
you
have
something
more,
I
mean
josh,
which
you
want
to
really
discuss.
Now
I
mean
I'm
holding
on
or
you're
good
to
start
at
least
now.
D
So
what
what
are
your
basal
issues?
So
I
can,
I
can
ask,
I
think,
yeah.
This
is
a
different
topic,
different
topic
not
related
to
tc
review.
But
what
are
the
basal
issues
right
now?
Yeah.
C
At
least
for
for
some
new
components
like
I
think
for
checker-
I
add-
I
I
didn't
add
vasel
support
because
it
has.
It
needs
two
handlings,
some
dependency
like
install
thrift,
so
I
ignored
that
and
I
saw
a
few
other
places.
We
also
miss
it
at
another.
A
Yeah,
I
think
most
of
the
places
is
already
there.
Probably
jagger
is
something
we
will
be
missing
and
more
important,
which
I
feel
is
that
we
still
are
not
a
built.
We
still
are
not
able
to
upgrade
the
grpc
version.
We
are
using
very
old
grpc
version
for
bezel
builds
yeah.
That's
the
reason
is
why?
Because
because
we
support
gcc
4.8
for
instrumentation
and
the
grpc
latest
version
does
not
support
4.8
for
compiler,
so
that
that
somehow
we
have
to
split
our
ci
built
such
a
way
that
instrument
tension
for
four
dot.
A
We
we
do
have
in
ci
bills.
We
do.
We
do
use
gcc
4.8
compiler,
but
that
should
not
be
using
for
grp
that
should
not
be
using.
That
should
not
do
a
otlp
build
if
we
are
doing
the
that's,
how
that's
how
we
have
done
the
changes
for
cmake
that
if
we
or
we
basically
check
for
the
gcc
compiler
and
we
use
okay,
sorry,
I
think
what
we
do
in
cmake.
Is
we
check
for
the
gcc
compiler
if
it
is
4.8
or
4.9,
we'll
use
the
old
version
of
grpc?
A
D
But
basil
hates
that
or
at
least
so
basil,
because
that
you
have
to
upgrade
bazel
itself
and
beijing.
A
Itself
doesn't
work,
okay,
yeah
and
that's
the
reason
why
we
are
not
able
to
upgrade
the
gazelle
also
because
we
are
on
the
old
version
of
grpc,
and
I
think
if
we
upgrade
basel,
the
older
version
of
grpc
is
not
again
built.
There
is
some
some
complicated,
I
think
version
dependencies
across
here
and
some
somehow
that's
that
we
needed
more
expertise
for
bazel.
In
that
case,.
D
So
yeah
that
so
that's
something
I
can
look
at
independently
again
it'll,
be
like
I'm
gonna
do
that
after
the
tc
review
yeah.
So
there.
A
Is
a
bug
there
is
a
bug
bug
for
that.
I
think
you
see
here.
If
you
can
see
my
screen,
I
mean
there
is
yeah
error
when
build
with
bazel,
it's
basically
in
our
1.2
milestone,
but
I
think
we
won't
be
able
to
meet
it.
So
this
this
is
a
bucket.
We
cannot
use
bazel
port
auto
and
there
have
been
some
discussions
happening
here.
Probably
you
can
just
go
through
this.
D
Okay,
I
think
I
did
look
at
this
in
the
first
cc
and
I
didn't
have
a
chance
to
dive
into
it
yeah,
because
I
was
in
april
right.
That
was
around
the
time
my
life
went
crazy.
So
I
did
look
into
this
a
little
bit
and
my
question
here
is:
would
it
make
sense
to
have
bazel
not
support
gcc
4.8.
D
Right
so
so,
basically,
if
you,
if
you
choose
cmake
here,
are
the
compilers
you
get?
If
you
choose
bazel
here
are
the
compiles.
You
get.
B
D
So
so
the
idea
here
would
be.
We
keep
the
c
make
build
that
supports.
4.8
bazel
would
upgrade
past
4.8,
but
bazel
would
only
have
instrumentation
that
is
past
4.8
right
effectively,
and
so
the
ci
for
bazel
would
be
different
than
the
ci
for
cmake
yeah.
That's
what
I'm
suggesting
does
that
make
sense
to
do.
A
So
you're
saying
we'll
remove
the
legacy
ci
build
for
bazel
and
we'll
use
the
newer
version
of
gcc
compiler,
and
then
we
should
be
good
to
upgrade
jpc.
Also.
D
A
Okay,
yeah,
that
should
be
okay.
I
think
I
mean
that
should
be
okay.
At
least
we
are
saying
that
for
for
for
bazel,
we
don't
support
4.8,
I
mean
our
bezel
build,
we
don't
support,
photo
tape,
but
for
cmake
you
can
still
use
it.
Yes,.
D
D
It
was
either
on
installer
on
your
readme
of
like
what
what
versions
of
cmake
are
supported,
right,
yeah
so
effectively.
We
could
just
have
a
change
there.
That
would
say
like
these
are.
This
is
what's
supported
on
cmake,
this
is
what's
supported
on
bazel.
D
Yeah,
but
my
suspicion
is
if
people
are
using
bazel
and
bazel
doesn't
support
gcc
4.8,
then
they
don't
care
about
4.8
because
they
can't
use
it
anyway,
right
yeah
for
the
version
of
bazel
that
we
support,
but
the
the
real
I
I'll
do
I'll.
Do
a
quick
dive
through
open
source
bazel
and
see
how
many
people
are
up
to
date
in
bazel,
pass
that
4.8
version,
because
it
could
be
that
maybe
that's
a
limiting
factor
on
bazel
adoption.
So
we'll
take
a
look
at
that
before
we
upgrade
bazel.
C
Yeah,
I
think
google
is
is
a
big
customer
bazel.
Do
you
have
some
dependency
on
4.8
or
other?
Yes,
so
yeah.
D
We
yeah
internally
right.
We,
we
use
basil-ish
thing
where
basil's
the
open
source
equivalent
of
it,
and
so
when
we
consume
this
internally,
we
actually
do
a
little
bit
of
adaptation,
but
it
I
wouldn't
we're
so
weird.
I
wouldn't
worry
about
us
specifically,
but
our
open
source
projects,
our
c
plus
plus
open
source
projects,
are
kind
of
what
matters.
D
So
if
grpc
dropped
4.8
support,
then
the
next
question
is:
did
all
of
the
grpc
based
projects
that
depend
on
grpc,
also
drop
498
support,
or
are
they
just
using
old
versions
of
grpc?
That's
what
I
want
to
look
at
and
see
see
where
that
version
skew
is
because
we
want
to
you
know
we
want
to
pick
a
version.
That's
going
to
hit
most
of
that
community
if
we
release
that,
and
so
looking
at
adoption
is
what
matters.
So
it's
more
about
the
our
open
source
projects
than
internally
internally.
D
We
we
kind
of
hard
code
to
the
version
of
gcc.
That's
the
most
supported
right
now
internally.
So,
even
if,
even
if,
like
the
open
source
project,
supports
4.8,
we'll
update
the
build
tool
to
the
one
that
we're
using.
D
A
A
I
mean
I'm
not
sure.
If
it
is
it's
not
part
of
ubuntu
18
18
over
20..
Probably
we
need
to
see
I
mean
in
red,
I
mean,
what's
less,
I
mean
as
a
default
compiler
I
mean.
What's
I
mean?
How
is
it
still
supported
or
not
probably
we
may
have
to
see
the
matrix
there.
Also
I
mean,
if
is
any
any
suse
linux
or
red
hat,
are
they
still
supported
with
gcd
4.8
or
not?
If
there
is
no
support
from
those
package
vendors,
probably
we
can
have
a
decision
to
really
drop
4.8.
D
Yeah
that
that's
a
great
question,
that's
a
survey
that
I
think
we
just
kind
of
run
through.
C
D
A
Yeah
I'll
look
into
that,
I
think
that
would
be
a
good
good
place
to
get.
I
mean
that
how
how
many
I
mean
how
many
destroyers
are
still
supporting
it,
so
probably
that
we
can
make
a
decision
based
on
that.
Probably
we
can
do
that
in
c
make
also
if
there
is
not
much
of
the
support
I
mean
that
will
simplify
our
scenic
builds.
Also,
in
that
case,.