►
From YouTube: 2023-03-15 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
C
I
guess
from
an
agenda
perspective,
I
don't
have
much
more
than
what
I've
got
in
there
from
yesterday
for
everyone
who
didn't
attend,
really
that
the
I'm
gonna
I'm,
considering
the
sandbox
available
I
haven't
yet
created
the
branch
for
minification,
but
if
you've
got
anything
you'd
like
to
play
with
and
want
a
branch
created,
we
can
now
look
at
that.
I
think
there's
enough
there.
C
C
There's
a
lot
of
minification
I've
been
doing
with
app
insights,
so
I
have
my
own
set
of
libraries
I'd
like
to
use
which
I'm
sure
is
going
to
like
cause
grief
if
I
try
and
bring
them
in.
So
no
I
really
I
want
to
apply
as
many
techniques
as
I
can
to
see
how
small
I
can
get
it,
which
is
the
whole
point
of
why
this
sandbox
creates
bundles
for
everything,
so
that
I
can
effectively
build
Main
and
then
go
build.
C
My
minification
and
I've
got
something
to
directly
compare
it
against,
but
no
there's
there's
a
huge
amount
of
space
to
try
and
get
minification
going,
but
yeah
I
I
was
just
going
to
start.
Applying
techniques,
like
probably
one
of
the
biggest
easiest
ones,
would
be
the
resources
all
those
strings
are
uncompressible
at
the
moment
you
can
make
them
a
little
bit
better
compatible,
but
look
really
nasty
so.
C
And
then
there's
all
the
Prototype
definitions,
which
is
when
I
did
the
diagnostic
log
I
constructed
it.
So
it
didn't
use
standard
classes
that
actually
created
the
functions
as
properties.
To
avoid
the
when
you
compile
for
es5,
it
says
a
class
name,
dot
prototype,
which
is
all
uncompressible
so
fixing
that
is
not
going
to
be
easy.
C
I
know:
last
week
we
talked
about
potentially
creating
an
another
one,
a
branch
that
is
to
be
able
to
effectively
just
try
and
create
a
cut
down
minimal
web
SDK
now
which
I'm
going
to
talk
about
in
the
jsig
today,
where,
instead
of
trying
to
reuse
as
much
code
as
possible,
we'll
reuse
the
API
and
keep
the
interface
layers
the
same
but
effectively
just
see
how
small
we
can
go
and
create
one
I
know.
Santosh
was
interested
in
doing
that.
I'm.
C
Yeah
so
that
way,
yeah
we'll
have
all
the
history
of
the
branch,
but
we
can
just
go
off
and
say:
okay,
we're
just
gonna,
make
something
it.
Oh
I
do
the
same
box.
It
doesn't
have
to
be
compatible
because
we're
not
publishing
it.
So
we
can
go
and
hack
at
it
and
then
in
theory,
as
long
as
we
could
perform
to
the
API
interface
layers,
the
functions
which
would
work.
C
C
So
that's
where
the
sandbox
was
born
from
is
to
try
and
actually
get
the
evidence
to
say
it's
not
going
to
work
I.E
my
medification
stuff
yeah,
but
my
gut
feel
is
it's
not
going
to
work?
I,
don't
think
I
can
make
it
small
enough,
based
on
its
current
sizes
and
there's
some
fundamental
things
that
need
to
be
addressed,
which
I
don't
know
how
to
address
it.
In
the
current
code
base
either
I.E
I
have
multiple
teams
that
load
the
multiple
versions
of
the
SDK
all
running
on
a
page.
C
At
the
same
point
in
time
the
basic
open,
Telemetry
Global
API,
get
me
get
me
this
one
for
this
version
and
if
it's
not
there,
it
gives
you
a
knob,
that's
not
going
to
work
so.
A
A
If
you
need
the
Tuesday
and
Wednesday
meeting
and
I'm
wondering
if
I
was
going
to
propose
that
we
just
go
to
one
meeting,
but
now
that
I'm
that
I
hear,
although
all
this
we're
gonna
do
all
this
work,
I
wonder
like
if
we
should
use
the
Tuesday
meeting
or
more
like
a
project
collaboration
on
or
on
some
of
these
things.
D
A
Yeah
I
I
still
think
that
it's
like
we
should
have
one
one
meeting,
that's
more
kind
of
General
client-side
where
people
can
bring
up
any
kind
of
topic.
But
then
we
have
separate
time
to
work
on
specific
things.
So
yep.
C
Yeah
I
have
an
open
PR
to
merge
the
sandbox
into
the
staging
Branch.
As
of
yesterday,
there
was
an
up
it
looked
like.
There
was
an
update
to
the
JS
one.
So
I
wanted
to
get
Daniel's
input
before
I.
Push
that
in
the
the
staging
Branch
doesn't
do
any
compilation
so
effectively.
We
could
just
keep
bringing
it
in,
like
I
can
push
that
PR
in
and
then
we
could
try
and
merge
that
into
main,
which
is
where
all
the
CI
happens.
C
If
it
breaks,
we
just
merged
the
staging
one
again
because
it
just
brings
in
the
current
code,
but
yeah
they're,
all
ad
hoc
mergers.
They
don't
happen
automatically
at
this
point.
It's
not
a
case
of
you
merge
the
staging
one
and
then
you
have
to
merge
into
Main.
C
You
can
merge
the
staging
as
many
times
as
you
like,
and
not
take
it
to
mean
as
I
mentioned
yesterday,
though,
the
whole
point
of
Maine
is
purely
there
to
keep
in
sync
with
JS
and
quantrib.
C
We
shouldn't
be
actually
changing
the
code
directly
in
Maine.
We
can
change
the
we
did
identify,
so
we
need
to
update
the
readme's,
but
all
code
changes
should
be
in
branches
and
then,
if
you've
got
changes,
you
want
to
end
up
being
back.
In
main,
you
have
to
submit
those
out
into
contribut.js,
so
they
propagate
background
through
the
merging
process,
which
is
a
little
bit
painful.
When
there
is
compilation
bugs
introduced
in
Json
contract,
which.
B
C
C
But
yeah
we
can
write
the
branches,
so
the
first
Branch
I
was
going
to
pay
is
minification,
but
thank
you.
Daniel
Martin
and
myself
were
all
maintainers
of
this
repo,
so
we
can
create
branches
that
will
what
we
should
be
able
to
create
branches
at
will.
C
My
idea
would
be
to
effectively
allocate
maintainers
to
branches
I'm,
not
quite
sure
how
we'd
go
about
doing
that.
At
this
point
it
may
be
just
a
case
that
we
just
end
up
with
a
bunch
of
maintainers,
and
you
just
only
play
with
your
branch
I
at
this
point.
I
think
we
have
to
go
through
a
process
to
get
additional
security
settings,
so
we
can
update
settings
and
change
Branch
definitions.
A
So
for
video,
we're
doing
a
look
at
the
sandbox
and
just
see
like
if
that
workflow
makes
sense,
and
if
you
need
some
clarification,
maybe
next
Tuesday
we
could.
Maybe
we
could
look
at
how
you
know
what
the
workflow
would
be.
C
Yeah
they
should
be
able
to
pull
it
down.
In
fact,
you
just
clone
main,
do
an
npm,
install
npm,
run,
compile
npm
run
test
and
that
should
generate
everything
and
test
everything.
So
that's
affect
you
what
the
CI
is
doing
great
yeah
and
it's
part
of
the
compile
it
generates,
bundles
for
everything
in
every
possible
format,
for
es5
and
well
next,
but
it's
effective
es5
and
6.
D
I
think
I
should
be
able
to
now
the
last
like
month
or
two
has
been
really
busy
at
work
with
other
stuff,
but
now
I
have
like
much
more
dedicated
space,
so
I've
I've
set
aside
this
time
and
the
Tuesday
time
so
I
can
come
regularly.
A
Okay,
so
we
have
we
want
to
work
on
the
minification.
We
want
to
work
on
this,
the
smaller
web
web
SDK,
and
also
we
talked
yesterday
about
having
a
branch
for
just
the
the
new
new
new
experimental
instrumentations
based
on
events.
C
Yep,
that
would
mean
we'd
need
to
bring
in
the
logging
API,
which
isn't
there
at
the
moment,
so,
okay,
okay,
but
that
that
should
be
straightforward,
effective.
If
you
look
back
at
the
history
of
config.ts
in
the
sandbox
tools,
you'll
see,
there's
just
a
table.
We
should
just
be
able
to
update
that
and
as
long
as
the
code
in
those
can
be
compiled
and
run
or
tested
in
node
a
browser
and
a
web
worker,
you
should
just
automatically
work.
C
Is
there
any
other
packages
you
want
to
drag
in?
As
part
of
that,
you
want
me
to
bring
I
think
the
log.
A
C
E
E
A
E
E
A
C
C
B
C
C
Oh
sorry,
dash
dash
space
Dash
test
switch
just
to
make
sure
everything
works
before
I
push
a
PR
out
for
that.
B
C
C
C
B
B
E
C
Yeah,
it's
it's
been
a
long
time
coming,
but
hopefully
it'll
be
immensely
helpful.
C
Probably
any
other
complication
that
is
going
to
happen
is
once
packages
move
around
in
Json
country.
The
config.ts
needs
to
be
updated
to
move
that
as
well.
The
auto
merge
Branch
will
automatically
get
it
because
it
just
effectively
clones
everything.
It
makes
that
the
same,
but
the
script
to
convert
that
into
Mains
format.
You
say:
go
grab
it
from
this
folder
and
move
it
to
this
folder.
So
if
the
source
fold
has
changed,
then
that's
going
to
change,
so
we
haven't
yet
had
to
do
that.
C
So
hopefully
it
doesn't
require
a
a
manual
git
move,
because
it's
the
scriptures,
git
merge.
It.