►
From YouTube: 2023-01-11 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
Martin
logs
SDK,
how
far
is
it
is?
How
does
it
look
like.
D
Well,
I
haven't
made
much
progress
actually
over
the
holidays,
and
last
week
I
was
onboarding,
so
I'm
just
kind
of
getting
back
to
it
back
into
it
this
week.
Okay,
but
it's
it's
at
the
top
of
my
list,
so
I
know
I've
been
saying
that
for
a
long
time,
but
I
I
really
do
want
to
move
it
forward,
as
you
do
so,
I
just
I
just
had
a
lot
going
on.
D
Okay,
I'm
still
kind
of
stuck
on
the
API
there
is.
There
is
a
there
is
a
PR
open
from
somebody
else
that
wants
to
separate
the
well
who
wants
to
basically
bring
the
API
events
API
up
to
up
to
the
spec,
but
I
think
the
spec
is
just
not
right
right
now,
so
you
know
I'm
kind
of
stuck
on
like
what
do
we
really
want
to
do
with
the
API.
D
Well,
so
this
the
spec
there's
so
the
spec
first
of
all,
doesn't
have
just
just
defines
it
as
a
as
a
not
a,
not
really
an
API.
It's
just
a
class
like
there's
a
there's,
an
event,
blogger
class,
that
all
it
does.
It
takes
a
log
record
and
a
name
and
you
just
instantiate
that
class
and
probably
behind
the
scenes.
All
that
it
will
do
is
is
just
move.
The
you
know
copy
the
name
to
the
log
record
as
an
attribute,
but
that's
all
it
will
do.
D
The
API
doesn't
really
help
you
with
anything,
but
you
might
as
well
just
add
the
attribute
yourself
in
my
opinion,
and
it's
not
really
like
API
in
the
sense
of
an
interface
that
you
can
Implement
have
different
implementations,
it's
just
a
single
class
right.
It's
like
a
on
top
of
the
log
records.
So
do
we
want
that?
D
You
know
we
discussed
that
with
with,
in
the
logic
I
think,
before
the
holidays
and
tigrant
was
saying
that
we
should.
We
should
come
up
with
an
API
that
works
for
us
that
makes
sense
and
propose
it
because
right
now
it's
in
my
opinion,
it's
not
a
good
API
right
now.
It
doesn't
really
help
with
anything
so.
B
I
I
want
to
understand
that
further
I
think
there
are
some
facts
that
we
cannot
change
right,
which
is
we
we
have
to
base
our
events
on
the
log
records
and
the
log
record
data
model
has
a
bunch
of
fields
that
are
not
relevant
to
an
event
and
and
also
we
have
also
agreed
on
what
kind
of
what
log
records
are
to
be
called
as
events
right
so
and
an
event
is
a
log
record
with,
with
you
know,
two
attributes
event.name
and
even
dot
domain.
B
So
as
long
as
and
the
purpose
of
the
event
API
is,
is
to
help
the
event
producers
to
to
produce
events
in
in
this
format.
So
you
you,
you
take
a
name
event
name
you
take
a
bunch
of
attributes
and
and
and
also
a
domain
and
and
then
you
create
the
log
records.
So
I,
not
100
clear.
You
know,
even
though
the
event
API
itself
has
system
is
a
minor
addition
to
the
logged
API,
the
log
API
itself.
B
So
so,
even
if
it's
a
thin
layer,
I
think,
let's
go
ahead
with
it,
because
if
it,
if
it
helps
build
the
events,
then
then
well.
What
is
the
concern,
whether
it's
thin
layer
or
are?
Are
you
recommending
that
we
just
you
know,
use
the
log
API
to
build
events.
D
No
I,
don't
like
I
mean
in
in
my
opinion,
is
that
the
API
should
be
just
separate
completely
and
then
like
the
logs
logs,
there's
an
implementation
using
the
logs
SDK,
and
then
that
would
give
us
like
full
flexibility,
like
the
the
instrumentations,
only
rely
on
the
events
API.
You
know.
If
you
want
to
replace
the
implementation
of
it,
you
can
okay
like.
If,
if
you
don't
go
that
route
fine,
we
can
leave
it
in
the
logs
logs
API,
but
then
even
then,
I
feel
like
the
currently
the
way
it's
spec.
D
Well,
I
just
want
to
I
just
want
to
have
at
least
like
a
good
idea
of
the
direction,
because
because
once
we
once
we
have
it,
then
once
we
start
putting
it
into
instrumentations
right,
then
it's
going
to
be
harder
to
change.
Okay,.
B
No
I
think
I
think
that
statement
is,
is
incorrect,
right,
I
think
we,
we
cannot
expect
the
spec
to
Mark
anything
stable.
Yet
right,
you
know
this
is
evolving
and
I
expect
things
to
continue
to
like,
like
this
is
a
confusing
area,
so
there
will
be
changes
and-
and
we
have
to
go
with
it
and
in
fact
the
counter
argument
is
the
more
instrumentations
we
build
on
the
log
in
on
this
event,
API
will
have
more
yeah.
B
Yeah
so
I
I
think
in
my
opinion,
I
think.
The
event
API
is
is
the
is
the
smallest
of
the
you
know
open
concerns.
We
should
just
go
ahead
with
what
it
is.
I
think
the
the
bigger
push
we
need
to
make
on
is
the
the
data
model,
the
event
data
model
and
nav
wanted
event.data
for
the
payload
I
think
we
should
focus
on
that
and
and
bring
that
to
closure.
So.
D
C
D
Yes,
I
I
get
it
so
so
there
isn't.
There
is
an
open,
PR
right
now
that
has
that
you
know,
updates
the
updates.
The
current
state
of
the
events
API
in
this
in
the
job
in
JavaScript,
SDK
and
so
I'm,
just
gonna,
say:
let's
leave
it
for
now
because,
like
we're,
not
sure
that
the
spec,
the
spec
might
change
we're
not
sure
about
the
spec
right
now,
let's
just
leave
it
as
it
is,
but
let's
get
some
eyes
on
it
and
then
we
can
modify
it
later.
D
And
yeah.
B
Yeah
I'm,
even
okay,
with
the
you
know,
keeping
the
event
API
and
log
API
combined,
I
I
know
the
spec
has
split
it,
but
I
would
rather,
you
know,
focus
on
the
other
aspects
and
we
come
back
and
make
these
changes
later,
because
this
the
event
API
changes
are
going
to
be
straightforward.
D
Yeah,
okay
I
this
this
contributor,
that
that
has
the
pr
open
they
they
also
have
the
logs
SDK
implemented,
so
I
think
they're,
probably
waiting
for
feedback
from
from
us,
and
then
they
would
probably
the
next
step.
They
would
open
a
PR
with
the
logs
SDK
implementation,
so
I'm
gonna,
yeah,
I'm,
gonna
work
with
them
on
this
I
just
say
like:
let's
just
leave
the
API
as
it
is
for
now
and
move
that's
fine.
Okay,.
B
So
so
to
be
clear,
so
logs
SDK
also
you're,
saying
there
is
a
open
PR.
D
No
there's
not
but
I
know
that
they
have
implementation.
There
was
there,
was
they
I
think
they
opened
a
PR
at
some
point
and
they
closed
it
with
the
SDK,
because
they're
waiting
for
the
changes
in
the
API.
D
B
Do
you
know
what
those
changes
consisted
of
because
the
logs
SDK.
B
But,
but
will
did
it
have
or
is
there
a
plan
or
is
there
Clarity
on
what
all
changes
it
includes
like?
There
are
different
exporters
and
different
processors
that
it
will
have
to
have
right
like,
for
example,
the
the
HTTP
exporter,
the
protobuf
exporter,.
C
D
C
B
Current
protob
of
exporter,
PR
that
you
have
purvi
I,
think
that
is
only
for
spans
right
there's
only
for
the
yeah.
B
Yeah
so
I
believe
the
initial
version
of
the
logistic
cable
will
probably
export
in
the
Json
format.
I
I,
don't
know
I
think
so.
So,
basically,
my
point
is
I.
Think
we'll
need
a
plan
on
what
all
it
will
include.
B
D
B
D
D
And
yeah
there's
there's
the
other
issue
issue
that
that
they're
gonna,
open
I
haven't
actually
looked
at
it.
Yet
does
it
do
you
know
nav
if
it's
like
yeah.
B
I
I
think,
let's
not
worry
about
it.
I'll
I
think
I.
Think
the
problem
with
you
know
those
changes
is
that
the
spec
is
changing
faster
than
you
know
any
prototyping
we
could
do
right,
yeah,
so
I
think
we
should
focus
on
our
prototypes.
You
know
completing
you
know
the
work,
we're
doing
you
know
doing
one
full
iteration
and
then
come
back.
You
know
and
and
yeah
do
do
the
iterations
later
based
on
the
you
know,
the
changes
in
the
spec.
E
Yeah,
but
but
just
to
summarize
it
tigram
was
proposing
to
effectively
remove
the
logs
API
completely.
E
Both
Jack
and
myself
could
come
back
and
sort
of
said
it
it's
much
better
to
leave
it
there,
because
it
provides
some
decoupling
rather
than
any
like.
If
we
create
the
events
API,
we
would
have
to
link
it
to
a
fixed
version
of
the
logging
SDK
API,
which
then
would
cause
grief
put
the
damaging.
So
so,
hopefully
we
can
convince
Digger
to
keep
the
API
level.
Sorry
today.
D
So
if
I
know
that
in
the
past,
tigern
was
against
having
like
he
wanted
to
like
have
an
API
tied
to
a
signal.
So
would
this
be
an
API?
That's
essentially
not
tied
to
a
signal.
E
If
you
load
up
the
that
PR
he's
got
a
nice
little
diagram
at
the
top,
but
effectively
yeah,
it
would
be.
You'd
still
have
the
logging
API
so
that
you
know
any
any
API
like
the
the
event
API.
We
would
just
say
it
exists.
We
can
emit
events
and
then
the
implementation
of
that
event,
API
would
have
like
be
linked
to
I,
would
prefer
to
see
it
linked
to
the
logging
API.
C
B
So
I
I
think
it's
not
a
problem
for
us,
because
the
browser
instrumentations
only
need
an
events.
Api
an
auto
log,
API
and.
E
Yeah,
if
the
event
API
is
fixed
directly
to
the
to
an
SDK
version,
then
it
becomes
a
problem
because
then
you
start
saying:
oh
for
this
browser
version,
we've
got
event
API
X
in
the
app
which
once
log
sdkx,
but
someone's
using
log
sdky.
So
all
of
a
sudden
you've
uploaded
the
code.
So
that's
where
it
becomes
a
problem.
B
So
I
I
want
to
I
saw
that
dependency
comment
in
the
pr.
Do.
I
want
to
understand
that
so
when,
when
when
we,
when
the
instrumentations
produce
events,
it
is
the
job
of
the
SDK
to
do
the
processor
pipeline
right.
So
what?
Where
is
the
dependency
on
the
SDK
version
coming
in
like?
Why
would
the
log
API
the
event
API
depend
on
a
specific
version
of
the
SDK.
E
Well,
that's
what
tigrants
proposing
that
it
would
the
the
event
API
would
effectively
require
a
direct
link
to
the
logging
SDK.
So
while
there's
a
thin
layer
on
top
it
effectively
is
directly
linked
to
a
specific
version
of
the
logging
SDK,
because
there
was
no
logging
API
for
it
to
be
able
to
emit
log
events.
E
That's
really
with
the
fundamental
bit
where,
if
you
have
the
event,
API
and
an
event,
SDK
implementation
that
can
use
a
generic
thing
to
to
emit
log
events,
it
just
it
separates
them.
So
you
get
away
from
version
dependency
issues
which
is
really
where
the
problem
comes
in
it.
It
would
come
in.
You've
got
component
X
once
event
API,
which
needs
logging,
SDK,
Version
Y,
so
you've
got
that
thing
over
in
the
corner.
You've
got
an
application.
E
That's
using
you
know
open
Telemetry
version
a,
but
now
it
wants
to
remain
defense
and
you've
got
like
you
end
up
having
two
versions
of
the
logging
SDK
installed.
E
E
B
Yeah
I
think
you
know
sorry
for
this.
You
know
dumb
questions,
maybe
but
I
I
think
when,
when
why
I'm
still
not
clear
why
the
instrumentation
would
need
to
care
about
the
SDK
like
when
you
are
generating
the
events,
the
event
API
itself
would
be
generating
the
log
records.
E
B
E
B
B
B
E
But
there
still
needs
to
be
a
log
API
for
the
appender,
so
we'll
put
the
dependent
implementation
but
yeah,
but
to
do
what
you're
saying
it
effectively
is
the
SDK.
E
It
really
comes
down
from
a
package.json
perspective.
It
comes
down
to
what
can
you
put
in
the
peer
dependency
rather
than
rather
being
fixed?
You
can
say:
yeah
I
can
use
any
version
because
I'm
just
looking
at
the
API.
B
Okay,
okay,
yeah,
I
I
think
we
we
should
proceed
based
on
the
current
spec
and
and
then
we'll
come
back
to
the
changes
later.
I
still
strongly
feel
about
that.
E
Yeah
there's
still
the
open
issue
of
the
nested
attribute
support
in
JavaScript.
So
that's
that's
still
going
to
be
implemented
because
it's
not
there
yet
based
on
using
event
data
like
event,
data
is
a
nested
attribute,
but
you
can't
actually
Define
an
attribute
as
a
as
having
a
nested
attribute
today.
So
we'd
have
to
either
introduce
a
log
attribute,
which
explicitly
has
that
like
we
did
originally
for
the
span
attribute
and
then,
if
tigrants
PR
goes
through,
it
can
be
folded
back
and
become
an
alias
like
we've
got
for
a
span
attribute
now.
B
E
Can
be
defined
as
an
attribute
as
an
attribute?
Yes,
whether
the
exporters
support
that
that
would
be
a
different
thing,
but
yeah
from
our
perspective,
we
can
say
an
attribute
as
an
attribute,
so
we
can
Define
it
once
and
just
use
it.
B
Okay
and
and
then
for
the
logs
exporter
that
we
will
be
creating
now
I
think
that
can
happen.
Yeah.
E
Okay,
so
what
the
only
issue
being
the
format
this
option
to,
as
we
talked
about
yesterday
because
of
the
adjacent
that
gets
generated.
B
So
his
fear
I
know
it
has
only
it
has
one
approval,
but
in
in
general
it
it
needs
more
approvals
right
yeah
from
the
spec
I.
E
This
issue
has
been
open
for
a
very
long
time
and
with
people
running
out
just
understand
and
come
around
to
this
way
of
thinking.
E
E
So
yeah
so
I
guess
that
that
means
in
terms
of
the
log
SDK
implementation,
we'll
just
have
to
introduce
a
log
attribute
at
this
point
in
time
into
the
JavaScript
SDK
JavaScript
implementation
card,
so
that
we
can
have
this
attributes.
E
I
think
we
go
ahead
with
it
anyway,
so
we
can
get
our
prototypes
going.
You
know
we
just
need
to.
E
That's
what
I'm
proposing,
as
we
say
it's
taking
too
long
to
get
this
other
stuff
through,
let's
just
go
and
Implement
a
log
attribute
which
supports
necessary
attributes
and
start
building
with
that,
a
bit
like
we're,
saying
we're
not
going
to
worry
about
the
making
it
conform
to
the
the
way
the
spec
is
for
the
log
API.
E
Now,
let's
just
go
ahead
and
make
it
work,
and
then
we
can
come
back
and
refactor
all
because
yeah
we're
playing
in
the
experimental
space
here
and
as
long
as
we're
explicit
that
you
know
this,
will
this
is
very
likely
to
change
so
therefore
you're
very
lucky
to
get
broken.
If
you
take
a
production
dependency
on
this.
B
But
I
think
the
attribute
is
defined
in
the
core
package.
E
For
now,
once
yeah
assuming
the
change
goes
through,
then
we
can
go
back
to
the
core
package
and
change
that
and
say
well.
Okay,
as
of
you
know,
the
logging
will
then
require
the
core
version.
Excellent.
You
know
whatever
version
we're
up
to
at
that
point
in
time
or
if
you
look
at
the
span
attribute
it
effectively
morphed
and
became
an
alias
2
attribute.
So
if
you
look
at
the
span,
attribute
definition
now,
I
think
just
as
type
span
attribute
equals
attribute.
B
Some
Martin
do
you
have
Clarity
on
how
to
do
this.
D
I
think
so:
yeah,
okay,.
E
D
B
I
get
that
part
but
which
package
it
goes
to
I.
Think
that
I'm
not
super
clear
yeah.
E
B
So
there
is
an
API
logs,
that's
being
introduced
now.
E
C
C
B
I
think
Martin
I
think
the
he
now
would
be
to
sync
up
with
this
other
person,
who's
working
on
the
implementation.
B
Mean
to
avoid
two
implementations
I
think
it
will
be
good
to
chat
with
this
person
yeah
somewhere
I.
C
B
Yeah
more
more
than
that
I
think
we
need
to
be
in
sync,
so
it
will
be
good
if
they
like
would
talk
to
each
other.
B
Okay
and
next
thing
you
have
the
event.data
like.
E
Well,
it
got
closed,
so
I
need
someone
to
be
able
to
open
it.
Sorry
I
was
going
to
bring
it
up
in
the
log
Sig
we
got
close
due
to
inactivity,
so
I
need
to
either
get
it
reopened
or
go
create
another
one.
E
Was
the
spec
one
yeah
defined
as
the
shape
of
the
Ventana.
E
C
D
Since
we're
talking
about
the
seven
data-
and
we
talked
about
the
events
API,
do
you
think
like
do
you
think
there
should
be
in
the
API
some
way
like
to
set
the
data
or,
like
some
convenience
method,
to
methods
to
set
the
data?
Because
otherwise-
and
you
know
otherwise-
there's
actually
not
it's
not
in
the
API
right
now.
So
you
would
need
to
just
set
it
manually
as
an
attribute
so,
and
you
know
we're
having
we're
thinking
about
at
least
having
some
way
of
setting
the
name,
the
event
name.
E
So,
in
terms
of
the
event
API
I
would
expect
Simplicity.
It
should
come
down
to
three
things.
We
should
have
the
name,
the
data
which
would
just
be
effective
in
attribute,
which
already
contains
all
the
you
know,
which
ends
up
being
assigned
to
event.data,
yeah
and
then
optional
additional
attributes.
E
Think
if
we
say
the
attribute
is
really
the
event
data
to
try
and
highlight
the
fact
that
all
the
attributes
for
an
event
generally
go
in
into
event
data,
because
that's
where
most
of
our
events
would
would
be
I
think
would
be
the
way
to
go,
and
that
way
just
automatically
assigned
it
to
event.data
for
us,
but
that
there
are
going
to
be
events
that
have
other
attributes
at
the
top
level,
so
that
we
still
need
that
capability
too.
B
That
will
need
a
change
to
the
API
spec
nav,
because
currently
the
spec
says
the
the
attributes
that
the
API
takes.
You
know
they
go
as
the
log
record
attributes
so.
E
It
can
be
implemented
as
a
convenient
function
like
that
then
uses
that
API.
So
you
could
say,
you
know,
have
a
helper
function.
That
says,
create
create
me
an
event
and
it
returns
you
back.
You
know
internally,
it
uses
the
existing
event
API
to
populate
it.
B
No
but
I
I
think
it.
It
also
needs
to
go
into
the
spec
right,
because
you
want
other
implementations
of
the
events
to
also
put
all
the
payload
into
the
event.data.
Not
just
our
use
cases.
E
Eventually,
yes,
but
in
terms
of
getting
something
going,
we
have
this
as
a
convenience
method
for
now
and
one
but
yeah
I
figured
we
can
trial
and
say
how
do
we
want
to
want
to
create
this
event
package?
Do
we
want
to
be
able
to
say
you
know
here?
Is
the
data
go,
go
and
assign
it
or
do
we
want
to
force
them,
as
the
API
does
today
to
say,
You
must
specify
an
attribute
called
event.data
and
it
must
contain
this
either
way
it
works.
E
It's
just
what's
the
easiest
and
you
know
a
helpful
functional
convenience
method
as
they'd
like
to
call
them
is
a
way
to
do
that,
and
if
we
find
that
that
works
best
for
us,
then
we
can
go
on
update
the
spec
and
say:
let's
do
it
this
way?
Well,
let's
extend
the
API
to
also
do
it.
This
way.
D
And
I've
buy
a
gun
by
convenience
method.
Do
you
mean
just
like
in
the
event
logger
having
the
log
event
method,
take
event
data
as
an
argument.
E
And
you
know,
then,
the
the
event
data
argument
is
just
an
attribute
or
I'm.
Sorry,
a
log
attribute,
because
it's
just
a
effectively
or
we
could
say
it's
an
attribute
and
then
internally
it
assigned
as
a
log
attribute
and
then
we
don't
actually
have
to
expose
or
get
repeat
because
it's
another
way
to
go.
E
And
that
way
the
log
attribute
the
nested
attribute
implementation
can
be
hidden
inside
of
the
of
the
SDK
portion
of
it.
If
you
like.
E
Because
yeah,
if,
if
you
have
it
today
like,
if
you
just
think
from
a
minification
perspective,
how
much
boilerplate
code
you
have
to
generate
to
always
populate
event.data,
if
every
event
is
going
to
say,
oh
and
assigned
event,
dot
data
sign
event.dated
to
this,
the
convenience
method
just
helps
remove
that
amount
of
repeated
code.
D
B
Martin,
could
you
track
this
change.
D
Yeah
yeah
I
can
yeah
I
can
I
can
open
a
PR
with
the
edition
of
the
log
data
event
data.
You
know.
D
Yeah
so
I
think
I
think
for
now,
I
have
better
Clarity
I'll,
just
I'll
just
push
back
on
on
that
changing
the
events
API
for
now,
because
we're
you
know,
there's
still
discussions
about
it
right
now,
so
we
can
move
forward
with
the
SDK.
B
A
I
have
a
question
if
it's
a
good
time,
I
work
for
a
specto.
We
are
at
racing
vendor
and
we
have
a
lot
of
experience
with
the
traces
from
servos
and
we
want
to
research
and
be
prepared
to
get
the
spends
also
for
clients.
So
I
started
to
play
with
it.
A
bit
started
with
the
Android
and
I
couldn't
find
any
resources
about
like
resource
detectors
or
the
semantic
conventions
for
Android
the
instrumentation
libraries
for
Android
and
I'm
curious.
E
So
we've
mainly
been
focusing
on
browser
stuff
at
this
point,
but
yeah
this
would
be
the
group
that
would
help
Define
those
semantic
conventions
as
part
of
our
event,
definition
that
we've
been
trying
to
Define
them.
As
generic
as
I
said,
we
haven't
actually
had
the
feedback
or
as
much
feedback
as
we
would
have
liked
from
mobile
Developers.
B
So,
but
for
Android
I
also
know
that
there
will
be
an
official
Android
instrumentation
soon
that
will
be
contributed
by
the
Splunk
team.
B
They
have
it
in
there
organization,
GitHub
organization
today,
which
they
are
working
on
to
to
you,
know
separate
out
the
Splunk
specific
code
and
then
contribute
the
generic
Android
instrumentations
to
the
open,
Telemetry
organization
and
I
think
they
had
said
that
they
would
do
it
by
end
of
Jan,
after
which
I'm
hoping
that
will
have
a
that,
will
get
a
bigger
visibility
and
more
discussions
in
the
open
and
and
and
then
we
can
do
our
discussions
based
on
that
report.
B
A
Bit
with
the
Splunk
report
and
I
saw
that
it
took
specifically
for
Splunk
that
the
user
cannot
just
use
it
and
send
the
data
to
any
vendor.
We
want
so
it's
good
news
that
they're
going
to
to
move
it
to
the.
B
I
mean
yeah
I
mean
in
general.
Yes,
like
once
the
basic
code
is
there,
then
the
resource
detectors?
If,
if
you
want
to
add
any
additional
resource
attributes-
and
it
doesn't
already
exist,
you
know
you
I'm,
assuming
that
you
should
be
able
to
add
it.
A
With
those
like
something
with
the
iOS,
like,
oh.
B
Ios
there
is
already
a
swift
implementation.
You
can
look
at
the
there's,
a
report
called
open,
Telemetry
Swift
and
this
Swift
team
meets
Thursdays.
9
am
so
tomorrow
you
can
join
the
their
Sig
and
then
you
can
discuss
okay.
C
D
A
Yeah
I'm,
not
into
all
the
details
about
all
the
problems
I
just
started
investigating
a
week
ago,
I
read
the
old
document.
You
know
it's
just
a
curious.
What
the
state
the
current
state
and
the
future
plans
are,
so
it
helps
that
the
Splunk
will
move
the
code
into
open
television.
B
Okay,
we
can
end
here.
E
Oh
cool,
so
I
assume
you
we're
all
going
to
go.
What
percentage,
maybe
I'm
going
to
go
to
the
log
Sig
as
well.
I
haven't
seen
any
response
from
pigment
on
that
PR
for
a
while
sorry,
I,
don't
know
if
you're
gonna
be
there,
but
let's
give
it
a
go.