►
From YouTube: 2022 05 19 Docs Office Hours
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
Welcome.
Thank
you
very
much.
This
is
the
doc's
office
hours
for
jenkins
european
and
it
is
thursday
may
19th.
For
today
we've
got
an
agenda
already
planned
out.
We
have
localization
and
internalization
with
alex.
He
ends
up
joining
us.
We
have
the
june
lts
change
log,
an
upgrade
guide
and
blog
post,
which
I've
added,
and
we
can
we'll
discuss
further.
A
The
require
java,
11,
epic
and
the
tasks
associated
with
that
bezel
has
done
a
great
job
of
compiling
all
that,
putting
that
together
and
creating
the
tickets
for
us
so
we'll
go
over
that
and
see
what
else
we
can
do
for
them.
And,
finally,
our
chico
africa,
africa,
contributon
it's
getting
close
to
wrapping
up
mark,
will
tell
us
more
about
that.
A
So,
first
off
it
doesn't
look
like
alex,
is
here
yet
so.
B
I'll
give
a
quick
status
report
kevin
if
that's
okay
and
then
yeah.
So
this.
This
can
be
really
a
nice
story.
To
tell
that,
we
now
have
eight
plugins
on
crowdin.jenkins.io
that
are
managing
their
translation
process
with
crowdin
and
bruno
has
been
a
great
contributor.
There
contributed
translations
into
french
language
for
many
of
them.
B
B
So
as
it
sits
now,
crowding
is
not
a
great
choice
for
a
hacktober
fresh
oktoberfest
contribution,
but
I
want
to
talk
to
alex
about
it
in
case
he's
got
some
idea
of
ways
that
we
might
be
able
to
make
it
fit
better,
and-
and
that's
in
part
because
of
this-
how
to
encourage
translation
contributions,
I'm
wondering
as
a
separate
story
is
there
a
way
we
could
motivate
and
inspire
people
to
contribute
some
form
of
leaderboard
or
some
form
of
thanks
thanks
to
our
top
five
contributors,
showing
the
crowdsourcing
ideas.
So
those
are
topics
for
me.
B
Then,
as
the
very
last
point
darren
pope
and
I
are
going
to
do
a
live
stream.
Probably
one
hour
on
internationalizing
jenkins,
I've
learned
some
things
about
what
it
means
to
internationalize
a
plug-in
and
we'll
use
those
to
talk
to
people
about
how
we
used
to
do
internationalization
and
how
there
are
slight
refinements
that
we
can
do
now
to
make
it
work
better
with
crowd
in
and
he
and
I
will
probably
do
that
within
the
next
one
to
three
weeks.
A
Thanks
mark,
does
anyone
have
any
questions
on
that
before
we
move
on
to
the
next
topic
or.
C
Is
it
okay?
I
have
a
question
a
very
basic
one,
maybe,
but
regarding
internationalization
and
localization,
when
I
used
to
do
some
internal
socialization
with
java,
only
we
could
go
up
to
internationalizing
images
or
html
files,
not
just
with
the
you
know
the
sentences
translated,
but
also
the
look
and
feel-
and
some
will
jenkins
go
up
to
that.
You
know
maybe
changing
the
images.
If
that
ever
makes
sense,
or
you
know
changing
the
way
it
is
read
from
left
to
right
or
right
to
left.
B
Good
question,
and
as
far
as
I
can
tell
right
now,
there
isn't
so
html
files
can
and
are
included
in
the
translation
process.
So
so
that
part
yes,
but
in
terms
of
images
or
or
what
what
I
might
call
deeper
deeper
changes,
behavioral
changes
jenkins,
doesn't
really
have
support
for
it
right
now.
Okay,
thank
you.
A
You
so
much
bruno
any
other
questions
before
we
move
on
yeah.
D
Regarding
this
topic
of
how
do
we
encourage
translation
contributions?
D
D
That
would
immediately
allow
you
to
start
filling
in
translations
and
submitting
them
to
us,
so
I
think
it
would
be.
It
would
be
cool
to
kind
of
take
to
think
about
that
idea
and
think
about
how
we
might
be
able
to
apply
that
to
crowded
in
a
way
that
we
could
maybe
put
a
link
at
the
bottom
of
the
jenkins
ui
that
might
direct
people
to
crowding
to
just
immediately
start
filling
in
their
translations,
because
that
kind
of
lowers
the
barrier
to
entry.
D
C
Yeah,
that's
brilliant
for
the
timing.
We
only
have
some
plugins
some
jenkins
plugins
that
we
can
translate
for
the
time
being.
The
core
is
not
yet
entered
into
the
crowding
system,
and
the
thing
is
we
could
have
a
link,
as
you
say,
for
existing
plugins,
which
are
already
registered
within
crowding
and
for
plugins,
which
are
not
yet
we
could
add
some
kind
of
another
link
that
could
start
something
with
desk
or
maybe
that's
not
such
a
good
idea
because
of
the
spam.
C
We
could
get
that
triggers
something
so
that
we
know
that
somebody
wants
to
help
with
the
plugin,
which
is
not
translated,
yet
all
the
parts
of
jenkins
which
is
not
translated.
Yet
that
would
be
really
helpful.
I
think
thank
you
for
this
suggestion.
B
Could
you
envision
that
this
this
facility
were
somehow
detecting,
hey
I'm
running
in
non-english
language,
and
I'm
this
message
that
I'm
seeing
on
screen
is
in
fact
still
the
english
language
version
show
them
a
choice
to
go
somewhere
to
help
convert
it.
I
I
think
I
see
your
point
mazel.
It
sounds
very
attractive
yeah.
I.
D
Mean
if
you,
if
you
look
at
the
plugins,
you
don't
have
to
do
this
right
now.
But
if
you
look
at
the
plugins
website
for
the
translation,
assistance,
plugin
or
whatever
the
name
of
it
was
they
have
a
screenshot
and
the
screenshot
shows
the
kind
of
the
old
ui.
So
there's
a
link
in
the
footer,
you
would
click
on
the
link
and
it
would
give
you
a
bunch
of
strings
kind
of
like
the
crowded
ui
does
and
you
can
just
hit
submit
to
submit
them
to
a
central
server
which
is
now
shut
down.
D
So
I
think
you
know
the
idea
would
be.
We
just
give
people
that
link,
but
instead
of
our
own
user
interface,
it
would
go
to
the
crowded
one
and
then
they
could
do
the
same
thing.
But
you
know
we'd
have
to
be
able
to
detect
whether
that
plugin
is
using
crowded
and
where
to
direct
them,
and
things
like
that.
B
Yeah
but,
and
though,
but
those
are
in
fact
solvable
solvable-
I
mean
in
context.
I
know
that
the
little
subsection
of
help
that's
being
displayed
is
coming
from
a
specific
plug-in,
because
it
tells
me
the
plug-in
that
contributes
that
and
so
that
kind
of
information's
got
to
be
available.
I
think
it
sounds
very.
A
Uh-Huh
kevin,
so
if
there
are
no
more
questions
on
that
move
on
to
the
june
lts
change,
log
upgrade
guide
and
blog
posts.
So
I
submitted
the
pull
request
last
week
for
the
june
lts
and
I'm
currently
putting
a
draft
together
for
the
blog
post
about
the
svg
replacement
based
on
bazel's
feedback
in
the
request
itself.
A
I'm
going
to
be
going
over
that
with
mark
a
little
after
this
to
just
get
some
more
structure
to
it
and
take
a
look
and
see
what
else
I
can
add,
there's
still
a
little
bit
of
the
format
that
I
want
to
make
sure
I
understand
and
have
ready
to
go
outside.
Of
that,
though
everything's
feedback's
been
given
we're
getting
a
lot
of
traction.
A
There
are
a
couple
of
other
tickets
that
are
linked
to
the
svg
replacement
item,
so
I'm
just
looking
through
those
getting
further
information
from
there
as
well
and
and
making
sure
that
I
have
a
full
comprehension
of
everything
prior
to
writing.
B
Yeah
so
kevin
there
yeah
that
that
one's
sort
of
my
my
voice
on
the
my
concern
that
it's,
if
you,
if
you
let's
see,
I
don't
think
you
can
even
view
visualize
this
one,
but
if
you
go
to
the
oh
I'll,
have
to
put
it
into
it.
If
we
were
to
look
at
this
in
the
visualization
view,
were
it
available,
what
we
would
see
is
15
20
or
more
ui
improvement
items
as
individual
line
items
that
are
each
one
by
itself
doesn't
look
terribly
interesting.
D
Would
it
be
good
to
just
group
them
into
themes
and
write
one
paragraph
about
each
theme
for
maybe
a
handful
of
themes
like
three
to
five
themes:
for
example,
plugin
manager,
improvements,
configure
project
improvements,
or
things
like
that,
like.
B
Yeah
that
that
might
be
that
may
be
the
technique,
because,
where
I
detected
three
or
four
themes-
and
I
actually
grouped
them
in
the
pull
request
by
those
themes
with
a
comment
above
each
so
I
may
I
may
experiment
with
that,
just
as
an
alternative
kevin,
because
I'm
I'm
wrestling
with
this
one.
The
this
is
a
cool
release.
It's
got
some
brilliant
functionality
in
it
and
the
change
log
sometimes
obscures
it.
By
being
too
detailed
got
it.
Can
we
add
screenshots
to
it,
because
that
would
that
would
make
it
even
more
compelling.
B
But
we
I
don't
have
a
way
to
do
screenshots,
but
if
we
want
that
we
could
certainly
do
a
blog
post
that
highlights
this
and
then
then
we
can
do
the
full
story
right
and
that
maybe
we've
certainly
done.
We
did
a
full
webinar
on
277.1
when
we
did
the
tables
to
divs
transition,
and
we
could
do
the
same
thing.
Here
is
a
blog
post
and
a
webinar
on
hey,
look
what's
coming,
and
then
we
can
talk
high
level.
We
can
show
pictures
we
can
demonstrate,
and
that
may
be.
A
Sense,
great
any
other
questions
before
we
move
on
to
the
next
item.
Under
the
june
lts
change
lab.
Okay,
so
again,
basil
created
the
require
java,
11,
epic
and
documentation
related
tasks.
So
right
now,
the
first
week
of
the
release
is
scheduled
for
june
21st
and
the
first
lts
to
require
java
11
will
looks
to
be
september.
2022.
A
then,
and
in
that
regard,
these
are
the
four
document
tasks
that
basil
created
he's
assigned
them
to
himself.
But
there
are
a
couple
here
that
I
might
be
able
to
take
over
or
help
with
just
due
to
what
I'm
going
to
be
doing
my
experience
and
everything
else
so
basil,
I
was
hoping
that
you'd
be
able
to
kind
of
take
us
through
those
and
if
once
we
get
through
those
just
if
I
have
questions
or
anything
like
that,
I
can
ask
them
for
it
and
get
some
better
insight.
D
A
B
D
So
so
this
this
is
referring
to
the
changes
in
the
packaging
repository,
and
these
pages
are
visible.
If
you
go
to
jenkins.io
and
click
on
the
download
jenkins
link.
It'll,
take
you
to
a
list
of
packages
that
we
build
and
publish
and
in
the
footer
of
or
sorry
the
header
of
that
page
is
header.html.
D
It
has
a
link,
it
has
a
list
of
releases
and
the
minimum
java
version
yeah.
You
could
also
find
it
in
the
ui
in
the
on
the
actual
website
there
yeah
exactly
so
somewhere
on
this
page.
I
think
it
might
be
it
might
be
if
you
click
on
one
of
the
one
of
the
packages
like
like,
for
example,
I
think
if
we,
if
we,
I
can't
remember
where.
D
Hand,
side
yeah
so
yeah,
so
on
this
page
at
the
very
bottom
it
says
you
know,
2.164
requires
java,
8
or
java
11..
So
basically,
that
list
needs
to
get
updated
to
show
the
new
requirement
for
java
11.,
but
there's
a
complication
with
this
page
in
that
the
code
you're
looking
at
to
generate
that
text,
it's
currently
the
same
html
file
for
both
the
lts
and
the
weekly.
D
So
that's
really.
The
difficult
part
of
this
task
is
to
figure
out
how
to
show
something
different
for
the
weekly
compared
to
the
lts.
So
the
the
url
that
we're
looking
at
right
now
is
slash
debian,
but
there's
another
there's
another
url,
which
mark
probably
remembers
offhand
that
that
shows
the
lts
download
link.
If,
for
example,
I
think
you
could
get
to
it
if
you
go
back
up
and
and
then
go
to
the
the
page
for
the
stable
yeah.
D
Column,
yeah
there's
a
bit
less
ubuntu
right.
So
on
that
link,
that
shows
you
this.
I
think
that
shows
the
same
information
down
there.
So
the
the
challenge
with
this
is
to
figure
out
how
to
keep
that
the
same
for
this
page,
but
to
change
that
text
for
the
other
page
for
the
page
for
the
weekly
release.
Do
you
see
the
point.
A
Yeah
because
the
lts
is
going
to
come
out
after
the
weeklies
have
already
been
coming
out,
and
so
we
have
to
make
sure
that
the
weeklies
get
updated
and
show
the
relevant
information.
But
at
the
same
time
the
lts
won't
be
able
to
require
that
until
it's
released
and
or
until
we
get
to
that
point.
D
Yeah,
so
I
think
this
would
have
been
a
trivial
just
updating
one
string
and
one
file,
if
it
weren't
for
for
this
complication.
So
I
think
it
could
just
be
done
by
you
know,
copying
and
pasting
the
text
or
finding
some
way
to
include
a
different
string
on
a
different
page.
I
haven't
looked
into
it
very
closely,
so
something
up
to
that
effect.
B
B
Think
so
yeah
we
can
certainly
toy
with
it
to
see,
because
you
need
to
know
how
to
how
to
modify
this
and-
and
basel
is
right
on
the
weekly
side,
we
on
both
sides.
We
want
to
accurately
describe
what
the
version
requirements
are.
It
would
be
better
for
this
page,
the
stable
one
if
it
gave
stable
version
numbers
instead
of
just
giving
weekly
version
numbers
right.
The
reader
of
this
page
doesn't
know
that
2.54
was
some
was
followed
by
some
lts
sometime
later
they're
they're
thinking
lts.
A
Great
awesome,
thank
you
so
much
appreciate
walking
through
that
one.
Is
there
anything
else
on
this
specific
date
or
on
this
one
that
you
want
to
mention
or
is?
Is
that
everything?
That's
all
okay,
great!
Thank
you,
okay
and
then
we'll
take
a
look
at
the
user.
Documentation
updates
as
well.
D
Yeah,
so
this
in
this
ticket
I
went
through
basically
did
a
grep
through
the
entire
jenkins.io
repository
looking
for
any
place
where
I
found
the
string
java,
8
jdk
aid,
jre
aid,
anything
java
related
and
the
number
eight
and
at
a
high
level.
That's
not
that's,
maybe
not
the
best
way
of
going
about
this,
because
what
that
shows
is
things
that
are
incorrect,
that
need
to
be
corrected,
but
that
doesn't
that
process
or
that
methodology
doesn't
necessarily
highlight
things
that
need
that
need
to
be
added
to
explain
new
things.
D
But
so
this
is
the
same
methodology
I
used
for
systemd
and
once
I
worked
on
that
mark
very
correctly
pointed
out.
Well,
it's
not
just
a
matter
of
correcting
the
now
incorrect
pages,
but
also
adding
new
pages
about
the
system,
the
new
system
d
functionality.
D
So
we
worked
on
that
together
to
not
only
go
through
this
process,
but
also
to
add
new
content.
I
don't
think
that
we'll
really
need
any
new
content
about
java
11..
Maybe
mark
has
a
different
opinion,
but
there
aren't
really
any
new
installation
requirements
or
management
requirements.
So
I
I
don't
believe
that
that
we
would
need
to
write
any
new
content
here,
apart
from
just
how
to
upgrade-
and
we
already
have
a
page
for
that-
and
it's
even
linking
to
a
youtube
video
about
how
to
upgrade.
D
So.
I
think
that
all
that's
needed
is
to
just
update
everything.
That's
going
to
be
wrong
to
the
correct
values
rather
than
writing
new
content.
Would
you
agree
about.
B
I
think
you're
right
in
the
main,
if
we
discover
something
where
we're
missing
content,
we
should
be
ashamed
of
ourselves
because
we've
been
shipping
java,
11
support
for
over
two
years
right.
So
if
we
find
something
missing,
it's
not
a
new
missing.
It's
wow!
We
should
have
had
this
for
a
long
time.
D
Right
yeah,
so
with
that
with
that
point
aside
this,
all
these
bullet
points
are
just
going
through
the
existing
content
and
finding
any
places
that
need
to
be
updated
and
the
the
the
general
theme
here
is,
if
it
says
java,
8
or
11
to
simply
change
that
text
to
say
java,
11.
and
there
there
are
some
places
where
there's
two
sections
a
section
for
java
8
and
a
section
for
java
11..
D
So
the
the
java
8
section
can
just
be
deleted
in
those
cases
and-
and
one
thing
I
noted
in
this
ticket-
is
that
a
lot
of
the
times
the
wording
is
set
up
to
introduce
a
contrast
between
these
two
sections,
so
a
mechanical
removal
of
one
section
might
still
result
in
an
awkward
flow
of
the
text.
If
the
text
is
setting
you
up
for
a
contract,
and
then
you
only
get
one
half
of
the
contrast,
rather
than
the
two,
the
two
sides
of
the
contrast.
D
So
one
thing
I
noticed,
as
I
was
reading
these
pages-
was
that
if
I
was
going
through
and
mechanically
deleting
the
java
8
sections
that
I
had,
I
would
probably
need
to
reword
some
of
the
text
a
little
bit
to
now
read
smoothly
under
these,
under
the
assumption
that
there's
no
contrast
being
made
anymore,
there's
just
only
one
thing
now,
so
so
at
a
high
level.
It's
a
very
mechanical
change,
but
then
at
a
more
low
level
I
think
there
might.
D
There
might
be
some
areas
that
just
need
to
be
phrased
more
smoothly
to
to
deal
with
this
lack
of
two
cup
two
items
being
contrasted
and
that
that's
probably
the
most
subjective
part
of
this.
This
change
and
the
other
subjective
part
of
this
is
this
again,
this
perennial
issue
with
lts
versus
weekly,
because
there's
only
we
don't
have
branches
in
the
jenkins.io
documentation,
there's
only
one
primary
branch
that
shows
the
latest
version
of
the
docs
and
I
think
for
system
d.
D
We
kind
of
took
a
compromise
approach
where
in
some
cases
we
just
changed
the
page
to
refer
to
the
weekly
version
and
decided.
Okay,
we're
all
right
with
this
not
being
very
accurate
for
a
period
of
three
to
four
months
until
the
lts
is
released
and
if
the,
if
it's
some
very
minor
section
of
a
minor
page,
it
might
not
be
worth
spending
too
much
time
to
you
know,
write
the
page
for
to
describe
both
weekly
and
lts
and
then
go
back
in
three
months
and
revise
that
again.
D
It's
a
lot
of
work
to
do
that
and
if
it's
a
minor
section
of
a
minor
page,
that
effort
may
not
be
the
best
use
of
time,
but
I
think
for
system
d
for
the
there's
one
major
page
that
we
we
did.
I
think
edit
that
to
describe
both
weekly
and
lts,
because
in
one
case
in
in
the
main
page
about
managing
services,
I
think
mark
felt
that
it
was
important
to
have
that
page
remain
accurate
for
lts,
since
it
was
the
primary
discussion
of
that
topic,
so
that
might
be
necessary
here
as
well.
D
If
there's,
I
think
there
is
one
primary.
If
you
scroll
up
there's
one
primary
page
about
java
yeah
that
the
very
first
link
you
know
requirements,
slash
java.adoc!
D
I
think
that's
really
the
main
primary
documentation
page
that
describes
java
support.
So
if
any,
if
there
were
any
page
where
we
do
that
extra
work
of
describing
lts
and
weekly
and
then
going
back
and
revising
it,
it
would
probably
be
that
page
rather
than,
for
example,
these
other
obscure
pages
like
jenkinscommandparameters.a
doc,
which
has
a
section
at
the
very
bottom
about
these
old
java
versions.
That
might
not
be
the
highest
priority
to
go
and
rephrase
that
for
lts
and
weekly
and
go
back
and
update
it
in
three
months.
D
B
B
A
Yeah
no
and
I
I
feel
absolutely
capable
and
comfortable
taking
on
those
two
documentation
tickets,
helping
out
updating
that
stuff.
No
problem
at
all.
One
question
I
did
when
I
asked
as
far
as
the
original
value
versus
new
value
stuff
is
this
kind
of
just
where
you
were
marking
down
what
changes
you
found
needs
to
be
made,
or
these
the
exact
changes
that
should
be
made.
I
guess
no.
D
This
is
the
his.
This
is
the
edit
history
of
the
the
jira
ticket
itself,
and
I
I
basically
I
wrote.
I
wrote
this
issue
description
and
then,
after
I
had
finished,
writing
it.
I
wanted
to
add
an
additional
note
at
the
bottom
about
this,
this
perennial
issue
of
lts
versus
so
I
went
back
and
added
some
extra
text
and
that's
the
so
that's
what
you
see
there.
D
But
it's
useful
for
me
when
I
want
to
go
back
and
see
if
someone
made
an
edit
what
the
original
version
is.
I
don't
think
in
this
I
might
have.
I
might
have
done
better
in
this
case,
to
just
add
a
comment
with
my
note,
whether
it's
edit
the
original
description
but
either
way.
I
don't
think
it
matters
too
much.
A
Yeah
no
and
that's
fine,
it
was
more.
My
curiosity
since
I
was
just
looking
at
the
ticket
really
kind
of
in
depth
for
the
first
time
off
jenkins,
jira,
so
yeah.
So
I
it
was
more
my
curiosity
of
what
the
all
meant
in
this
case
and
if
those
were
actually
part
of
the
needed
changes
or
not.
So
thank
you
for
clarifying
that.
I
appreciate
it.
D
So
I
think
that
that's
mostly
just
a
matter
of
the
tool
allowing
you
to
look
at
the
edit,
the
edit
history
and
sometimes
that's
a
very
valuable
valuable
for
me,
because
people
will
sometimes
paste
stuff
into
jira
and
as
when
people
go
and
edit
it,
they
sometimes
lose
the
formatting.
So
it's
sometimes
valuable
to
be
able
to
go
back
and
see
how
it
was
originally
formatted
before
someone
made
an
edit
and
messed
up
the
formatting.
So
that's
what
I
that's
what
I
use
that
feature
for
the
most
got
it
awesome.
Thank
you
appreciate
it.
A
Okay
and
then
the
other
two
tickets
possible
were
the
upgrade
guide
and
the
was.
D
B
D
For
this
one,
I'm
going
to
try
to
talk
about
the
nature
of
this
migration,
because
it's
not
it's
not
a
use.
D
It's
not
the
usual
java
upgrade
for,
like
we've
done
for
java,
seven
to
eight
and
before
that,
six
to
seven
you
know,
java
11
introduces
a
lot
of
incompatibilities,
so
I
think
I'm
going
to
try
to
explain
what
those
are
and
what
that
means
to
administrators
and
one
of
the
big
ones
is
this
removal
of
jax
b,
which
affects
jenkins
the
most,
but
more
generally
kind
of
reflecting
on
the
the
the
evolution
of
the
the
java
community
and
how
11
was
a
release
that
broke
compatibility
in
some
ways
that
were
unprecedented
and
the
same
will
be
the
case
for
17
so
kind
of
explaining
to
administrators
who
might
not
be
familiar
with
java
programming
on
a
day-to-day
basis
that
you
know
this
is
not.
D
D
So
I'm
hoping
to
kind
of
cover
that
that
topic,
as
well
as
the
usual,
how
to
file
issues
and
how
to
upgrade
your
plugins
and
things
like
that.
So
great
and
I
think
for
the
for
the
upgrade
guide.
It's
just
going
to
be
the
the
how
to
file
issues
and
upgrade
your
plugins
portion
of
the
blog
post,
just
repeated.
D
So
that's
what
I'm
I'm
going
to
start
writing
that
today.
Hopefully,
but
I
plan
on
sharing
a
draft
in
these
tickets,
I'll
probably
write
it
in
google
docs
and
then
share
the
draft
here
and
you
know
I'll
be
happy
to
to
get
some
people
to
read
the
drafts
and
to
leave
comments.
B
On
it,
so
in
terms
of
getting
this
information
to
the
users,
the
blog
post
can
certainly
be
highlighted
to
the
users
as
a
link
from
the
the
june
21st
changelog
saying:
hey
here's
this.
We
don't
really
have
an
upgrade
guide
for
weekly,
so
I'm
prone
to
say
that
we'll
point
them
to
the
changelog
from
the
changelog
to
the
blog
post
for
the
weekly,
and
this
upgrade
guide
will
be
mostly
for
lts.
Is
that
does
that
work?
For
you,
okay,
I
think
that's
what
we
did
for
guava,
but
if
we
didn't.
A
Great
thanks
so
much
father
appreciate
all
of
that
and
I
know
we're
running
up
against
time
so
mark.
Do
you
want
to
just
quickly
go
over
the
sheet
code,
africa.
B
B
Looking
for
what
pages
that
need
a
screenshot
update
and
identified
them,
and
they
did
a
number
of
them
and
the
ones
that
they
didn't
do
are
still
in
our
list,
so
we
know
to
do
them
so
nice,
nice
help
there.
The
inclusive
naming
project
had
actually
already
touched
the
jenkins
documentation
long
ago,
well
before
she
called
africa.
Most
of
the
all
the
pull
requests
from
this
change.
This
particular
project
were
to
specific
plug-ins,
so
good
work
thanks
to
them.
That's
it
for
me,
great
great
does.
A
Nope
all
right
and
thinks
we
can
wrap
up
now
more
for
end,
recording.