►
From YouTube: 2020-09-24 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
I
saw
another
flurry
of
activity
last
night,
looking
through
just
looking
through
the
emails.
A
On
just
stuff,
in
the
instrumentation
repo
work
work
going
on.
A
It
seems
like
most
currently
most
of
our
most
of
our
contributors
are
in
europe.
C
A
A
A
A
A
We
closed
one,
we
opened
one
so
we're
still
at
ten.
The
the
one
we
closed
will
get
was
a
really
nice
muzzle
improvement
which
had
broken
in
one
of
our
releases.
Did
we
release
it
nikita
with
the
broken
servlet
output
stream?
Or
did
we
catch
that
before
the
release?
No,
we
released
that.
I
don't
remember.
A
Yeah
anyway,
we
had.
We
had
written
a
sub
class
we'd
made
a
subclass
of
servlet
output
stream
to
count
the
bytes
that
were
sent
so
that
we
could
capture
the
content,
links
semantic
convention.
A
Normally,
we
also
run
tests
against
the
latest,
so
now
I'm
confused
why
we
didn't
catch
that,
but
muzzle
definitely
didn't
catch
that
because
muzzle
keeps
track
of
all
the
methods
that
we
call
and
make
sure
that
those
methods
are
available
at
runtime
before
it
applies
the
instrumentation
that
uses
those
methods.
A
So
if
we
extend
an
elastic
search
class
or
a
servlet
output
stream,
a
servlet
class,
it
was
not
looking
at
runtime
to
make
sure
that
that
super
class
didn't
introduce
any
new
abstract
methods
that
we
haven't
implemented,
and
so
now
it
does
that
and
it
won't
apply
the
instrumentation.
If
there's
new,
abstract
methods
that
we
haven't
implemented.
A
A
A
Using
the
underlying
library
like
compiling
stuff
directly
against
the
code
versus
that
the
user's
code
is
using
versus
trying
to
you,
know,
fight
code
instrument
that
at
runtime.
A
B
F
A
I
think
last
week
we
went
over
the
p1
issues,
so
I
don't
think
we
need
to
do
that.
The
only
the
only
new
one
is
just
a
simple
one.
I
just
made
it
p1
to
make
sure
that
it
happens.
Is
the
environment
variable
names,
several
environment
variable
names
are
changing
upstream
in
the
spec
and
in
the
java
repo.
A
So
once
we
pull
in
this
the
latest
snapshot
or
yeah,
we
tend
to
try
to
keep
the
main
readme
up
to
date,
with
the
latest
release
that
we've
made
so
like
in
this
case
for
updating
the
environment
variable
names.
G
So,
since
these
properties
are
same
as
across
languages,
wouldn't
it
better
to
just
reference
a
spec
or
have
a
website
and
just
reference
the
website.
We
had
exactly
the
similar
problem
in
jager
clients,
and
so
we
ended
up
just
documenting
everything
on
the
website
and
then
from
the
clients
we
referenced
it.
The
website.
G
A
G
G
G
A
Default
yeah,
so
I
think
we
do
list
the
defaults,
but
yes,
we
also
don't
stock
the
the
all
those
batch
span
process.
Oh
no,
we
do
here,
okay,
yeah.
These
will
be
great.
Maybe
we
should
even
look
at
that
sooner.
A
If
we
could
reference
a
tag
if
we're
up
to
date,
I
think
we
rely
on
most
of
these
to
be
implemented
in
the
sdk,
so
we
would
want
to
check
if
all
of
these
are
supported
in
the
java
sdk.
D
G
D
A
Do
we
have
anything?
Do
you
know
if
we
have
anything
in
the
sdk?
That's
not
in
the
java
repo.
I
mean
sorry
anything
in
the
sdk.
That's
not
in
the
spec.
B
B
Not
right
now,
currently
there
is
proposal
to
document
or
to
to
make
it
to
document
the
configurability
of
all
other
properties
like
on
the
screen,
but
that's
not
the
attribute
lengths
yet
but
probably
should
be
put
into
spec
of
volume.
A
So
we
could
dock
things
not
inspect
separately.
B
Topics
we
need
more
topics,
I
have
a
question,
so
I
just
wanted
a
a
confirmation.
Can
we
now
use
java
8,
specific
apis
and
features
in
agent.
A
In
definitely
in
oh
yeah,
we
can
we
can
because
the
sdk
is
bumped
now.
So
we
can't
even
support
java
7
our
our
original
plan
of
having
some
manual
instrumentation,
maybe
for
java
7
on
android
yeah,
because.
B
A
So
we
can
have
the
de-sugaring,
the
android
de-sugaring
that
wasn't
needed
so
yeah
can
we
do.
F
A
G
Yeah
or
some
things
like
the
instrumentation,
I
let's
say,
add
something
to
an
instrumentation,
for
I
don't
know
jdbc,
and
I
would
like
to
try
it
out
on
my
simple
app
or
I
modify
something
in
the
agent
core
classes.
I'm
still
new
to
this
agent,
so
bear
with
me.
I
don't
have
maybe
the
right
terms.
Yeah.
A
A
G
B
B
C
B
A
A
So
yes,
I
I
agree
this
this
that
matches
my
workflow
also
for
instrumentation
is
I
pretty
much
do
exclusively
for
instrumentation
work
testing
using
the
tests
and
debugging
in
intellij
and
then
yeah.
This
is
a
great
caveat
that
about
the
breakpoints
for
the
initialization
stuff,
though
well.
F
With
regards
to
the
breakpoints,
that's
where
it's
really
helpful
to
have
the
bulk
of
the
logic
inside
of
like
the
helper
classes
like
in
the
pieces?
Yes
like
in
new.
B
F
D
So
fyi
fyi
thread.dump
stack
does
exactly
what
the
line
above
does
in
your
in
the
document
there.
All
it
does
is
stack
all.
D
A
Yeah,
I
know
this
is
a
great
point
and
yeah
one
thing
with
the
the
decorators
had
the
same
benefit
the
as
we've
been
with
the
new
tracers.
It
has
been
reducing
the
amount
of
code
still
in
the
on
method
enter
and
on
method
exit,
but
we
still
do
sometimes
need
logic
there.
So
it's
it's
a
good
reminder
for
us
to
where
possible,
push
that
logic
into
the
tracers.
A
For
initialization
stuff,
this
is
what
I
do.
This
is
when
I
need
to.
This
is
the
time
when
I
need
to
compile
the
agent
and
honestly
the
initialization
stuff,
so
I
don't
know.
Does
anybody
from
my
recollection?
A
D
A
A
F
F
F
A
Is
that
different?
I
wonder.
F
I
don't
know
why
it's
different,
but
there
seems
to
be
a
difference
in
behavior,
perhaps
because
the
debugger
like
intellij
is
able
to
attach
before
the
pre-main
starts
up.
D
If
you're,
starting
that
remote
process
with
the
whatever
the
weight
equals
true
or
I
don't
know
what
the
flag
is,
it
literally
does
nothing
before
it
starts
up.
I'm
sure
I'm
almost
positive
of
that
suspend
equals
y.
That
right
there.
A
Yeah
yeah-
I
don't
know
why,
like
this
is
ringing
a
bell
that
this
has
not
worked
for
me
in
the
past,
but
I
could
be
completely.
D
A
That
as
an
open
question
I
will,
I
will
try
it
out
because
I
want,
I
bet,
I'm
dying
to
know
now.
Does
action
item
I
will.
I
will
report
back
next
week,
does
debugger
attach
early
enough
for
pre-main,
because
I
also
meant.
I
also
said
that
on
the
issue,
the
issue
that
pavel
opened-
I
mentioned
that
last
last
night,
so
I
want
to
correct
that
issue.
My
statement
on
that
issue.
If
it's
not
correct.
G
A
Code,
currently,
the
the
tests
don't
run
like
with
the
full
java
agent.
So
it's
that's
something
that
we're
thinking
of
that
we'd
like
to
do.
A
We
have
an
issue
for
it:
yeah
using
a
real
java
agent,
that
it
would
potentially
give
us
a
few
benefits
and
that
that
actually
could
be
one
as
it
would
go
through
our
full
initialization
routine,
as
it
is.
A
If
you
look
in
the
agent
testrunner
class
that
all
of
the
tests
extend
from
you'll,
see
we're
doing
this
bite
buddy
dynamic,
attach
where
it
and
we
start
it
sort
of
has
it
goes
through
some
of
the
initialization
code,
but
not
the
stand,
not
all
of
it
and
not
the
standard
route.
So
no,
no
guarantees
there.
A
I'd,
say
the
for,
like
the
exporter
stuff
that
you
were
doing,
I
would,
I
think
this
you'll
you
would
need
a
at
least
that's.
My
current
workflow
is
build
the
full
java
agent
and
test
with
spring
pet.
A
A
Yes,
yes,
we
have
yes
in
the
contributing
doc.
That
would
be
great.
I
don't
we
don't
have
any
section
about
debugging.
A
A
A
Hotel
propagator
did
carla
is
carla.
Carlos
is
here
hey
carlos,
like
this
looks
like.
H
Carlos
added,
yes,
totally
yeah,
I
just
wanted
to
let
you
know
trask,
especially
trust
production
and
the
rest
of
the
maintainers.
This
is
a
very
small
iteration
and
specification
for
defining
what
was
left
of
this.
What
is
left
of
this
so
please
approve,
we
don't
have
to
do
it
here.
It's
super
simple,
but
still
we
need
your
your
input.
H
Is
there
something
that
should
be
removed
or
added,
even
if
it's
small
or
whatever
just
let
me
know,
hopefully,
because
my
plan
is
to
have
all
the
big
things
to
be
merged
by
the
end
of
the
day
tomorrow,
and
this
is
one
of
the
one
of
the
important
items
that
we
were
still
missing,
even
after
what
they
were
related
vrs.
Yes,.
A
Yeah,
so
could
you
just
talk
kind
of
high
level?
What
I
mean
I
saw
this,
but
it
didn't.
It
seemed
mainly
just
like
wording,
clarification
of
things
I
didn't
see
any
real
change
to
behavior.
H
Yeah,
I
think
that
the
changes
the
most
of
the
actual
required
changes
for
closing
this
ticket
were
in
two
pr's.
One
of
them
was
for
specifying
how
b3
should
behave
in
general.
The
other
one
is
just
for
listing
the
actual
canonical
names
for
for
for
the
propagation
formats.
That's
about
it.
H
A
Okay,
I
had,
I
think,
the
the
I'd
seen
ot
tracer
for
that
open.
This
is
the
open
tracing
one
right.
A
A
We're
supporting
that
in
the
java
agent
we
support
x-ray
here
and
ot,
so
it
would
be
nice.
H
If
I
don't
know
what
yeah
well,
the
situation
is
in
the
specification,
sorry
for
interrupting
I'm
just
very.
I
had
too
much
copy
today.
H
Not
the
specification
basically
mentioned
that
aws
or
open
tracing
and
other
external
formats
must
be
in
their
own
repos,
so
we
will
moving
them
out
of
open
telemetry
java
and
then
after
that-
and
this
is
why
I'm
not
listing
them
in
today,
well-known
formats
and
then
after
this,
it's
up
to
the
instrumentation
to
decide
if
they
want
to
import
these
packages
with
these
external
propagators,
which
is
perfectly
possible.
It's
up
to
you.
A
Okay
got
it.
Do
we
document,
oh
yeah
yeah,
so
we
do
okay,
so.
A
Support
baggage,
but
these
were
the
these
seemed
like
the
names
that
they
gave,
but
yeah
makes
sense
to
me.
H
I
will
update
the
names.
One
of
the
things
is
that,
even
though
we
have
b3
and
b3
single
going
forward,
we
will
only
require
v3,
which
would
be
a
propagator
which
will
do
to
extract
both
formats,
but
that
has
to
happen.
You
know
java.
First,
it's
just.
A
A
A
A
All
right:
well,
I'm
I
will
go
through
the
the
weekly
digest
and
then,
if
anybody
thinks
of
anything
in
the
meantime,
we
can
circle
back.
A
So
we've
got.
We
support
multiple
exporters.
Now
so
otlp
exporter,
environment
variable
you
can
specify
you
can
send
your
data
to
both
zipkin
and
jager.
If
you
like,
that
will
be
come
more
useful
once
we
support
prometheus,
since
that
was
kind
of
the
seems
like
the
main
use
case
is
oh,
I
want
to
send
my
spans
to
zipkin,
but
I
want
to
send
my
metrics
to
prometheus.
A
More
work
on
decorators
to
tracers
to
the
new
tracer
hierarchy.
So
all
the
database
client
decorators-
I
don't
know
nikita-
have
you
looked
at
what?
Because
so
we've
done
now.
Http
client,
http
servers,
databases.
B
B
Nice,
so
the
the
I
would
like
to
review
all
of
them
and
to
review
how
they
correspond
to
semantic
convention
by
next
tuesday,
where
my
internal
sprint
ends,
because
I
have
tuscany
in
jira.
But
I
will.
I
don't
know
if
I,
if,
if
I
will
manage
that,
but
that's
the
problem.
A
Cool
yeah,
let's
skip
down
to
these
two
nikita
nikita,
has
been
going
through
all
of
the
different
span
types
one
by
one
and
making
sure
that
we're
conforming
with
the
semantic
conventions.
A
So
that's
really
nice
and
a
lot
of
work.
We
removed
java
7
support.
So
yes,
it's!
It's
all
official.
The
sdk
is
now
on
java
8
we're
on
java
8
moving
forwards.
A
Oh
the
smoke
test
for
log
back,
so
the
log
back
because
of
slf
for
j,
because
log
back
uses
slf
for
j
and
we
shade
we
use
slf
for
j
shaded
internally,
we
do
some
shading,
it's
easy
for
our
shading
to
mess
up
the
log
back
instrumentation,
but
the
log
back
instrumentation
itself.
A
A
A
Now
the
apps
we
spin
up
docker
containers
and
the
app
is
inside
of
the
docker
container,
and
that
way
we
can
run
against
different
java
versions
in
the
docker
container
and
the
the
otlp
those
the
egg.
We
use.
The
otlp
exporter
to
send
the
results
back
to
the
test
that
kicked
it
off
and
then
it
can
verify
the
results
that
way.
A
Yeah,
so
it
it,
it
creates
a
grpc
service
right
using
the
same
protobuf
definitions
that
the
collector
uses.
But
then
it's
just
a
real
simple
in-memory
collector
right
that
then
the
tests
can
use
to
verify
data.
B
File
we
we
used
to
have
the
full-blown
collector
in
in
small
tests,
but
then
we
hit
an
issue
between
different
versions,
released,
unreleased
versions
of
collector
and
code,
blah
blah
blah,
and
so
now
we
have
just
a
fake
back
end
which
talks
your
pc,
but
that's
it.
So
if
we
still
have
some
yeah
that
one.
A
Yeah,
so
it's
just
a
real
simple:
you
know
it
receives
the
the
data,
the
otlp
data
stores
it
locally
and
then
the
tests
can
get
that
and
verify
with
the
results.
A
There
we
go
instrumentation
for
aws
lambda,
so
anurag
has
been
doing
work
for
assigned
to
me
sure
google's
too
smart
for
aws
lambda,
I'm
adding
instrumentation
for
that
support,
and
I
think
we
talked
about
it
last
week
a
little
bit
the
problems
of
functions
as
a
service
and
instrumentation,
but
they
are
trying
to
tackle
that
as
far
as
how
that
it
would
work
for
over
both
the
overhead,
since
you
have
to
spin
it
up
just
to
handle
a
single
request-
that's
incoming,
for
example,
and
then
also
the
flushing
at
the
end,
having
to
do
that
essentially
synchronously
at
the
end
of
the
request,
because
at
the
end
of
the
request
the
vm
gets
frozen
so
we'll
be
interesting
to
find
out,
follow
how
that
goes
in
the
future,
mdc
instrumentation
for
log4j2.
A
So
this
is
the
same
where
now
we
inject.
So
if
customers
are
using
for
j
two
and
they
have
their
configuration
their
out
their
configuration,
they
can
encode
use
those
mdc
properties
for
trace
id
span
id,
and
I
think
it's
trace
flags,
so
they
can
encode
those
into
their
logs
so
that
they
can
get
correlation,
and
I
know
a
lot
of
a
lot
of
vendors
support
ingesting
these
logs
and
autocorrelating
them.
I
imagine
both
splunk
and
datadog.
A
A
I
know
datadog
was
using
the
mdc
stuff
previously.
F
A
A
Okay,
so
the
the
way
that
it's
implemented
now
doesn't
use
a
scope
listener.
It
instruments,
basically
the
append
method,
so
the
the
internal
like
log
for
j
append
and
it
takes
like
a
log
event
and
then
we
wrap.
We
add
the
mdc
properties
at
that
point
to
that
log
event,
so
that
then
it
can
get.
F
Logged
out
so
aren't
those
la
aren't
those
mdcs
a
copy
on
right
thing,
though
so,
if
they're
doing
very
heavy
logging,
won't
that
cause
pretty
significant
overhead.
A
A
F
A
This
one
we
talked
about
the
muzzle
this
was
very
fun
and
time-consuming
to
review.
I
can
only
imagine
how
fun
and
time-consuming
it
was
to
implement
so
good
work
mateosh.
I
know
he's
not
on
the
cot
today
and.
A
Yes,
so
muzzle
is
so
the
problem
that
muzzle
is
trying
to
solve
is
in
our
instrumentation.
We
call
like
say:
apache,
http,
client
instrumentation.
Let's
pull
one
up
to
make
it
concrete.
A
So
let's
look
at
this
instrumentation
here
and
so
the
instrumentation.
This
one
is
way
too.
Just
let's
go
to
google
http
client.
That
one
is.
A
Smaller
so
we're
instrumenting,
http
request
and
instrumenting
exec
method
and
on
method
enter.
So
we
take
in
this
the
actual
google,
http,
client,
http
request
and.
A
We
call
start
spam.
Is
this
gonna
work?
Oh
my
on
that?
Oh
here's,
an
example
request
get
headers
so
say
we
apply
this
instrumentation
say
google
releases
a
new
version
of
google
http
client
and
they
remove
the
get
headers
method.
A
Then,
if
we
apply
this
instrumentation,
then
it's
going
to
come
in
here.
We're
going
to
call
get
headers
get
headers
is
not
going
to
exist
and
so
they're
going
to
get
an
abstract
method.
Error.
A
So
what
muzzle
does
for
us
is
it's
both
a
there's
two,
it's
a
two-pronged
approach.
Two
phases
to
muzzle
one
is
at
compile
time.
We
have
a
gradle
plug-in
that
goes
through
analyzes,
all
of
the
methods
that
we
rely
on
that
we
call
from
these
basically
from
anything,
that's
not
our
own
code.
If
it's
our
own
code,
we're
like
we
can
rely
on
that
being
present,
so
it'll
make
this
list
of
all
the
methods
that
we
call.
B
A
Or
just
just
any
classes,
it
starts
at
the
advices
and
then
recursively
drills
in,
like
so
tracer.
So
here
we
call
tracer
start
span.
A
So
if
we
go
up
to
the
tracer
here,
it'll
go
into
start.
A
Oh
that's
in
the
base,
so
it'll
go
into
start
span,
which
you
know
keeps
going
and
eventually
it
keeps
it
keeps
going,
and
so
that'll
eventually
call
like
these
abstract
methods,
which
then
link
back
up
to
these
methods
here,
like
status,
so
get
status
code
will
be
muzzle,
will
see
that
we
also
use
get
status
code
inside
of
that
instrumentation.
A
And
so
it'll
make
that
list
of
all
those
things
at
compile
time
and
it'll
stuff
those
into
this
instrumentation
class
in
a
new
method,
it'll
bytecode
instrument,
this
class
add
a
new
method
called
muzzle
matcher
get
muzzle
matcher,
and
actually
I
just
put
in
because
matej
and
I
were
kind
of
chatting
about
this-
muzzle
check
optimization.
So
it's
kind
of
cool.
A
If
you
decompile,
you
can
see
what
this
get
instrumentation
muzzle
method
looks
like
and
it's
kind
of
enormous,
and
so
this
issue
mateosh
and
I
are
chatting
about
ways
that
we
could
maybe
optimize
this
or
reduce
this
a
little
bit.
A
But
basically
it
builds
up
these
huge
matchers
that
then
are
used
at
runtime
to
verify
that
the
when
it
tries
to
apply
this
class
so
say
we
match.
Okay,
we're
like
oh
okay.
We
match
this
type.
A
The
user
brought
http
request,
but
this
http
request
doesn't
satisfy
the
muzzle
constraints
because
they're
using
a
newer
google
library
that
doesn't
have
get
headers
anymore,
maybe
they
decided
to
you
know
migrate
away
from
the
getters
right
and
they
just
renamed
it
to
be
headers
and
then
so
muzzle
will
see
that
it
doesn't
match
and
it
won't
apply
this
instrumentation
at
all,
which
is
you
know,
not
awesome,
because
the
customer
is
not
going
to
get
telemetry
from
the
google
http
client,
but
it's
a
lot
better
than
breaking
their
app.
G
A
In
the
type
matcher-
oh
yeah,
so
this
first
of
all
it
just
says
this
is
sort
of
the,
because
the
muzzle
matching
is
very
is
much
more
expensive
because
it
goes
through.
You
know
you
can
see
how
long
some
of
them
are
here.
A
So
we
do
the
the
type
matcher
first
to
make
sure
that
we
find
something
that
we
want
to
instrument,
and
then
we
apply
that
whole
muzzle
matcher
and
the
muzzle
matcher
really
goes
against
the
class
loader
that
the
user,
that
the
type
is
part
of
that
that
we're
considering
to
instrument
because
they
could
have
write
different
versions
of
google
http
client
inside
of
different
class
loaders.
A
So
the
muzzle
matcher
will
then
check
that,
for
example.
So
this
is
something
partly
why
I
opened
this
issue,
because
we
don't
really
need
to
verify
that
this
type
is
present,
because
this
is
our
type.
But
if
we
find
something
here,
it's
verifying
that
this
exists,
that
this
class
exists
and
it's.
F
Public
there's
actually
a
print
references
task
on
gradle
that
you
can
see
all
of
the
references
for
a
particular
module.
F
You
gradle.
A
G
G
A
Yeah,
so
it's
bite
buddy
will
protect
against
the
the
type.
What
we're
inject
like,
what
we're
expecting
to
pass
in
to
the
advice,
because
that's
where
it
is
that's
part
of
its
matching
routine
and
same
here,
ensuring
that
we're
actually
getting
this
type.
G
A
Yeah
yeah,
so
this
came
from
datadog
from
I
don't
know
you
said
tyler
at
you.
It
has
been
there
for
a
long
time.
It
was
in
the
early
early
days.
F
Yeah,
it
was
something
that
we
developed
very
early
on
as
a
way
of
like
being
able
to
support
multiple
different
versions
of
a
particular
instrument,
a
particular
library.
G
A
Yeah,
that's
a
really
good
point.
Is
that,
since
that
the
muzzle
will
then
automatically
right
it'll
if
the
user
has
netty
4.0
on
their
class
path,
it's
going
muzzle
is
going
to
notice
that
okay.
D
A
The
4.0
methods
that
we
rely
on
because
there
was
major
breakage
right
between
especially
I
mean
the
three
eight
used
a
whole
different
package
name,
so
that
was
easy,
but
everybody
struggles
with
instrumenting
neti,
4-0
versus
4-1,
because
they're
sort
of
similar
but
there's
some
important
api,
breakages
and
so
muzzle-
will
automatically
detect
that
and
it'll
suppress
the
wrong
one
that
doesn't
match
the
apis
that
we
use
in
our
instrumentation
and
use
the
right
ones,
and
this
way
so
like
in
glow
root.
A
A
A
Oh
yeah
jason,
the
the
youtube.
I
I
finally
got
the
youtube.
Video
never
made
it
to
youtube,
but
I
I
I
harassed
people
and
they
found
it
and
they
uploaded
it.
So
I
have
it
queued
up
to
watch
now.
I
know
you
were
dying
to
be
a
youtube
star.
A
Awesome
we
are
at
five
minutes
till
so
any
last
words,
questions,
thoughts.
D
Don't
forget
six
six
pm
pacific
time
tonight
is
the
meet
up
with
anarag
and
zoe,
and
anyone
else
who
wants
to
join
us
from
the
other
side
of
the
world.
D
The
zooming
for
the
6pm
should
be
fine.
That
was
the
yesterday
mornings.
I
think
carlos
was
going
to
update
that.
E
A
A
A
One
of
them
is
tuesday,
10
pm,
pacific
and
the
other
is
thursday.
6
pm
pacific
so
definitely
encourage
anybody
who
wants
to
join
this
one
tends
to
be
more
of
a
recap
of
the
existing
of
the
meetings
that
we
have
now
on
wednesday
and
thursday
across
those
six,
and
this
one
tends
to
be
topics
more,
like
a
maybe
more
like
a
traditional
sig
meeting,
where
we
have
topics
and
we
discuss
and
try
to
resolve
stuff
and
everybody's
welcome
to
all
of
them.