►
From YouTube: 2022-01-19 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).
B
A
Right,
let's
start
two
open
issues:
the
the
name
and
blogger
name
for
the
name.
We
have
a
pr
we
have
approvals.
I
think
we
need
to
keep
it
open
for
at
least
a
few
days
to
make
sure
that
people
see
this
change.
A
A
Hopefully
we
will
have
a
resolution
on
this
in
a
few
days,
so
this
one
is
good
on
the
logger
name,
I
haven't
been
able
to
get
any
resolution,
or
I
guess,
or
a
specific
opinion
from
bogdan
about
how
we
solve
this.
So
what
I
would
like
to
do,
I
don't
want
to
delay
this
by.
A
A
It
would
just
mean
clarifications
and
and
how
we
intended
the
the
instrumentation
library
name
to
be
used
by
the
rest
of
the
by
the
rest
of
the
open
language
specification,
particularly
the
logger
name,
meter
name
and
also
what
it
means
for
the
for
the
logs
right
that
the
longer
names
also
loader
name
is
also
stored
in
the
instrumentation
library
name,
essentially
keep
the
the
current
situation,
as
it
is
just
just
two
clarifications
and
then
see
where
that
takes
us,
because
at
this
stage
I
don't
see
the
I
haven't
been
able
to
do
it
myself.
A
There
is
no
champion
who
will
do
this,
so
I
I
don't
see
the
possibility
of
this
happening
any
time
and
then
by
just
keeping
it
open
for
indefinitely
long
is
not
going
to
solve
it.
I
don't
see
that
happening,
so
I
think
that's
that's.
What
I'm
going
to
try
to
just
clarify
the
current
state
of
things
and
be
done
with
it.
It
will
be.
A
A
C
I
think
it
makes
sense
it's
pretty
clear
that
we
we
can
clarify
what
the
intention
of
the
field
is.
It's
just
a
bad
name.
That's
all.
It
is
really
right.
A
A
So
that's
with
the
logger
name,
then
you
have
the
next
item:
log
collection,
library,
v2.
C
Yeah
just
drafted
a
a
list
of
changes
that
I
think
would
make
sense
for
the
log
collection
library
in
light
of
basically
recent
changes
to
the
data
model
and
to
some
extent
there
were
a
few
slight
misalignments
between
the
original
stanza
contribution
and
the
data
model
as
it
was
that
were
never
reconciled
just
because
it
appeared
that
it
would
be
a
lot
of
effort
and
the
data
model
was
still
not
clear
or
the
stability
of
the
data
model
was
not
well
established.
C
Yet
I
think
we're
at
a
point
where
at
least
this
group
believes
we
are
very
close
to
stability,
and
so
I
think
it
makes
sense
to
pursue
some
changes
to
the
log
collection
library
that
would
completely
align
it
with
the
latest
data
model
and
just
make
it
basically
make
the
user
experience
of
using
it
makes
sense
to
someone
who's
thinking
about
it
in
terms
of
the
data
model.
C
So
I
don't
know
that
we
necessarily
should
go
through
this
document.
I
know
a
lot
of
folks
here.
Just
aren't
probably
deeply
familiar
with
the
library,
but
if
you
are
curious
or
if
you
want
to
please
comment,
please
review
and
comment
and
make
sure
we
can
discuss
further
if
necessary,
but
I
think
otherwise
the
next
step.
I
would
would
be
that
I'll
create
issues
for
these.
We
can.
C
We
can
discuss
on
individual
issues,
and
I
suppose
the
big
point
here,
though,
is,
is
that
I
believe
30
breaking
changes
and
this
would
be
a
v2
of
the
library.
So
I
guess
the
immediate
question
is:
are
we
okay
with
that?
I
I
think
we
should
be
at
this
point,
but
is
anyone?
Does
anyone
object
to
that
that
notion.
A
No
objections
from
my
side.
I
think
that's
the
right
approach
and
we
only
have
a
handful
of
components
which
depend
on
what
collection,
library
right
it's
file,
log,
some
others,
maybe
yeah
yeah
they're
about
five
right
now.
Yeah.
A
Can
you
so
I'm
looking
at
the
document?
Can
you
also
it
says
what
the
final
state
is
going
to
be.
It
would
be
very
useful
to
to
show
what
is
the
current
state,
how
we
want
it
to
be
changed
right.
Sure,
I'm
not
completely
familiar
with
the
current
implementation
of
everything
in
that
collection
library.
It
would
maybe
help
understand
the
the
what
exactly
is
changing
right.
So
what
what
are
the
breaking
changes?
A
From
and
with
the
logger
name,
I
don't
know
if
we
will
anyway,
I
guess
it
depends
on
how
quickly
we
will
be
able
to
declare
that
part
here
in
the
specification
as
table.
If
not,
maybe
that
will
be
another
one
more
pass
on
the
log
collection
library,
or
do
you
want
to
delay
this
until
we
make
a
decision?
Final
decision.
C
Here,
what
do
you
want
to
do?
No,
so
I
actually
think
that
in
in
the
case
of
the
log
collection
library,
the
decision
is
irrelevant
because,
ultimately,
the
user
is
going
to
need
to
capture
the
logger
name
and,
and
it's
just
a
matter
of
how
the
translation
from
this
log
collection,
internal
data
model,
is
going
to
map
to
p
data
logs.
C
And
if
we
go
the
other
way
with
it,
then
basically
it
will
just
map
directly
onto
a
field
on
the
log
on
the
log
record.
So
I
think
it's
okay
either
way,
and
even
though
we're
we're
leaning
against
having
that
extra
field.
I
think
it's
just
a
internal
data.
Modeling
thing
in
the
case
of
this
production
library.
A
C
Exactly
exactly
yeah
it's
just
and
it
will
be
exposed
to
the
user
in
the
sense
that
they'll.
I
think
there
should
be
a
logger
named
parser,
basically
just
to
give
them
an
easy
way
to
set
that
value,
but
other
than
that
it
would
be
yeah.
Just
an
intro.
Okay,.
A
A
What's
the
other,
the
the?
What
do
you
want
to
add
to
the
the
microphone.
C
That
the
next
step
will,
after
this
document,
is,
if
there's
any
immediate
feedback,
please
put
it
on
the
document
and
we
can
iterate
a
little
bit
there,
but
the
next
step
will
be
I'll.
Just
move
these
two
as
issues.
I
think
that
would
make
sense
to
well
sorry.
I
guess
I
was
making
an
assumption
there.
C
I
think
it
would
make
sense
to
put
these
on
the
basic
log
support
milestones
so
that
when
we
cut
when
we
declare
the
collector
components
basically
stable,
that
they
would
be
dependent
on
on
all
the
changes
that
are
in
the
pipeline
here
relating
to
the
data
model,
but
certainly
we
could
we
could
push
towards
minimizing
the
changes
in
some
way.
If
anyone
feels
strongly
about
that.
B
C
B
B
A
C
On
it,
the
yeah
we
do,
I
think
we
can
adapt
to
the
same
changes
pretty
easily,
but
probably
there'd
be
a
slight
preference
towards
towards
preserving
compatibility
initially.
C
C
So,
yes,
I
think
that
the
major
version
proposal
was
primarily
motivated
with
just
a
sense
of
that.
There
are
some
users
out
there
and
this
would
be
perhaps
slightly
disrupt
less
disruptive
to
them,
but
I
do
think
we
can.
We
can
proceed
with
that.
I
think,
if
we're,
if
we're
comfortable,
causing
a
little
bit
of
disruption
to
those
who
are.
C
It's
not
just
like
a
developer
problem,
but
there
may
be
some
people
who
have
deployed
the
collector
in
some
way.
I
don't
know
but.
B
It
means
that
they
are
getting
significant
breaking
change
after
that,
anyway,
whether
we
mark
another
version
of
login
library
or
not,
probably
users
of
the
collector,
don't
even
know
what
the
library
is
being
used
by
the
collector
internally.
So
it's
like
pretty
less
visible
to
them,
which
version
change
with
the
login
library
comparing
to
which
version
change.
Collector
went
through
with
this
breaking
changer
right.
A
I
think
it's
okay,
we
we
definitely
then,
should
call
out
the
configuration
changes
in
the
collector
release,
but
I
think
we
can
go
with
the
0x
for
the
low
collection
library
for
now.
Okay
sounds
good,
so.
A
Yeah,
that's
the
main
one.
Okay.
Can
you
is
it?
Do
you
have
that
in
the
document?
Do
you
describe
what
changes
are
from
the
configuration
settings
perspective.
C
A
B
Okay,
probably
maybe
not
should
be
not
only
a
change
log
but
some
upgrading
guidelines,
because
it
may
be
more
actions
to
be
taken
by
the
users
of
the
particular
component,
so
yeah.
A
A
I
think
we're
good
with
that
and
I
had
one
more
item,
which
is
the
addition
of
the
observed
timestamp
to
the
proto.
Let
me
give
you
guys
the
link,
I'm
posting
here
in
the
zoom
chat.
Please
have
a
look
and
approve
the
the
addition
of
the
new
timestamp
field.
The
second
time
stop
observe
timestamp
to
the
to
the
whole
tlp
proto,
please
review
and
approve.
I
don't
have.
I
only
have
one
approval
so
far.