►
From YouTube: Kubernetes SIG Release - 2019-06-04
Description
A
A
All
right,
I'm
gonna
go
ahead
and
get
started,
there's
one
person
who
dropped
something
on
the
agenda,
who
is
not
on
yet
and
may
not
be
I'm,
not
sure,
since
it's
late
their
time.
So
we
will
kick
things
off.
It
is
Tuesday
June,
4th
2019.
This
is
the
sig
release.
Bi-Weekly
meeting
welcome
everybody.
The
meeting
is
being
recorded,
I'll
upload
it
to
YouTube
just
after
the
meeting,
hopefully
so
be
cognizant
of
our
kubernetes
code
of
conduct
and
be
good
people
as
I'm
sure
everybody
here
will.
A
We
usually
have
a
good
amount
of
cloud
rice
you
go,
and
so
first
thing
if
I
will
drop
a
reminder
on
the
minutes
into
the
zoom
chat.
If
y'all
could
put
your
names
in
there
under
attendance,
I
will
volunteer
to
take
notes,
I
guess
because
I
I
don't
have
much
to
talk
about
today,
so
I
figure
I
can
take
notes.
While
you
all
talk
this
time
around.
A
B
C
Yes,
I
was
sorry
double
muted,
yeah
I
generally
agree
with
Josh
that
I'd
like
to
see
a
turnover
or
if
that
person
really
is
like
passionate
about
continuing
and
initiative
in
that
role,
they
maybe
step
into
a
shadow
capacity
to
help
push
a
specific
initiative
through
and
let
someone
take
over
being
the
lead,
so
they
get
some
more
of
that
leadership.
Exposure
within
the
release
team
like
I,
could
see.
C
The
only
area
is
if
somebody
had
a
very
specific
initiative,
they
were
trying
to
push
through
why
they
would
be
super
keen
on
staying
in
a
role
but
generally
and
I
think
that
we
kind
of
like
talked
about
the
release
team
in
the
sense
of
it's
not
a
super
long
commitment
and
it's
a
place
where
you
can
go
to
get
exposure
and
get
some
leadership.
So
yeah
generally
agree
with
Josh
that
it
should
be
something
where
folks
are
able
to
take
on
a
not
hold
on
to
a
lead
role
for
multiple
cycles.
D
Yeah
sorry
Tim
go
ahead,
yeah
I,
agree
with
Josh
and
Claire
I
think
the
only
thing
I
would
have
to
add
is
if,
if
there
are
no
suitable
shadows
or
they
don't
want
to
step
up
to
the
role,
then
potentially
we
could
say
hey
you
can
stay
on,
but
I
think
then
that
effect
is,
if
you
have
shadows,
who
want
to
step
up
you're
priming
them
for
burnout
by
not
letting
them
step
up
so
either
week.
Somehow
state
that
clearly,
like
hey
you're,
not
guaranteed,
to
be
a
lead,
and
there
should
be.
D
There
could
be
a
way
that
you
could
say:
hey,
I,
don't
I,
don't
feel
like
as
a
lead
that
the
shadows
are
capable,
but
I
think
leads
could
serve.
I.
Think
the
best
thing
is
just
to
say
either.
If
there's
no
no
shadows
willing
to
do
it,
then
a
lead
could
continue
on,
but
otherwise
leads
should
try
other
roles
or
we
could
I
think
there's
another
thing
down
there.
D
They
could
be
emeritus
advisors
if
we
wanted
to
do
something
with
that
to
where
they
can
help
the
other
thing
that
Claire
mentioned
about
if
they
had
specific
initiatives.
If
I
was
to
take
like
Aaron,
Crick
and
Berger,
for
example,
he
went
into
the
sub-project
because
he
wanted
to
help
do
CI
signal.
So
we
could
actually
spin
people
out
and
say:
look
you
you
you,
you
learn
something
from
a
race
team,
go
to
the
sub-project,
execute
on
something
that
will
help
the
release
team,
but
you
can
do
that
under
the
guise
of
the
sub-project.
D
A
A
There
is
a
phrase
saying
that
there's
an
expectation
that
shadows
would
step
up
at
some
point
in
the
future
to
lead,
but
I
know
we've
discussed
saying
that
it's
okay
for
a
lead
to
stay
on
and
we've
had
a
few
situations
where
the
lead
was
really
trying
to
figure
a
fair
amount
out,
like
I,
think
I'm,
Doug,
McClure
and
I
think
did
Branch
Management
twice
in
a
row
if
I
recall
correctly,
and
the
first
time
was
a
huge
discovery
process
in
the
second
time.
Maybe
was
kind
of
refining.
A
So
I
can
see
that
as
a
pattern
like
you
you've
shadowed,
but
you
become
the
lead
and
you
change
some
stuff
or
you
really.
You
once
you've
been
given
sort
of
the
keys
of
the
castle
for
whatever
that
role
is
you've
really
learned
something
and
you
you're
finally
able
to
really
exercise
it.
So
I
think
there's,
like
Tim,
said:
balancing
continuity
versus
turnover
just
because
the
person
had
three
months
doing
the
thing
doesn't
mean
that
they've
really
satisfied
that
desire
to
do
it,
and
we
should
also
honor
that.
E
I
think
one
point
would
be
that
as
its
shadow.
If
you
continue
in
the
next
round
other
shadow,
you
can
still
continue
executing
on
the
same
story.
You
don't
have
to
believe
next
cycle.
Do.
E
So
I
do
agree
that
maybe
a
policy
of
shifting
shadows
and
and
graduating
shadows
to
leads
and
LAT
leads
being
only
leads
for
one
cycle
or
one
consecutive
cycle.
It's
a
good
way
to
introduce
new
ideas
and
ability
for
everybody
to
execute
and
also
if
someone
is
intending
to
continue,
they
can
be
shadows
or
emeritus
and
they
should
be
of
exception,
like
we
have
lots
of
policies
now
and
a
way
to
file
an
exception.
If
there
is
really
a
need
for
a
consecutive
lead,
they
can
file
an
exception
or
to
the
policy.
E
A
Josh,
do
you
have
some
wording
in
mind
that
would
be
not
prescriptive
or
so
declarative,
but
kind
of
could
cover
the
set
of
ranges
and
be
flexible,
like
I,
don't
think
we
have
like
a
formal
process
pilot
exception.
All
of
that
sort
of
that
starts
to
feel
a
little
heavy.
Wait.
We've
been
pretty
pragmatic
on
this,
but
to
put
some
wording
in
there.
That
does
say
we
value
turnover
and
growing
skills
and
broadening
things
out.
In
addition
to
valuing
continuity,
could
you
maybe.
B
F
So
far
we
have
avoided
like
all
the
process,
hard
core
processes
for
exception
and
things
like
that.
I,
don't
think
we
need
that
here
as
such
at
this
point,
and
they
can
take
two
turns
then
go
to
something
else.
They
can
come
back
as
well
right
and
worst
case
scenario.
You
don't
really
need
a
formal
role
to
do
anything
right.
You
can
always
work
on
the
things
that
you
want
to
do
and,
oh,
you
can
work
with
the
leads
to
get
whatever
you
want
done.
So
I
don't
see
that
as
a
problem.
B
C
Yeah
just
a
note
that
I've
started
the
repo
for
assembling
the
1/16
release
team
and
the
I've
nominated
lucky
and
he
is
accepted
to
be
the
1/16
release
lead.
So
hopefully
we'll
start
seeing
all
the
different.
The
different
folks
who
are
gonna
be
helping
lead
1/16
getting
put
up
there.
D
B
B
Let's
see,
wait
a
minute
I
think
there
was
something
else
I
wanted
to
say
about
this:
did
you
do
oh
right
person?
The
second
thing
is
I
was
thinking
of
also
doing
an
exit
questionnaire
for
section
leads
and
shadows
believes
that
the
overall
goal
of
this
is
to
check
up
on
the
sort
of
mentoring
and
promotion
process
for
the
release
team,
because
the
release
team
is
getting
very
large
and
I,
don't
think
it's
possible
to
necessarily
track
all
of
it
casually.
B
G
C
A
So
next
on
the
agenda
would
be
the
emeritus
advisor
Josh
I
feel
like
you've
got
a
fair
amount
that
you've
talked
about
wanting
to
accomplish,
with
this
role
and
and
this
feedback
loop
kind
of
dovetails
into
that
I
sense
that
you
have
more.
You
want
to
do
here
and
that
you've
just
kind
of
started
into
it,
but.
F
B
B
B
E
A
I
feel
like,
as
we
expanded
the
shadows,
we
kind
of
we've
added
some
words
and
some
of
the
existing
handbooks
about
make
sure
you're,
you're
mentoring,
your
shadows,
but
I'm
really
curious
to
hear
having
a
person
dedicated
and
making
sure
that
happened.
What
wait,
what
you
were
observing
and
if
we
need
to
bolster
any
of
that
yeah.
B
And
one
of
the
reasons
why
I
want
to
continue.
This
is
because
of
my
travel
schedule.
I,
don't
feel
like
I
was
able
to
observe
that
as
closely
as
I
would
have
liked
to
the
during
a
lot
of
the
sort
of
it
was.
A
combination
of
this
was
a
short
release
cycle
and
I
spent
most
of
it
on
the
road,
and
so,
as
a
result,
I
pretty
much
dealt
with
just
dealt
with
problems
in
terms
of
recruiting
shadows,
etc,
and
not
so
much
day-to-day
monitoring.
A
So
next
on
the
agenda,
then
I'm
not
hearing
anybody
else
and
basically
everybody
saying
yeah.
Please
please
continue
Josh
next
up
is
the
release,
notes,
website,
chef,
hello,.
H
This
is
gonna,
be
quick,
because
this
meeting
is
kind
of
awful
for
me
and
I'm
in
the
middle
of
cooking.
The
release
notes
website
is
live
in
that
we
now
have
a
domain
name,
it's
rel,
No
states.
Do
you
can
go
to
that
right
now
and
you
will
see
an
old
draft
of
114
really
I
wanted
to
get
the
DNS
and
the
net
laughs
I
integration
going
sooner,
because
I
wasn't
sure
how
long
that
would
take
and
it
happened
to
get
done
a
lot
faster.
H
H
E
H
One
question
that
I
was
curious
about
is
whether
we
wanted
to
rip
off
the
band-aid
and
remove
all
the
basic
change
log
entries
from
the
115
mark
down
or
if
we
wanted
to
punt
that
to
116
and
then
have
kind
of
a
split
brain.
We
have
the
mark
down,
but
we
also
have
the
website.
I
personally
have
an
opinion,
but
I
would
prefer
to
get
more
of
a
consensus
than
they
just
arbitrarily
deciding
and
the
cats
are
fighting
awesome,
but
once
it's
all
finalized.
F
H
Tom
about
it
once
it's
all
like
finalized
and
between
115
and
116
I'm,
going
to
write
up
Doc's
on
how
to
update
the
release
notes
website,
it's
kind
of
already
there
in
that
it's
a
PR
against
the
release,
notes,
website
and
there's
a
JSON
file,
but
I'd
rather
have
it
in
the
will
handbook
not
just
like
in
the
release,
notes
website
or
a
release,
notes
repo.
So
that
is
me.
I
would
love
to
hear
discussion.
H
It's
minimal,
so
the
difference
really
is
the
release,
notes,
tool
you've
put
in
a
flag
that
has
a
generate
JSON
versus
markdown.
The
difference
is
when
we
go
through
the
whole
draft
phase,
where
people
can
go
through
and
change
the
verbage
and
stuff
we'd
have
to
then
take
that
from
the
Google
Doc
that
we
jet
or
that
we
copy/paste
and
work
out
of,
and
then
update
the
JSON
with
that.
So
it's
it's
not
that
much.
It's
just
somewhat
tedious.
Until
we
go
to
a
single
one,
I'd
be
happy
to
do.
F
H
Technically,
okay,
the
change
that
I'm
proposing
and
that
was
in
the
cap
is
the
giant
list
of
every
single
PR
and
the
PR
description,
get
removed
from
the
changelog
and
then
put
into
this
website.
Technically,
you
could
then
select
115
and
then
print
it
out
or
PDF
it,
but
it
would
not
be
in
the
same
page
as
the
markdown
that
has
like
the
major
themes
and
the
deprecation
zamana.
A
Was
that's
been
my
question
across
a
fair
amount
of
time
like
what
fill
us
philosophically,
you
were
wanting
to
do.
I
think
we.
We
have
two
things
that
we're
trying
to
accomplish
one
give
a
human-readable
summary
and
editorialize
in
it,
and
that
definitely
has
value
that
is
hard
to
do
and
accomplish.
But
once
done
that
can
live
is
a
basically
static
thing
in
a
repo
and
and
be
viewed
offline
and
imprinted
things
like
that.
Like
tim
says,
but
then
there
is
still
like
hey
all
of
these.
A
This
huge
list
of
things
somebody
deemed
them
worthy
of
a
release.
Note.
How
do
you
make
that
searchable,
sortable
on
dynamic
criteria
versus
static
in
a
file
where,
basically,
nobody
reads
the
fifty
pages
of
stuff
and
the
the
dynamic
website
suits
that
version
of
sought-after
information,
better,
so
I
kind
of
like
having
the
the
two
paths:
I,
don't
see
them
necessarily
as
duplicated
content,
though
versus
different
like
one,
a
one-time
effort
to
create
an
edited
human,
readable
shortlist
of
highlight,
highlights
and
then
one
all
of
the
release
notes
in
a
searchable,
sortable,
dynamic
way
right.
F
H
So,
to
be
somewhat
specific,
what
I
am
would
propose
for
115
and
it
doesn't
have
to
be
115,
but
just
let's
roll
with
it
is
we
remove
the
giant
list
of
PRS
and
those
go
into
the
release
notes
website.
The
markdown
file
would
still
have
the
themes,
the
deprecations,
the
security
notices,
literally
everything,
but
the
list
of
PRS
with
their
descriptions,
and
then
we
would
link
to
it
directly
and
it
would
automatically
load
with
115
I
again
I'm
perfectly
fine,
duplicating
it
and
I'm
saying
duplicating
it.
Just
because
it's
running
the
tool
twice
but
I.
A
There's
always
somebody
who
says
why
was
it
sorted
on
this
dimension
instead
of
that
dimension
and
I
can't
find
my
stuff
so
having
all
of
that
disappear
and
refer
to
the
tool
where
you
can
go
find
the
stuff
that
you
individually
are
interested
in
I?
Think
that's
a
good
thing,
and
but
at
the
same
time
we'll
see
whether
people
like
it
or
find
fault
with
it
as
well.
Yeah.
F
H
So,
while
it's
not
in
there
now,
I
have
to
PR
it
in
the
behavior
will
be.
If
you
just
visit
real
notes,
KPI,
oh
it
will
list,
it
will
automatically
select
the
most
recent
release
and
you
can
click
and
filter
on
multiple
or
you
know
different
releases,
and
you
can
also
directly
link
to
different
releases
so
like
for
the
markdown
for
1:15.
Let's
say
it
would
have
a
direct
link
that
automatically
selects
115
all.
F
H
H
F
H
Let
me
share
my
screen.
Click
just
perfect,
oh
good.
It's
about
to
get
a
whole
lot
louder
and
I
apologize,
so
everyone
can
see
that
right
yeah.
So
if
you
click
this
number,
it
goes
right
to
the
actual
PR.
So
right,
for
example,
when
you
need
to
link
this
specific
one,
we
could
link
backyard
and
it'll
have
the
same
thing.
If
it
actually
does.
F
F
H
Yeah
that
is
coming,
that's
in
the
clear
that
I
need
to
cut,
because
the
same,
the
same
logic
that
lets
me
link
to
directly
to
say
114
would
also
let
me
dynamically
read
it's
the
angular
routing.
So
if
I
start
selecting
stuff,
it'll
actually
start
changing
the
URL
on
that
you'll
be
able
to
comment
paste
that
so
that
is.
F
A
Oh,
we
lost
Claire
actually
well
so
I
would
I
would
bring
this
up
again.
On
the
because
I
know,
I've
talked
with
Lindsay
about
it
and
has
kind
of
been
discussed
much
earlier
in
the
cycle,
but
we
hadn't
really
closed
out
on
it,
whether
as
a
sig
release
or
as
the
release
team,
but
I
think
this
is
directly
in
response
to
something
that
the
community
has
been
asking
for
so
I'm
inclined
to
say,
trial
it
and,
let's
see
what
happens,
but
I
would
give
Claire
the
call
in
her
release.
A
A
G
I
wanted
to
bring
up
this
item
with
you.
Basically,
for
now
we
only
publish
the
latest
stable
version
on
a
you
URL.
Let
me
send
you
a
link.
I
can
find
it
so
yeah.
Basically,
we've
we
publish
links
like
that
that
are
consumable
by
automation,
but
for
now
we
do
not
publish
version
requirement
for
dependencies,
such
as
CN
my
HDD
cordia
nessam,
these
kind
of
stuff
that
are
published
in
a
way
that
is
consumable
by
automation.
So
I
wanted
to
see
with
you
if
it's
something
that
we
should
or
won't
do.
F
So
that
goes
back
to
the
question
in
release
notes
where
we
constantly
struggle
to
update
the
version
numbers
of
the
different
components
that
we
use
every
time.
I
think
we
need
to
figure
out
a
way
to
automate
that
first
and
then
that
will
help
publish
it.
Make
the
publishing
easier.
The
gathering
of
the
information
is
the
first
problem.
We
don't
have
a
reliable
way
to
gather
that
information.
We
typically
end
up
scrambling
trying
to
figure
out
okay,
which
version
of
core
DNS,
which
will
innovate
CD.
You
know
what
have
you.
F
Each
company
is
different
right,
so
we
have
some
of
them.
We
go
looking
bad
script,
some
of
them.
We
go
look
in
some
JSON
file
or
Yammer
file
and
then
most
of
the
time
we
go
hunt
for
peers
that
are
changing
something
and
see.
So
no,
we
we
don't
have
it.
That's
that's
the
first
problem
we
need
to
work
on
so
then
we'll
be
able
to
publish
it
from.
F
F
Note
look
at
the
list
of
dependencies
that
we
published
there
and
come
up
with
JSON
or
AML
that
reflects
that
list
of
modules
and
the
versions
right,
and
so,
let's
do
that
in
in
a
PR
or
somewhere
right
collaboratively
and
then
we'll
find
out
the
updates
that
happen
from
a
114
to
115
and
in
that
process
see
if
there
is
a
way
to
automatically
collect
that
information
and
gets
somebody
to
update
in
this
file.
In
addition
to
the
other
file
that
they
are
touching.
A
F
A
G
I
think
that
we
could
base
the
approach
on
the
release
notes
since
bump
a
dependency.
We
usually
open
a
PR
for
at
least
for
the
major
components
like
go.
Read
it
from
the
last
release.
Note
for
114
I
can
see
a
bunch
of
bumps,
so
if
we
could
have
like
some
set
of
label
to
filter
out
PRS
the
bump
that
some
of
the
components
we
could
then
rely
on
some
github
query
to
to
fetch
these
PRS
and
get
the
release
notes
at
the
versions.
A
Expecting
an
individual
contributor
to
put
the
right
label
on
one
of
these
bumps
is
basically
the
same
as
expecting
them
to
put
a
release
note,
and
we
know
that
a
lot
of
them
there's
a
big
track
record
of
us,
discovering
them
retro
actively
them
out.
So
I'm
really
curious
to
see
if
we
could,
if
we
can
enumerate
the
places
where
these
constants
exists
today
in
the
code
base,
if.
E
E
A
Just
look
at
that
and
different
compared
to
prior
release,
but
if
we
could
start
automating
the
observation
of
hey
somebody
changes
without
requiring
the
individual
to
have
done.
The
right
thing
to
highlight
it.
I
feel
like
that,
instead
of
cig
release
pushing
work
on
everybody
out
there
in
the
entire
project,
its
cig
release,
saying:
okay,
this
thing
is
unmanaged.
We're
gonna,
try
and
take
control
of
it.
F
G
F
B
A
Of
a
pattern
in
the
project
and
it's
a
more
constructive
one
than
than
hoping
or
wishing
or
declaring
somehow
that
everybody
must
do
this
thing.
If
we
can
articulate
it
in
code,
we
can
have
a
script.
It
can
notice
the
mismatch
and
fail
a
test
so
that
somebody
gets
the
feedback
that
they
didn't.
Do
the
thing
and
start
to
build
out
the
knowledge
from
there
yeah.
A
Awesome,
thank
you
for
bringing
this
up,
and
thanks
for
volunteering.
I
I
do
think
that
this
is
a
relatively
straightforward
little
verifier
to
get
written
out
and
it'll
it'll
be
huge
to
be
able
to
have
this
tool
that
we
can
run
periodically
or
even
get
a
part
of
CI
regular
much
more
regularly
if
nothing
else
to
be
able
to
instead
of
humans
scouring
a
bunch
of
files
every
three
months
that
it's
press
the
button
and
collect
the
things
and
and
also
we
publish
it
as
a
draft
and
people
say.
A
Well,
that's
not
right,
and
this
is
already
what
we
have
with
the
release
notes.
We
we
manually
laborious,
ly,
build
up
the
list
and
share
it
in
people
like
no,
that's
not
right.
We've
changed
this
to
that,
and
then
we
start
to
notice.
There's
multiple
places
where
the
that
this
is
defined
as
this
and
that
so
the
more
we
build
this
up
a
little
bit.
I
think
we're
gonna
make
a
lot
of
positive
cleanups
across
the
codebase.
A
A
Do
need
to
work
on
having
a
shift
different
times
in
the
bi-weekly
meetings,
so
Niko's
just
left
a
note
to.
Let
us
know,
I
think
that
the
the
triage
workflow
improvements
are
moving
along.
There's
an
issue
and
a
pull
request
out
there.
So
folks
take
a
look
at
them,
please
and
comment
if
you
have
thoughts
on
them
and
then
one
last
thing
for
me,
so
I
just
discovered
this
today
we
there's
relatively
small
number
of
people
in
the
communities
project
who
have
right
access
to
different
repos
across
the
different
SIG's.
A
For
us,
some
of
our
lead
folks,
especially
from
the
release
team,
have
right
access
on
the
Kasich
release
repo
and
what
that
means
nowadays
is
that
you
can
also
do
some
funky
things
in
the
github
web
UI
it's
possible
to
edit
a
file
and
make
a
PR
without
ever
doing
anything
local
on
your
computer
nowadays
get
lets.
You
do
this
in
the
web,
UI
and
apparently,
if
you're,
not
careful,
you
do
it
on
k,
cig
release
instead
of
your
username
slash,
cig
release
fork.
A
So
we
need
to
figure
out
if
there's
any
controls
we
can
put
in
place
on
that,
to
prevent
it
or
just
watch
for
it
and
be
mindful
and
educate
our
new
people
who
come
in
to
release
roles
so
that
they're
not
creating
branches
and
pushing
direct
to
Kasich
release,
but
rather
doing
that
to
your
fork.
So
I,
don't
I
thought
this
is
what
branch
prediction
was
supposed
to
prevent.
I
was
looking
at
the
branch,
protection,
toggles
and
I
wasn't
seeing
creation
as
an
option
vs.
A
deletion,
which
makes
sense
so
I
I,
just
I
bumped
into
this,
like
45
minutes
before
the
call
and
realized
and
found
out
that
a
couple
of
people
have
been
doing
things
direct
on
the
branch
and
they
are
people
who
have
elevated
privileges,
so
I'm
not
sure
if
it's
the
elevated
privileges
or
a
lack
of
control
or
if
we
can
somehow
thread
that
combination
in
a
way
that
makes
sense.
But
I
will
take
the
to
do
to
go.
A
Look
at
this
understand
better,
what's
happening
and
propose
something,
and
it
may
be
something
that
we
need
to
bubble
up
like
to
contrib
X,
to
let
others
know
about
the
potential
for
similar
to
happen
on
their
repositories
and
I
feel
like
this
is
something
that's
gonna
happen.
More
and
more
github
is
is
doing
cool
things
in
the
UI,
but
some
of
us
who've
been
around
longer
just
sort
of
assume
everything's
happening
on
the
CLI
and
people
know
how
to
get
and
the
min
commits
and
push
and
elevated.
B
A
A
One
final
thing:
I
guess
that
I'll
throw
out
there.
It's
been
two
weeks
now
a
week
before
last,
at
cube
con,
we
had
quite
a
few
people
who
were
interested
in
both
release
team
and
cig
release
and
the
deep
dives
in
intros
at
curious
to
get
involved.
I've
had
a
few
people
ping
me
one
on
one
on
slack,
just
asking
for
more
info
and
just
the
reminder
and
how
to
get
on
the
Google
group
how
to
get
on
the
invite
for
the
meeting
and
stuff
like
that.
So
hopefully
we've
got
a.
We.
A
A
Yes,
exactly
mentioning
that
in
the
chat
there's
a
couple,
other
people,
who've
pinged
me
and
I-
don't
didn't
see
today,
but
yeah
we
last
week
getting
back
from
travel
after
a
couple
weeks
of
conference
travel
in
row.
I
was
sooo,
first
want
on
the
day
job
immediate
requirement,
so
I
haven't
gotten
back
to
working
on
the
the
backlog
instead
of
actions
that
I
want
to
see
getting
done,
but
my
hope
is
now
I.
A
Don't
like
Josh
said:
I,
don't
have
any
real
travel
plans
for
work
or
conferences
for
quite
a
while
and
can
hopefully
go
to
a
little
more
heads
down
on
some
of
this
stuff
and
we
can
get
these
sub
projects,
but
the
release
one
and
the
the
release
engineering,
but
also
a
licensing
or
or
two
that
we're
looking
to
get
a
little
more
activation
on
in
the
coming
weeks
and
months
for
the
through
the
116
cycle.
So
watch
this
space.