►
From YouTube: 2021-10-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
A
All
right
moving
through
the
agenda
specification,
looks
like
no
important
updates.
Metrics
we're
working
on
getting
the
metrics
sdk
spec
to
feature
freeze
before
the
end
of
october.
Java
has
almost
reached
feature
complete
need
to
add
one
feature
to
allow
the
selection
of
aggregation
temporality
for
the
otlp
exporter.
Dot
net
has
reached
beta
python
is
making
progress
on
the
sdk,
but
no
blocker
from
the
spec
quick
question
for
for
riley,
or
whoever
wants
to
speak
about
this.
A
When
we
say
java
is
almost
feature
complete,
we're
talking
about
the
sdk,
not
just
the
api,
spec
correct,
correct,
great
cool,
so
quick
question
right
once
we
hit
feature
freeze
on
the
sdk
spec.
What
else
is
there
to
do
beyond?
You
know
vetted
out,
make
sure
it
works
like
well.
At
that
point,
we'll
have
an
api
spec,
that's
feature.
Freeze,
we'll
have
an
sdk
spec,
that's
feature
frozen.
B
So
the
api
spec
is
already
feature
freeze
for
about
a
month
and
a
half
the
sdk
has
a
few
remaining
prs
was
immersed.
We
should
be
able
to
declare
feature
freeze,
and
I
expect
that
to
happen
before
end
of
this
month
and
after
visual
freeze.
The
language
maintainers
should
expect
there's
a
clear
feature
matrix
in
the
spec
and
that
matrix
is
not
going
to
have
new
entries.
B
So
what
they
can
do
is
just
to
do
the
checkbox
once
they
like
hit
all
the
all
the
years
items
for
the
metrics,
then
they're
done,
and
if
we
have
three
languages
that
have
confidence
to
reach
the
the
future
completeness
and
also
be
able
to
shift
the
beta
version.
Then
we
have
good
confidence
to
move
the
spec
to
stable
state.
A
Okay,
and
is
there
any
collector,
work
that
we've
attached
this
as
well
or
are
you
not
tracking
that.
B
There
there
is,
but
it's
captured
by
the
matrix
data
model
and
protocol
instead
of
the
api
and-
and
I
I
think
that
part
most
of
the
specs
of
work
are
already
stable.
It's
just.
There
are
some
protocol
implementation
details
that
we
we
need
to
sort
out,
so
it
takes
time
probably
like
a
month
or
a
little
bit
more
than
that,
but
it's
not
going
to
block
the
spec
itself
great.
A
A
A
E
Oh
yeah,
we
just
have
the
yeah
yeah
yeah
go
ahead:
oh
yeah!
We
we
just
have
a
logs
sdk
prototype.
There's
some
some
users
asking
to
try
it
out,
and
so
we're
probably
gonna
be
releasing
like
a
prototype.
Alpha
version
sometime
this
week,
so
cool.
A
Awesome
all
dotnet
shipped
to
beta
last
week,
working
on
otlp
log
exporter
and
we'll
continue
metrics
work
and
make
further
improvements.
A
Go
we're
planning,
1.0.2,
release
of
bug,
fixes
this
week
addressed
addressing
identified,
minor
issues
and
issuing
fixes
progressing
with
metrics
work
c,
plus
1.1.0
beta
1
for
traces
of
bug
fixes
to
be
released
this
week.
Metrics
work
is
still
ongoing
and,
of
course,
there's
the
continuous
ask
for
more
developers,
yeah
any
updates
from
ruby
or
swift.
A
A
F
Yeah,
that's
correct.
I
think
that
the
main
thing
about
this
is
that
instrumentation
needs
to
be
updated.
So
if
any
of
the
maintainers
here
maintainers
here
have
to
maintain
any
instrumentation
piece,
please
take
a
look.
This
is
an
actual
change
to
be
more
conservative
towards
our
users.
So
please
take
a
look.
Morgan,
you're,
putting.
C
Yeah,
so
I
wanted
to
just
chat
a
little
bit
about
without
maintainer,
with
maintainers
about
semantic
inventions
and
schema
evolution.
C
So
in
the
java
sig
this
week
or
last
week,
we
spent
a
considerable
amount
of
time
trying
to
talk
through
how
we
should
deal
with
the
evolving
semantic
conventions
and
also
we're
also
curious.
Just
from
you
know
the
spec
maintainers
perspective.
Are
we
ever
going
to
market
mark
those
as
1.0,
so
we
can
actually
have
stability
there,
but
the
big
question
I
have
for
maintainers
is:
what
are
you
doing
with
the
ammo?
Are
you
generating
constants?
Are
you
doing
some
sort
of
code
generation
or
something
in
your
languages?
C
And
if
so,
what
are
you
planning
on
doing
when
the
the
semantic
inventions
rev
and
there
are
potentially
incompatible
or
like
convent,
like
things
removed
or
names
changed,
or
that
sort
of
thing
right
now
for
java
we're
just
we
generate
a
version
that
is
aligned
with
emel,
but
we're
not
versioning
within
that.
So
if
things
get
deleted,
instrumentation
that
was
using
file
at
1.6
would
that
could
potentially
break
when
1.7
was
released,
which
of
course,
is
not
good.
C
G
Okay,
cool,
yes,
want
to
double
check.
I
would
also
recommend
talking
to
tigran
he's
smart
dude
yep
we've
been
we've
been
chatting.
C
I
mean
some
of
the
subtlety
is
like
we
actually
think
in
java
it'd
be
useful
to
break
up
the
generation
by
type
so
have
a
file
that
has
the
http
conventions
and
one
that
has
rpc
conventions,
one
for
database
conventions,
etc.
If
it's
possible
to
do
that,
because
it
means
that
then
instrumentation
could
depend
only
on
the
things
that
they
care
about,
rather
than
kind
of
having
to
bring
in
everything
all
at
once.
It's
a
it's
a
thought.
C
We
also
pondered
whether
it
would
be
possible,
rather
than
generating
the
entire
semantic
invention,
constants
every
release,
but
to
actually
use
the
schema
evolution
to
generate
diffs
some
sort
of
diff
file,
rather
than
having
to
continue
just
copying
everything
over
and
over
again,
even
when
in
most
cases
nothing
will
have
changed.
C
So
we're
still
pondering
ideas
and
just
wanted
to
get.
You
know
some
feedback
from
other
containers,
that's
great
by
the
way,
john,
if
you
haven't
noticed
we're
in
in
the
instrumentation
sig
we're
in
the
process
of
rearranging
the
semantic
conventions,
just
how
they're
laid
out
in
the
spec
and
thinking
about
regenerate
how
to
generate
them
better.
So
this
is
like
really
good,
really
good
timing.
C
Well,
yeah,
it
was
funny
that
you
know
we
had
a
extensive
half
hour
discussion
in
the
javascript
and
then
tigran
login
issue,
not
having
any
idea
that
we
were
already
discussing
it
specifically
to
bring
this
up.
So
obviously,
it's
top
of
mind
for
a
lot
of
people.
Yeah.
Well
one
question
I
I
have.
I
don't
know
if
you
guys
have
thought
about
this,
but
we
should
assume
that
applications
are
loaded
up
with
instrumentation
packages
that
produce
potentially
produce
a
skew
of
versions
of
a
particular
semantic
convention.
C
C
That's
done
the
work
to
ensure
every
single
instrumentation
package
is
like
up
to
date
on
the
same
version,
but
assuming
we
can't
keep
all
the
instrumentation
all
exactly
on
the
same
version,
which
seems
like
a
realistic
situation
that
users
would
be
in
in
a
lot
of
languages
being
able
to
to
tell
what
schema
version
each
each
api
packages
or
yeah
each
instrumentation
package
is
at
would
probably
be
helpful.
H
C
C
C
Is
definitely
still
an
issue
even
with
auto
instrumentation
ted,
because
the
auto
instrumentation
agent
still
lets
people
use
the
api
and
they
can
bring
in
library
instrumentation
that
uses
the
api
directly
exactly
yeah.
C
Okay,
I
mean
it
sounds
like
we've
got.
The
we've
got
the
building
blocks.
We
need
to
to
do
this,
but
I
just
wanted
to
make
sure
that's
we're
not
presuming
that
one
sdk
deployment
equals
one
schema
version.
I
guess
right
yeah,
no
for
sure.
C
Well,
the
other
thing
that
we're
thinking
about
for
java
is
to
actually
move
the
semantic
invention,
constant
generation
out
of
the
main
repo
and
either
putting
it
into
the
instrumentation
repo
or
into
a
separate
repo
like
we
did
for
the
proto
bindings,
because
it
is
something
that
should
be
published
with
the
spec.
C
The
spec
is
released,
not
necessarily
when
java
happens,
to
release
so
anyway
and
probably
need
backwards.
Compatibility
in
that
that
file
as
well
right,
oh
yeah,
that's
that's!
That's
the
main
thing
that
we're
worried
about
yeah
so
like
what
is
our
convention
for
for
naming
newer
versions
of
existing
stuff,
it
would
be
good
to
have
have
a
convention
for
that
that
we
share
across
different
languages
yeah,
it's
probably
going
to
vary
by
language,
the
specifics,
because
in
java
we
have
many
options.
C
One
thing
that
we
probably
have
to
do
is
the
java
the
java
package,
not
talking
about
the
the
the
maven
coordinates,
but
the
actual
java
packages
inside
the
jar
have
to
change
with
every
release,
which
is
a
little
annoying,
because
it
means
that
if
any
time
anyone
will
need
to
upgrade
their
version
of
the
semantic
inventions,
their
code
will
absolutely
need
to
change
if
they
want
to
use
new
conventions
as
opposed
to.
If
nothing.
This
is
one
thing
that
honor
august
brought
up
is
like.
C
C
Some
diff
like
generate
diffs
or
something
with
continually
extending
the
previous
version
or
something
I
don't
know
anyway,
it's
kind
of
it's
complicated
like
finding
a
good
solution.
That's
ergonomic
for
the
instrumentation
author
is
actually
fairly
tricky.
Yeah
I
mean
have
you
thought
about
just
like
there's
just
one
package
and
like
just
constants
are,
and
everything
are
immutable,
and
then
you
know
new
things
come
in
with
a
v2
or
v.
C
You
know
where,
where
is
the
v2
or
v3,
though,
on
the
constants
right
I
mean
that
that
sounds
like
kind
of
annoying
to
to
deal
with.
I
don't
even
know
how
that
would
you
would
have
like
http
url,
v2,
http
or
lvc
sounds
obnoxious.
That
sounds
horrible
yeah,
because
you'd
also
have
to
detect
when
they
changed.
In
that
case,
right.
G
C
Yeah,
but
I
mean
like
the
flip
side,
is
like
users
bringing
in
like
30
different
packages
of
constants
or
something
yeah.
No,
it's
ugly.
I
mean,
I
think,
it's
all
ugly.
H
I
H
C
It's
good
to
talk
about,
I
mean
maybe
name
spacing-
is
a
way
way
to
do
this,
unlike
like
get.
This
gets
back
to
what
you're
saying
before.
If,
like
we
conversion
these
constant
name
spaces,
maybe
that's
saner
like
being
able
to
track
when
http
gets
an
update,
that's
backwards
incompatible,
then
the
http
convention
essentially
has
to
get
versioned
yeah
and
then
the
version
naming
gets
super
weird
like
what
is
it?
Is
it
named
with
the
spec?
C
C
I
don't
know
I
mean
because
I
mean
go
package
or
python
package.
I
mean
I
mean
like
not
having
not
generating
new
packages
per
per,
not
having
to
to
create
a
new
package
per
specification
release
right,
like
creating
a
new
package
per
backwards
and
compatible
change
to
the
conventions
or
if
the
conventions
are
split
out
by
by
their
name
space
into
sub
packages.
Only
versioning
those
things
when
there's
a
backwards,
incompatible
change
or
something
something
like
that.
A
That
needs
to
get
explored
like
what's
the
so,
what's
the
next
step
for
for
this
right?
Is
it
like
some
github
discussion
or
github
issue?
Is
it
some
meeting
during
the
sig
that
you
mentioned
ted.
C
Yeah
I
mean,
I
think
I
think
it
would
be
helpful
for
the
requirements
here
to
all
get
get
laid
out
in
a
single
spot,
which
kind
of
sounds
like
an
otep
to
me,
along
with
a
proposal
for
like
a
way
to
to
handle
all
of
this,
and
that
might
include
having
to
like
have
have
the
name
spacing
of
conventions,
become
a
more
concrete
concept
in
the
spec,
for
example.
C
But
it
would
be
nice
if
it
would
be.
I
think
helpful
if
we
had
a
concrete
proposal
for
how
to
do
this,
and
not
just
have
every
language
try
to
figure
it
out,
because
it
feels
to
me
like
we
need
more,
like
information
coming
out
of
the
spec,
for
example.
To
do
this
same
way,
regardless
of
how
any
language.
A
A
Fair
enough,
okay,
we
we
can
bring
this
up
in
the
instrumentation.
That's
that's
that's
what
I
was
thinking.
Yeah
yeah.
C
I
always
think
well,
I
was
thinking
tigre
and
I
were
planning
on
bringing
it
up
tomorrow,
just
in
the
main
spec
meeting-
that's
all
great,
so
we
can.
We
can
start
there.
I
think
and
then
move
on
and
the
instrumentation
meets
after
the
spec
tomorrow.
So
yeah
follow
up.
I'm
happy
to
help
help
draft
this
for
sure,
but
I'd
like
to
do
it
in
conjunction
with
other
people
who
are
struggling
with
it.
A
Cool
all
right
next
topic
should
be
pretty
quick,
so
I
will
be
updating
the
zoom
meeting
links
for
all
of
our
all
of
our
sig
meetings
later
this
week.
So
there's
a
challenge
that
we
have
today
and
that's
that
we
have
four
zoom
accounts
and
we
exclusively
use
zoom's
instant
meeting
functionality
to
create
meetings.
A
This
means
that
we
can't
have
any
more
than
four
overlapping
meetings,
which
is
a
problem
on
thursday
mornings,
and
it
also
means
if
we
have
back-to-back
meetings
with
the
same
code,
sometimes
they
just
kind
of
flow
into
each
other,
which
is
not
fantastic
for
our
youtube
recordings
and
everything
else,
and
so
we've
wanted
to
fix
this.
For
a
while,
I
reached
out
to
kubernetes,
and
the
suggestion
of
the
cncf
turns
out.
Kubernetes
has
the
exact
same
problem
as
of
us,
and
they
have
not
solved
it.
A
Their
solution
has
just
been
getting
like
15
zoom
accounts
or
something
like
that
which
the
cncf
is
not
eager
to
do
for
us
to
say
the
least.
So
what
I'm
trying
and
what
I
was
testing
out
last
week
with
a
variety
of
meetings
that
seemed
to
work,
was
using
one
of
our
zoom
accounts
and
then
generating
unique
meeting
codes
for
each
meeting,
as
if
kind
of,
if
you
zoomed
the
way
you
integrated
google
calendar
for
yourself
as
a
human,
this
seems
to
work.
We
tried
two
of
them
in
parallel
last
week.
A
No
issues
doesn't
matter
that
the
the
fake
zoom
account
person
never
signs
in.
So
that
appears
to
work
really.
It's
mostly
upsides.
Another
sort
of
nice
side
effect
of
this
is
that
zoom
will
know
the
names
of
our
meetings,
because
zoom
will
be
integrated
with
our
calendar,
meaning
that
the
youtube
recordings
should
just
automatically
pick
up
the
meeting
names,
which
is
really
really
good
and
something
that
people
wanted
for
a
long
time.
A
There's
one
downside
and
that's
to
generate
to
to
edit
a
meeting
or
to
generate
a
new
zoom
code
for
a
meeting
you
need
to
be
have
your
google
calendar
linked
with
the
zoom
account,
so
what
I
still
need
to
figure
out
before
we
really
commit
to
this
is
if
multiple
people
can
link
their
sort
of
version
of
the
google
of
the
shared
google
calendar
with
zoom
or
if
we
need
to
create
a
shared
google
account.
The
downside
of
the
shared
google
account
would
mean
that
people
can
no
longer
edit
the
calendar
themselves.
A
C
A
Maybe
I
know
one
of
the
downsides
is
there's
a
maximum
length
on
certain
meetings
like
the
meeting
will
automatically
end.
I
think
after
either
the
one
like
at
some
point.
Basically
after
the
meeting
is
over.
If
people
are
still
on
and
talking,
it's
gonna
cut
cut
out
from
them.
Okay,
I
don't
know
about
having
to
refresh
the
codes.
It
wouldn't
surprise
me
if
we
needed
to
on
some
cadence.
C
Yeah
I
recall
I
I
could
be
wrong
or
maybe
they've
changed
this,
but
I
recall
that,
like
repeating
meetings
in
zoom
yeah
have
some
like
max
number
of
times.
They
repeat,
okay,
so
there's.
A
C
C
C
A
This
is
also
a
challenge
here
like
if
we
have
a
shared
google
account.
It
might
not
be
so
bad,
but
we
generally
want
the
calendar
view
to
be
as
editable
as
possible,
so
maintainers
can
move
meetings
around
and
cancel
occurrences
and
things
without
causing
issues.
So
this
is
also
a
challenge
I'm
trying
to
work
through.
I
think
for.
A
C
A
Don't
think
we
should.
We
may
then
also
want
to
use
this
as
an
opportunity
to
move
the
calendar,
because
I
think
the
calendar
is
still
owned
by
my
old
google
account
when
I
was
at
google
that
no
longer
exists,
which
is
why
we
can't
increase
the
number
of
editors
on
it.
So
if
we
create
a
shared
google
account,
this
may
also
be
an
opportunity
just
to
permanently
move
that
so
that
we
can
unlock
the
permissions
a
bit
more.
That
sounds
like
a
great
idea:
okay,
you've
definitely
had.
A
It's
a
good
point
as
well:
yeah
there's
always
been
a
risk
with
them
like
if
people
type
meeting
notes
through
gmail
accounts
is
generally
fine,
but
there's
a
risk
that
if
people
create
meeting
notes
or
important
critical,
specs
or
other
docs
for
the
project
that
are
tied
to
a
corporate
account
and
then
they
change
jobs.
I
believe
at
some
point
those
get
deleted.
A
D
We
had
this
problem
in
js,
our
old
maintainer
mayor,
kale,
owned
our
sig
document
yep
and
when
he
had
some
job
change
or
something
I
I
don't
even
remember
exactly
what
happened
but
he's
he
was
still
even
at
google,
but
we
got
locked
out
of
it
and
he
was
no
longer
a
part
of
the
project
and
he
happened
to
be
on
vacation
when
it
happened.
A
Yeah,
so
this
would
be
nice
because
then
we
can,
we
can
establish
ownership
of
all
of
our
docs
with
a
shared
google
account
all
right.
So
I
will
take
the
action
to
research.
This
50
meeting
limit
on
zoom
and
find
out
a
workaround
and
assuming
we
can
make
that
work,
then
I
will
go
create
a
shared
google
account
for
the
projects
for
the
project
and
shift
all
the
meetings
over
all
right.
Next
up
is
ouch.
J
Hey
everyone
yeah.
I
just
wanted
to
basically
get
a
discussion
around
and
understand
if
there
is
any
general
policy
or
a
general
discussion
around
a
support
for
runtimes
and
older
runtimes,
I
think
we
let's
say,
for
example,
we
have
support
for
our
artifacts
around
python,
3.6
or
higher,
but
there
may
be
a
number
of
users
who
are
still
on
the
older
runtime
versions.
J
So,
however,
we
just
wanted
to
understand
more
across
if
we'd
be
able
to
determine
where
most
of
our
users
are
or
or
being
able
to
identify
whether
we
need
to
support
older
runtimes
and
where
are
we
stopping
at?
Maybe
just
wanted
to
bring
this
up
to
the
group
and
whether
we
had
to
speak
more
about
it.
A
J
B
Yeah,
so
in
python
and
donut,
I
I
think
people
struggled
with
that.
I
can
share
my
thinking.
I
think
there
are
three
type
of
things
number
one
is
do
we
support
some
very
old
version
that
is
already
deprecated
by
the
language,
the
official
community,
for
example,
in
this
case
python,
2
or
donaid
5
4.0.
B
So
you
can
see
like
if
you
look
at
python
2,
it's
already
deprecated,
probably
like
two
years
ago,
downloaded
four,
probably
deprecated.
Like
many
many
years
ago.
There
are
some
users
who
have
critical
business
running
on
this
older
version.
They
know
they
are
deprecated
they're
not
going
to
get
any
security
hot
fix,
but
yet
they
cannot
move
out.
So
they
come
back
and
say
I
I
even
want
to
contribute.
I
I
already
have
the
the
code
div.
That
makes
it
work,
and
can
you
accept
that
I
I
think
so
far.
B
The
answer
is
no,
because
just
supporting
this
metrics
means
a
lot
for
the
maintainer
and
and
we
don't
see
a
common
need.
So
I
guess
probably
we
can
see
if
people
asking
for
those
versions,
they
can
make
a
div
in
the
country
repo
given.
This
is
not
going
to
be
used
by
a
lot
of
customers.
B
B
B
I
think
we
should
encourage
people
to
upgrade,
but
if
they
see
some
need
it's
case
by
case,
depending
on
how
how
much
the
div
would
be,
for
example,
in
donet,
what
we
do
is
whatever
donated
version
that
is
officially
supported
by
microsoft
in
opentime2.net
will
support
the
same,
but
there
is
one
exception:
there's
doughnut
3.5.1,
which
is
very
old,
but
somehow
probably
a
mistake.
It
was
tight
as
part
of
the
windows
operating
system,
so
it's
subjects
to
the
windows,
support
lifecycle,
which
is
10
years
for
normal
user
and
15
years.
B
If
you
want
to
pay
extra
money
for
extended
support,
that's
that's
miserable,
so
we
decided
in
open
time
to
donate.
We
don't
do
that
because
we
have
a
good
understanding
that
people
who
are
using
that
version
is
only
using
that
as
part
of
windows,
doing
some
client
and
given
here
we're
doing
services
we're
doing
this
retracing.
So
we
think
we're
going
to
add
very
few
value
to
them.
C
I
I
do
think
open
planetary
should
try
to
be
conservative
about
using
new
language
features,
though
I
think
what
you're
saying
is
totally
right.
Riley
like
stuff,
that's
that's
deprecated,
perhaps
with
the
caveat
on
how
big
the
user
base
currently
is.
C
I
know
this
was
like
a
struggle
in
java
for
a
while
right,
because
the
community
wants
to
camp
on
java
6
forever,
but
at
the
same
time,
like
really
difficult
to
support
old
versions,
I
think
should
be
dropped
like
in
the
case
of
java,
like
it
was
just
a
fundamental
improvement
to
how
open
telemetry
could
be
written.
C
If
java
6
support
was
dropped
but
at
the
same
time
just
grabbing
at
new
features,
because
they're
new
or
doing
something
that
would
force
users
to
be
on
the
latest
version
of
pipe
like
something
where
people
would
be
noticing
open.
Telemetry
is
like
their
pressure
to
upgrade.
It
would
be
be
nice
if
we
avoided
that,
where
possible.
C
Just
because
open
telemetry
is
a
a
widely
deployed
dependency,
it
would
be
nice
if
we
were
not
the
dependency
that
was
putting
the
pressure
on
people
to
to
upgrade
unless
it
was
something
we
needed
to
do,
because
it
really
benefited
the
open
telemetry
project
in
some
material
way.
C
If
that
makes
sense
for
java,
it
was
actually
java.
Seven,
not
six
java
7
like
java
8,
is
the
current
oldest
long-term
support
version
of
java,
which
is
what
so
that's
what
we
target.
The
java
7
is
no
longer
in
long-term
support
unless
you're
paying
oracle
an
obscene
amount
of
money
to
get
on
custom
security
patches.
C
J
The
observation
for
sure
and
yeah-
I
was
just
trying
to
think
about
that.
Whether
there
is
any
kind
of
review
across
different
languages
to
identify
this
kind
of
perspective,
right
that
whether
we
really
need
to
make
that
kind
of
a
decision
of
dropping
a
support
versus
not,
I
think,
that's
a
good
fallout.
C
Yeah
I
like
the
idea
of
the
the
oldest
supported
version
of
a
runtime,
is
the
one
we
should
we
should
target.
I
have
a
feeling
that,
when
java
8
goes
out
of
lts,
which
I
think
is
coming
up
in
a
pretty
soon,
I
mean
now
that
java
17
is
the
newest
lts
version.
That's
out
we're
going
to.
We
will
need
to
support
java
8
for
basically
the
rest
of
our
lives.
Even
if
it's
not
an
lts,
because
it
is,
people
will
be
using
it
forever.
G
Point
I
think
this
is
a
similar
thing
that
we
found
in
go
as
well.
It's
definitely
you
know
I'm
not
trying
to
disparage
java,
but
it
moves
faster
than
the
java
language
and
so
like
they
also
have
a
support
for
the
past
two
minor
releases,
and
then,
after
that,
it's
I
don't
think
if
they
apply
any
security
updates
to
the
language
you
know
prior
to
that,
but
you
know
we,
you
know
these.
G
These
releases
are
coming
out
every
few
months,
so
we
released
the
1.0
of
open
symmetry
go
and
it
supported.
I
think
it
was
1.15
and
now
that's
out
of
the
support
for
the
main
go
language,
but
we
still
want
to
try
to
support
it.
G
I
think,
because
of
the
release
and
exactly
what
ted
was
saying
like
having
you
know
forcing
users
that
they
can't,
they
cannot
run
open,
telemetry
because
they're
still
using
one
point,
five
or
one
five
is,
I
think,
not
ideal
agreed
yeah
exactly
yeah,
and
so
I
think
that's
kind
of
our
stance
on
it
as
well.
It's
still
debated,
but
I
think
that
it
also
goes
really
good
about
backwards,
compatible
support.
A
Yeah,
I
was
wondering
like
just
because
I
you
you
had
some
data
behind
this
like
maybe
if
we
picked
up
a
set
of
languages
or
set
of
like
languages
or
versions,
you
wanted
to
investigate
yeah.
J
That's
definitely
and.
A
We
could
also
yeah,
and
also
this
call
or
in
a
different
call,
like
I'm
sure,
ted,
probably
has
a
list
of
of
ones
you've
heard
at
lightstep
and
and
they're,
probably
people
from
other
other
vendors
or
end
users
who
have
comments
or
questions
or
concerns
about
supporting
certain
versions.
We
could
maybe
just
get
a
list
of
what
what
the
community,
what
we've
heard
that
people
want
versus
what
we
actually
serve.
H
C
New
features
that
would
require
some
to
upgrade
are
are
optional
right
and
in
some
cases
those
new
features
actually
make
a
substantial
impact
on
either
the
performance
or
the
code,
quality
of
open
telemetry
and
in
those
cases,
there's
like
a
good
case
to
me
be
made.
I
think,
like
java
8
support
was
like
a
good
example
of
that,
where
it
really
was
a
substantial
difference
in
how
the
project
could
be
written.
C
If
I
recall,
but
you
know,
if
that's
not
the
case,
if
it's,
if
there's
no
like,
if
it's
just
like,
perhaps
mild
inconvenience
to
the
maintainers
of
the
project,
to
stay
away
from
the
new
features,
then
it
would
be
nice
to
do
that
for
a
community.
So
if
that's
that
conservativism
is
like
our
default
stance,
I
think
that's
helpful.
J
C
Yeah,
just
you
know,
to
add
a
little
bit
more
color
commentary
on
the
java
side.
Android
makes
it
more
complicated.
Yes,
we
like
we
are
on
java
8,
but
there
are
java
8
classes.
We
cannot
use
because
they're
not
supported
on
android,
which
is
extra
annoying
because
there
we
had
to
invent
our
own
future
responses,
because
the
future
that
the
modern
one
doesn't
work
on
android,
so
yeah
and
stuff
like
that.
A
C
C
D
D
D
New
browsers,
sometimes
don't
support
all
of
the
the
api
in
javascript,
it's
very
difficult
to
to
make
you
know
hard
promises
about
support
unless
you
test
on
every
specific
version.
A
H
Here
it's
the
compiler,
because
we
have
a
source
releases
for
our
open
telemetry.
So
basically
we
have
to
ensure
that
we
have
to
support
the
minimal
base
compiler
across
all
the
platforms.
Our
development
is,
I
mean
we
support
c
plus
plus
11..
H
H
So
even
though
gcc
4.8
is
the
minimal
c
plus
11
version
which
supports,
but
we
have
to
remove
the
support
of
gcc
4.8
just
because
these
libraries
have
stopped
supporting
4.8
and
they
started
supporting
5.1
as
a
minimal
gcc
compiling
volume.
So
just
because
of
the
dependencies
of
these
libraries,
we
have
to
remove
those
supports,
so
I
mean
case
to
case.
Basically
we
have
to
decide
for
each
of
those
platforms.
J
C
C
You
know
like
we
should
pre,
especially
for
like
big
organizations.
They
often
move
very
slowly
at
updating
stuff
and
as
long
as
we're
weighted
towards
that
and
not
weighted
towards
like
being
eager
to
use
new
features,
then
it's
mostly
good,
but
yet
like
the
lead
just
brought
up.
Sometimes
it's
tough
right.
It's
like
do.
We
continue
to
support
this
compiler,
or
do
we
like
rip
out
this
dependency?
We
were
using.
A
Yeah
well-
and
I
think
maintainers
also
have
a
lot
of
just.
They
already
have
a
very
high
workload
in
this
project
yeah,
and
so
I'm
also
cautious
of
of
like
yeah
it'd
be
great.
We
could
snap
our
fingers
and
say
we
support
this
other
older
version
of
java
or
something
but
the
poor
java.
C
As
long
as
maintainers
have
experience
in
their
language
ecosystem
and
they're,
you
know
we're.
We
do
some
work
if
we
decide
we're
going
to
drop
something
we
currently
support
to
just
make
sure
that's
not
going
to
be
like
a
big
problem
for
our
user
base.
I
think
that's,
maybe
kind
of
the
requirement
like
to
throw
it
out
to
the
community
that
we're
considering
dropping
support
for
something
where
support's
getting
dropped,
just
to
to
give
people
opportunity
to
respond
to
that
yeah.
Okay,.
A
F
A
Gonna
you're
gonna
chat
around,
I
think,
with
some
of
our
customers
and
maybe
talk
to
ted
and
some
others
about
just
if
they've
heard
of
language
versions
that
aren't
supported
that
need
to
be,
and
then
we
can
just
basically
pass
that
info
onto
the
maintainers.
I
think
for
some
of
these
the
answer's
going
to
be
no
like
that's
too
hard.
We
can't
do
that.
I
think.