►
From YouTube: Platform SIG 2020 04 23
Description
Jenkins Platform special interest group met April 23 and discussed Java 14 and beyond, Core release project progress, Windows installer, Plugin installation manager in Docker images, Platform roadmap, s390x Docker images for master, Agent images renamed, Windows support for Docker agents, and Google Season of Docs
A
Hi,
everyone
welcome
to
the
Jenkins
platform
special
interest
group,
we're
delighted
to
have
you
here.
It
is
April
the
23rd
of
2020
agenda,
wise
we've
got
open
action,
item
review
and
I
had
put
core
release,
project
and
I.
Think
given
I
propose
the
following
adjustment
and
count
in
agenda.
We're
gonna
put
the
Java
upcoming
topic
with
Matt
sicker
top
of
the
list,
because
Matt's
joined
us
this
morning.
Thanks
very
much
Matt,
then
I
had
cor
release.
Project
windows
installer,
like
an
installation
manager.
A
A
C
Price
I
mean
it's
a
proposal
to
the
developer
money
increased
after
some
consideration,
I
decided
that
maybe
Jeff
isn't
needed.
If
there
is
a
consensus
right
now,
there
is
a
developer,
meaning
this
thread
linked
below
each
documents,
the
policy
proposal
and
I.
Guess
our
current
situation
that
we
would
go
with
multi-level
Windows
support
policy.
I
will
say
that
recently,
platforms
based
on
survey
actually
fully
supported
and
tested
the
rest
of
the
platform
supported
but
not
tested,
and
they
will
be
also
platform
sivash.
We
basically
do
not
support.
A
B
C
D
E
So
that
was
kind
of
interesting
but
anyway,
so
the
so.
The
major
change
that
Java
has
made
to
the
released
training
at
least
a
couple
years
now
and
has
been
doing
it,
and
it's
almost
coming
up
to
the
next
LTS,
is
essentially
that
starting
with
Java
9,
they
kind
of
you
can
almost
imagine
that
they've
adopted
Jenkins
is
release.
Schedule
is
essentially
the
way
I've
kind
of
thought
of
it
lately
because,
as
you
know,
with
Jenkins
are
we
have
weekly
releases
where
new
features
can
always
just
go
in
there.
E
But
we
don't
support
old
weekly
releases
because
you
just
get
the
latest
wait
weekly
Reis
right.
Those
are
what
that
would
be.
How
Java
is
when
it
comes
to
versions
like
9,
10,
12,
14,
15
and
16,
15
and
16
in
the
future.
Now
there's
those
special
LTS
releases
now
kind
of
like
how
Jenkins
has
LTS
releases,
where
we'll
just
take
a
version,
every
so
often
tag
that
as
an
LTS
and
then
backport
security
fixes,
and
maybe
some
bug
fixes
or
any
actual
important
things
now.
E
You'll
note
that
the
interesting
comparison
here,
too,
is
well
there's
a
slight
difference.
Comparison
there,
I
guess,
is
because
Jenkins
versus
open,
JDK,
Jenkins
does
distribute
binaries
of
Jenkins
I
mean
we
kind
of
need
to,
especially
for
on
the
java
web
start
old,
stuff
and
everything
anyway,
whereas
open
JDK
only
released
the
source
code
still
while
they
do
coordinate
strong
directly
with
all
the
various
distributions
that
are
creating
binaries
from
it,
like
it,
OpenJDK
Oracle's,
JDK,
Zulu
and
and
millions
of
others.
Now,
essentially,
these
all
just
come
from
open
JDK.
E
So
with
that
in
mind,
the
new
LTS
schedule
is
to
essentially
stabilize
around
every
three
years
or
every
six
releases,
basically
of
those
updates
so
kind
of
similar
to
where
at
Jenkins,
where
we'll
take
like
every
X
amount
of
weekly
releases
becomes
a
new
LTS
release.
They
are
barely.
It
is
a
fairly
stable
cadence
like
that,
except
we're
a
little
more
fine-grained
compared
to
the
two
Java
but
I
mean
Java
is
a
programming
language.
It
still
has
to
release
a
little
slower
than
us.
E
So
in
that
regard,
there's
a
couple
strategies
to
you
actually
staying
up-to-date
with
Java.
So
for
one
you
want
to
make
sure,
of
course,
that
you're
at
least
supporting
the
LTS
release,
because
that's
what
people
may
be
running
in
production
more
likely,
however,
if
you're
not
actually
using
the
LTS
release,
which
you
always
want
to
be
doing,
is
using
the
latest
version.
Just
like
you
would
be.
E
You
know
in
at
Jenkins
weekly
release,
because
if
you
were
using
two
weeks
ago
release
and
you
had
a
bug
that
was
fixed
last
week-
I
don't
care
right
and
neither
does
neither
does
open
JDK.
If
you
found
a
bug
in
Java,
13
they'll
be
like
sorry,
Java
14s,
the
current
version.
You
know
it's
like
you
can
either
report
it
to
Java
11
or
the
latest
version.
Basically,
and
then
what
Java
17
comes
out,
you
know
they'll
start
slowly,
I'm
planning,
support
or
whatever,
but
here's
the
fun
part.
E
The
second
aspect
of
this
is
that
now
that
Oracle
has
tried
to
de-emphasize
their
own
central
role
in
Java
it
basically
kind
of
while
they
still
are
the
primary
supporter
and
primary
funders
of
development
and
that
sort
of
thing
they
that
still
opens
the
possibility
to
all
the
other
companies
that
work
on
the
jdk
and
maintain
their
own
distributions
to
make
their
own
LTS
releases
if
they
want
to.
So
this
is
where
things
could
potentially
get
complicated
in
the
future,
but
they
aren't
yet.
E
But
the
the
gist
of
the
LTS
thing
is:
there's
a
so
there's
a
couple
things
to
keep
in
mind
about
the
LTS
schedule,
so
kind
of
kind
of
like
in
Jenkins
new
features
pop
up
in
an
LTS
release
based
on
whatever
things
were
sort
of
in
there
at
the
time.
Right
and
that's
kind
of
how
Java
will
we
know
so
in
that
in
that
Mayan
you
know
how
upgrading
from
Java
eight
to
nine
kind
of
sucked
well
going
from
9
to
10
10
to
11
and
so
forth
should
actually
be
trivial.
E
E
So,
let's
say,
for
example,
you
download
a
Java
14
today
right
and
you
want
to
try
out
the
new
records
feature
and,
let's
say
Java
15
comes
out
in
a
few
months,
and
that
feature
was
still
a
preview
feature
and
they
want
to
fix
and
they've
changed
something
about
it
backwards
incompatible,
but
the
thing
it
was
it
was
a
preview
feature
that
you
had
to
feature
fly
again
now.
If
you
had
relied
on
that
and
and
kind
of
ignored
that
update,
then
the
next
you
know,
basically
the
following
update
might
completely
remove
it.
E
For
example,
I
mean
like
well
in
it:
okay,
H
I'm,
mixing
two
things,
one:
they
might
remove
the
next
release
or
change
it,
because
it
was
a
preview
feature.
So
there's
that,
on
the
other
hand,
there's
the
new
deprecation
policy.
I
think
this
is
probably
more
important
to
consider
is
up
until
recently,
Java
has
never
removed
anything
that
was
deprecated
I,
don't
think
ever
at
least
from
the
standard
JDK.
However
they've.
E
Finally,
wised
are
changing
that
after
they
modularized
Java,
so
there
is
actually
I
mean
besides
the
fact
that
they've
stopped
bundling
all
everything
besides
the
base
by
default,
which
is
something
we
already
had
to
deal
with
now.
You
know
now
they're,
actually,
finally,
slowly
trying
to
get
rid
of
some
of
the
old
deprecated
classes
and
the
way
this
works
is
they'll
essentially
mark
something
for
deprecation
in
one
release
and
it
will
tell
and
basically
it'll
be-
and
there
can
be
like
another
release
or
two
between
its
removal.
E
E
Java
17
comes
out,
it's
still
in
there,
you
use
it
and
then
Java
18
it's
gone
and
let's
say
you
never
test
any
version
of
Java
between
17
and
23,
and
then
23
comes
out
and
you're
like
hey
where's,
my
it's
like
well,
you
should
have
you're
supposed
to
keep
trying
it
out
on
the
new
versions
to
see
where
your,
where
your
went
so
essentially
on
it,
like
did.
The
big
change
of
the
versioning
number
is
like,
as
they
tried
to
explain
that
and
various
blog
post.
E
This
is
kind
of
similar
to
what
they
used
to
do
in
like
Java
8,
when
they,
the
number
after
the
you
would
increase
by
20
every
time
they
had
like
a
major
update
like
this.
So
it's
like
8,
you
28,
you
48,
you
60
and
those
are
now
equivalently,
9,
10,
11
and
so
forth,
except
now,
they're
now
they're
less
strict
about
what's
allowed
in
the
release,
though
so
imagine
so,
I
guess
you
could
imagine
if
Jenkins
weekly
releases
before
didn't
allow
new
features.
E
Imagine
if
we
had
like
some
sort
of
master
branch
that
was
collecting
all
the
new
features
and
weekly
releases
were
only
like
bug,
fixes
and
stuff,
and
then
the
LTS
releases
were
the
ones
that
came
out
with
the
big
featured
a
big.
The
big
bang
feature
release,
that's
how
Java
used
to
work
and
and
as
anyone
who's
been
working
in
Java
for
long
enough
knows.
That
has
been
terrible,
but
you
know
Big
Bang
releases,
a
Java
has
been
horrible.
E
You
know,
like
I,
I,
wasn't
programming
professionally
back
when
a
Java
4
to
5
or
1
to
4
to
5
with
generics
or
the
Java
6
to
7
or
Java
7
to
8,
or
some
of
these
I've
been
on
for,
but
you
know,
they've
they've
always
been
a
huge
hassle
for
various
legacy.
Software
and
and
this
whole
released
cadence
is
supposed
to
actually
help
prevent
that
issue.
B
E
I'm
thinking
some
sort
of
like
some
full-on
integration,
tester
and
like
a
periodic
basis,
would
probably
be
good
enough
for
now,
because
it's
mostly
techtronic
I
would
imagine
in
a
lot
of
the
issues
if
they
would
come
up,
would
be
caught
in
compile
time
because
we'd
be
like
hey.
This
thing
doesn't
exist
anymore
or
hey.
You
know
this
thing
changed,
I'm
I
know,
I've
been
bit
by
issues
of
the
pike
offer.
Api
has
changed
a
little
bit,
for
example,
between
Java,
eight
and
and
newer
versions
like
they.
E
They
changed
into
long
to
make
it
actually
support.
You
know
more
two
gigabytes
of
memory,
for
example,
and
and
things
like
that
can
trip
you
up.
If
you're
not
actually
cross,
compiling
I,
guess
you
could
say,
and
then
I
guess,
there's
also
I,
don't
think
Jenkins
has
head
to
you
resort
to
using
this
yet,
but
one
other
tool
that
we've
used
like
in
log4j,
for
example,
is
the
maven
toolchains
plugin,
which
allows
you
to
configure
multiple
j
decays
to
run
in
a
single
maven
build.
E
We
basically
had
to
do
that
in
the
past
so
that
we
could
continue
supporting
java.
Is
our
baseline
but
we'd
also
have
some
specific
java,
9
or
even
java.
11
know,
I,
guess
specific
version,
specific
code
that
gets
bundled
in
using
the
new
version
specific
code
feature
of
of
Java
I
will
note
that
the
IDE
support
is
fairly
lacking
in
a
maven
tool.
Change
thing,
I
mean
it
mostly
works.
It's
just
there's.
No,
it's
it's
not
convenient
I
guess.
E
So
it's
something
like
gum,
I've
seen
one
of
the
workarounds
we've
done
here
is
someone
I
forget
who,
but
somebody
had
written
in
a
small
little
library
like
a
fields,
access
or
type
of
library
for
the
Java
11
migration,
so
it
to
avoid
developer
issues
too.
If
you
ever
need
to
make
Java
9
plus
specific
code
to
pull
in,
you
could
try
and
make
it
into
a
multi
version
jar,
basically,
and
and
instead
of
having
it
directly
in
your
project,
just
to
just
to
make
it
a
little
easier
to
edit.
E
C
C
If
we
try
building
on
java
jdk
14
it
won't
be
built
as
well,
is
on
GT
k12
Inc
didn't
build,
it
did
run,
but
not
so
supporting
new
Java
versions
is
quite
expensive,
and
if
you
want
to
do
that,
we
actually
need
a
team
behind
that
say,
for
example,
Java
11
support.
We
had
almost
50
contributors
at
different
stages.
We
were
contributing
that
always
the
yeah.
If
somebody
was
working
on
that
but
say
just
one
day
a
week,
we
could
pull
it
off,
but
still
it's
quite
difficult.
What
we
have
imagined
is
roadmap.
C
E
About
the
graafian
ones,
you
know
that's
another
challenge,
I'm
I've
been
facing
like
for
Jay
as
well,
mostly
around
reflection,
because
they
didn't
fully
support
the
reflection.
No,
they
don't
fully
support.
The
new
reflection.
Api
is
I
should
say
they
support
each
standard
old
ones,
but
the
you
know
the
high
performance
method
handles
var
handles
all
the
other
handles.
Those
are
all
too
low,
too
low
level
for
all
VM
to
understand
at
the
moment.
So
yeah
Jenkins
over
be
a
very
interesting
project
to
get
working
in
that
system.
E
Yeah
right,
but
I
see
that
would
be
long-term.
What
is
there
a
way
that
we
can?
So
you
said
it?
You
said
yeah,
even
at
least
been
able
to
run
Jenkins
with
the
newer
version
of
Java
in
the
past
right,
so
is
there
a
way
that
we
can
kind
of
run
some
basic
tests
with
Jenkins
on
the
latest
JDK
just
running
it
not
necessarily
building
it,
because
I
mean
every.
C
In
the
yes
and
actually
it's,
this
is
what
you're
doing,
for
example,
when
you're
working
on
Java
we
want
support.
So
what
can
this
is
that
wait?
Oh
did
presentation,
but
it
summarizes
major
obstacles
we
hit
when
we
it
wasn't
building
finishes,
we
heat.
So
if
you
want,
you
can
go
through
this
presentation,
but
you
know
there
is
just
a
lot
of
different
a
hidden
stalls.
C
So,
for
example,
we
started
from
building
kanji
dk8
and
running
kanji,
DK
11
and
actually
didn't
quite
work,
because
we
have
a
lot
of
magic,
for
example,
again,
management
of
extensions
and
management
of
annotations
and
the
GDK
level
flow.
We
just
got
enabled
in
version
2.1
64,
and
before
that
you
wouldn't
be
able
to
reach
the
11
at
all,
because
it
would
not
start
same
for
plugins.
Oh
yeah,.
C
E
So
so
it
probably
I
would
hope
that
we
can
try
to
look
at
this
before
Java
17
I
mean
that's
a
while
from
now,
but
you
know
a
while
will
creep
up
pretty
fast.
You
know
to
at
least
make
sure
that
to
get
an
idea
of
what
kind
of
work
me
may
or
may
not
be
necessary
for
building
on
Java
17
in
the
future,
yeah
Hey,
so
some
sort
of
period
just
smoke
testing
if
just
running
it,
yes,
well.
C
C
The
Java
8
for
several
years
before
Joanne
was
released
and
once
Java
9
was
released.
Mr.
t
be
getting
some
issues
from
users
because
he
a
giovanna
and
is
completely
different
from
Java
8,
and
nothing
could
really
work
and
dreams
for
2017
countries
that
there
was
a
first
experiment
way
back
east
matters
and
menarche
who
tried
running,
create
and
reported
a
number
of
issues.
So
we
started
yeah.
C
There
is
just
the
kind
of
words
we
agree
that
we
don't
want
to
open
it
yet
and
sometime
afterwards,
several
months
later,
we
started
discussing
it
in
the
community
and
finally,
we
had
this
in
it
only
made
solvent
again
when
there
was
a
lot
at
the
age
of
10
released
me
discover
that
yeah.
There
is
a
lot
more
issues,
we
discussed
it
in
the
community
and
finally,
we
when
online
hackathon
in
June
2018
way
we
work
on
Java
10
support.
We
had
almost
30
contributors
at
this
hackathon
III.
C
Yeah
I
bet,
if
you
participated
also
so
this
was
our
main
resource
investment
way.
We
pushed
all
common
obstacles
and
we
fix
the
issues
on
the
table.
So
we
made
fight
line
of
work
in
a
minute
blows
on
the
work
and
all
that
common
components
and
five
days.
But
again
it's
requite
a
lot
of
contributors,
but
it
was
just
a
Java
10,
another
blog
post
cetera.
C
So
you
can
find
this
information
on
the
Gennie's
website.
Then
we
had
make
Java
11
release
candidate
and
jinkies
was
running
well
on
the
release
candidate
and
who
were
the
last
moments
because
they
introduced
some
changes
and
actually
a
broker
update,
Center
project.
So
when
we
had
Java
11
hug
fest
after
Jenkins
fault,
I'll
be
forging
after
doing
his
fault.
C
So
then
you'll
beg
me
mark
and
several
other
contributors
spent
more
time
to
expand
testing
and
to
close
their
areas,
and
actually
we've
got
a
prototype
working
on
Java
11
in
just
three
days
before
G
evasion.
Some
J
was
on
25th
of
September,
but
it
wasn't
to
the
end
because
after
that
we
need
to
preview
any
big
bigger
than
general
availability
in
retail.
C
In
general
really
built
in
LCS-
and
these
took
us
six
months
and
actually
yeah-
it
took
us
six
months
to
get
working
prototype
to
G
because
of
because
of
fixing
called
jcd
problems
in
Jenkins
because
of
hits
in
developer
two
issues.
We
also
discovered
some
regressions,
for
example,
Java
XML
by
on
removal
which
broke
but
record
configurations,
even
if
we
removed
him
from
Jenkins
core
and
over
these
six
months,
which
they
had
a
number
of
inhibitors
working
and
thanks
to
Cobb
nice
team
working
on
that
just
a
little
bit
it
over
the
line.
C
E
C
E
That,
after
I'm,
hoping
that
Java
has
or
OpenJDK
has
stayed
true
to
their
word
and
since
Java
11
has
made
the
updates
easier
or
has
made
them
less
breaking,
but
you
know
you
I,
think
you
raised
a
fairly
interesting
point
here.
This
is
something
that
I've
noticed
in
two
of
my
own.
Lack
of
keeping
up
to
date
sometimes,
is
that
one
of
the
nice
advantages,
though
up
to
this,
is
a
of
this
release
process
now
that
they
have
is,
if
you're,
actually
trying
out
the
early
access
releases
like
that
or
the
release
candidates.
E
If
you
notice
regressions
or
changes
like
that,
and
you
can
report
them
upstream
early
enough,
they
might
actually
fix
it,
whereas
if
you
don't
ever
test
it
until
after
its
release
and
you
go
and
complain,
they'll
be
like
well,
where
were
you
when
we
were
developing
that
feature?
We
don't
hear
anymore
already
five
releases
past
that
you
know.
C
E
Said
well,
yeah
I've,
seen
that
same
I've
seen
that
same
subscription
on
well
I
mean,
of
course,
we
had
unlocked
for
J,
but
we
have
I
used
to
be
I
used
to
be
on
the
ant
mailing
list
too,
and
of
course
they
were
I
mean
they
were
one
of
the
they
were.
Usually
the
project
I
would
at
least
try
to
integrate
the
newest
Java
stuff
first,
because
they're
like
well.
We
want
to
make
a
Khmer
things
compile
want
to
support
the
new
compiler
features.
C
Technically
is
a
member
of
this
project
ago.
We
are
supposed
to
test
in
this
new
versions,
and
this
is
something
we
probably
need
to
discuss
at
the
Jenkins
port
level.
So
at
some
point,
I
kiki.
Basically,
and
we
need
it
us
and
it
will
be
needed
but
say
if
you
want
to
really
deliver
on
this
process.
It's
actually
a
good
thing
to
do
in
principle.
C
But
again,
if
we
have
contributors
were
numbered,
for
example,
Java
11
migration,
just
didn't
just
fix
a
javelin
support,
helped
us
did
the
entire
tool
chain
and
it
helped
us
to
introduce
new
features,
for
example
dependable
in
our
developer
tools,
because
many
issues,
if
they
came
from
upstream
and
weekly,
it
really
moved
a
lot
of
technical
depth
in
the
project.
Are
you
doing
Java
level
support
so.
E
Not
that
kind
of
a
tough
decision
to
make,
though
I
mean
I
like
depend
like
of
how
often
to
do
that,
because,
following
the
LTS
schedule
of
Java
sort
of
makes
sense,
because
it's
every
three
years,
but
it
also
depends
on
how
much
changes
each
time.
So
in
principle,
it
would
be
best
if
we
can
do
some
minor
adjusting.
C
So
I
I
agree
in
principle
in
practice.
There
is
one
issue,
extremely
a
slow
adoption
of
Java,
11
and
then
I
think
beyond
to
Java
8.
So
our
current
installation
rate
for
javelin
is
less
than
1%
for
Jenkins
and
it
actually
reflects
the
industry
state.
So
we
need
tools
etc.
They
still
run
on
Java
8
and
it's
basically
fine.
Even
if
we
know
in
principle
the
javelin
is,
but
it
shows
better
benchmarks.
C
So
until
we
let's
say
switch
docket
images
by
default
to
Java,
you
shouldn't
expect
a
massive
adoption
right
and
yeah
investing
killed,
supporting
new
generations
again
is
good
in
principle,
but
I'm
not
sure
how
Wyatt
is
our
target
audience
for
that,
and
whether
we
could
invest
better
but
in
other
areas.
So,
for
example,
expanding
platform
support.
A
C
A
E
Like
straight
you
know,
Java
jar,
Jenkins
and
dot
ward
types
of
things
that
work
fairly
well.
For
me,
at
least
with
whatever
newer
version
of
Java
I've
had
at
the
time
I
mean
I.
Don't
think
this
computer
has
like
practically
of
a
version
of
Java
installed
like
I,
do
on
my
other
one,
but
you
know
like
a
it,
and
also
part
of
this
too
is
I
also
recently
realized
that
homebrews,
the
brute
casks,
actually
are
updatable
to
nowadays,
so
I'm
actually
able
to
keep
my
jdk
up-to-date
automatically.
E
So
that's
also
helping
me
try
to
stay
a
little
more
up
to
date
on
seeing
things
are
incompatible.
Even
if
I'm,
not
you
production,
oh,
and
it
does
remind
me
one
of
the
other
interesting
one
of
the
I
guess
harder
things,
which
is
something
that
we
became,
that
we
see
in
Lockridge
a,
but
it
would
be
the
same
exact
problem
here
is
that,
of
course,
we
want
to
continue
supporting
Java
8,
because
that
is
the
main.
You
know
platform
for
the
foreseeable
future.
E
C
E
So
we
had
that
same
issue.
The
first
time
we
made
a
lot
4j
release
with
a
multi
version
thing.
We
had
complaints
from
people
like,
oh,
my
Android
tooling,
is
blowing
up
and
it's
like.
Well,
it's
not
supposed
to
be
scanning
in
that
folder
and
the
same
story
for
like
800
other
tools
and
and
I'm
sure
you
came
across
like
half
of
the
same
ones
as
we
did,
or
probably
almost
all
same
ones.
Yeah.
E
Now
it's
so
much
better
I.
Remember
the
initial.
The
initial
stage
of
trying
support
multiple
releases,
a
Java
and
stuff
was
basically
oh.
Are
you
using
ant
here's
an
easy
way
to
do
it?
Are
you
not,
oh
sorry?
Well,
here's
it
here's
how
to
do
it!
Here's
how
to
call
aunt
from
maven
white,
so
it
got
super
complicated,
yeah.
E
C
Keep
discussing
this
topic
yeah,
what
exactly
we
do
with
Java
14
really
depends
on
contributions,
because
if
somebody
has
bandwidth
and
interest,
we
can
do
that.
We
fixed
our
infrastructure.
We
can
now
easily
at
a
new
Java
version
so
to
testing
if
needed,
and
we
may
need
it
for
the
purposes,
for
example,
a
new
platform,
so
just
switching
distributions
to
adopt
open
JDK.
What
our
agents
are
actually
already
runs
on
Java
level
and
we
mostly
use
adopt
open
JDK
across
solicita,
but
still
there
might
be
cases
where
you
do
test
multiple
Java
versions.
You.
E
Know
if
there's
a
one
little
feature,
maybe
to
help
get
anybody
excited
about
trying
to
have
a
14
I
just
got
me
excited
from
a
weird
point
of
view,
but
basically
in
Java
14
that
they
have
a
I.
Don't
remember
if
it's
pretty
features
it's
fully
released,
but
basically
they've
updated,
byte
buffer
API,
so
that
you
can
you
you
can
actually
directly
access
nvme
memory
straight
from
Java,
so
that
you
can
do
high
performance
off
heap
type
of
stuff
and
and
whatnot
through
and
not
just
from
RAM,
but
through
nvme.
E
A
A
A
So
Alex
you
can
you
can
chime
in
if
I
make
some
mistake,
Jenkins
to
232
and
to
233
have
both
released
from
the
core
release:
automation,
project
232,
had
some
packaging
bumps
and
bruises
that
were
resolved
in
233,
we've
still
got
more
items
that
will
need
to
be
resolved,
but
it's
making
good
progress.
We're
pleased
with
the
progress
next
stops,
we'll
be
working
on
how
to
do
the
workflow
for
security
releases
and
how
to
do
the
workflow
for
long-term
support
releases.
We're
really
pleased
with
it
be
aware.
A
B
The
one
of
the
items
from
the
core
release
is
that
the
newer
Windows
installer
is
being
built.
There's
still
some
issues,
issues
in
having
the
final
artifacts
uploaded
during
the
release
process.
I
think
Olivier
is
looking
at
that
to
determine
what's
what's
wrong,
so
we're
just
working
through
that
I'm,
adding
some
tests
for
Windows
installer
to
your
install
tests
in
the
packaging
repository
so
I'm
just
working
through
some
issues.
There.
A
E
A
C
Thank
ya
right
before
that.
It
was
inherently
broken
because
we
were
installing
32-bit
to
Java.
So
we
were
running.
You
know,
walk
64
more
by
60
in
Jenkins,
and
we
know
that
there
are
some
limitations,
for
example,
for
Windows
process
management
fiber.
If
you
want
to
tell
many
processes
and
yeah
more
other
things
so
great
to
see
it
finally
winding
excellent.
B
I
we've
talked
about
it
for
a
while
of
integrating
the
plug
installation
manager
tool
into
docker
images.
Since
I
have
a
my
main
docker
platform.
Right
now
is
Windows
I
have
a
Jenkins
master
on
Windows,
PR
and
I'm,
incorporating
the
plug-in
installation
manager
tool
with
good
success
so
far,
so
I'm
just
working
through
some
issues,
then
I'll
push
that
as
part
of
my
PR
for
the
Windows
master
image
and
then
I'll.
Look
at
I
do
have
some
Linux
docker
platforms
and
I
can
then
go
look
at
the
Linux
docker
images
incorporating
that
tool.
A
C
Fully
support
that
I
would
be
interested
to
discuss
the
better
allowed
plan
because
there
are
basically
two
ways:
one
is
just
replace
instantly
install
plugins
a
shell
script.
Another
way
is
to
add
plug-in
manager.
Two
in
parallel
change,
the
documentation
announcer
this
experimental
feature,
but
change
install
plug-ins
SH
only
when
we
are
fully
confident,
but
it
behaves
similarly
because
if
I
recall
correctly,
there
are
some
minor
issues,
for
example,
in
how
dependencies
are
picked
up
and
I'm
totally
willing
to
treat
or
install
plugins
aphasia.
But
maybe
we
should
have
it
as
a
two-stage
process.
We.
B
C
So
I'm
not
sure
what
we
could
do
about
it.
So
obviously
we
can
just
announce.
It
is
what
was
announced
is
duplicated
clunk
ago.
So
I
think
that
just
remove.
It
is
good
approach,
though
I
know
for
sure
that
some
companies
still
use
this,
not
in
the
Jenkins
Center
searching
but
yeah
in
other
use
cases,
so
maybe
just
marking
it.
Let's
duplicate
it,
for
example,
in
the
changelog
and
saying,
and
the
commencement
would
be
a
good
stuff
to
go
there.
A
All
right
next
topic,
then,
was
just
a
reminder
that
the
platform
roadmap
has
been
published
or
has
been
through.
The
governance
board
is
still
in
Oleg
Mutu
college,
still
in
draft
state,
it's
still
evolving
and
growing
and
developing,
but
we've
got
a
number
of
entries
for
them
from
the
platform
sig
on
the
on
the
roadmap,
thanks
very
much
to
Oleg
for
leading
that
effort,
the
the
road
map
looks
beautiful.
C
You
can
see
it
and
yeah
the
most
of
items
actually
aggregated
here,
so
it's
where
this
doctor
supports
or
some
multiple
doctor
images
which
still
need
to
get
over
the
line.
These
flows
open,
June
9
and
you
windows
installer,
which
currently
can
be
moved
to
release
stage
out
from
the
big
it
this
week.
C
Also,
we
have
some
icons
suggest
that
for
the
future,
for
example,
custom
Jenkins
submission
service-
this
is
project
link,
is
the
working
on.
Then
there
are
also
some
packages
for
docker
images
which
we
may
include,
but
the
roadmap
is
mostly
there
and
plugin
management
is
actually
also
included,
but
it's
referenced
in
management
and
administration
site
right
now.
So,
if
you
click
here,
you
still
get
to
the
platform
secret.
This
folder
and
if
somebody
wants
to
provide
better
documentation
and
description
for
this
project
is
also
excellent.
Thank
you.
Yep.
E
A
A
Okay,
so
we've
we've,
we've
delayed
the
use
of
the
s
390x
and
PowerPC
infrastructure.
That
IBM
has
kindly
provided
for
us
on
CI
de
Jenkins
at
IO,
but
it
continues
to
be
used
in
my
test
environment,
so
Jenkins
2.2,
22.2
release
candidate
was
spent
the
last
week
or
more
on
my
test
environment
using
the
PowerPC
and
series
390
system,
390
agents.
So
now
I'm
assuming
Jim,
that
a
first
preference
is
agents
as
first
target
and
someday
in
the
future.
That
they'll
likely
want
to
run
Jenkins
masters.
D
I
think
actually,
prior
the
from
the
interesting
like
from
people
like
my
team,
is
the
master
and
then
Hutchins
there
actually
was
I
was
last
Alex
this.
Today
there
was
interest
in
the
the
agent
the
other
day,
although
he
got
pings
asking.
If
there
was
one
I
looked
at
the
evals,
the
the
you
know
the
docker
hub
eval,
the
user
and
I
didn't
see
any
multi
large
containers
for
the
the
Jenkins
agent
is
that
I
just
saw
like
Windows
I,
think
being
pushed.
D
B
B
A
A
C
Actually,
in
multiple
more
places,
because
we
were
able
to
remove
around
on
her
net
occurrences
from
the
documentation,
but
there
is
a
catch.
So
one
thing
that
we
do
need
three
images.
So
it's
now
dr.
agent
took
in
bout
engine
and
dog
is
each
agent
and
with
dr.
SSH
agent
we
still
have
an
open
question
how
to
name
that.
C
So
that's
why
I
postponed
announcement
a
bit
but
I
think
it's
time
to
proceed
because
I
reached
out
there
is
a
developer
man
increased
threat
where
basically
people,
okay,
would
it
be
SSH
agent
or
SSH
built
agent,
because
most
options
have
for
their
own
advantages
and
disadvantages.
There
was
no
consensus.
There
I
offered
two
ways
to
vote:
nobody
really
stepped
up
and
since
all
linking
its,
including
colleagues
and
humor
country
via
SSH
agent,
based
in
principle,
I
suggest
to
just
take
an
option.
C
A
C
A
problem
because
that
is
apparently
a
docker
image
force
SH
agent,
oh
you're,
not
an
official
one
and
it's
called
something:
/
SSH
agent
I,
don't
think
that
it's
a
big
deal
but
yeah.
Basically
it's
contributor
guess
somebody
wants
to
rename
it
to
a
cessation,
build
agent
or
come
up
with
a
new
name
which
would
actually
good
good
Mobile's
just
a
little
bit
right.
There
was
also
this
HD
agent,
but
basically
it's
exactly
the
same
like
SSH
agent,
so
god.
A
C
So
yeah,
actually
my
question
is:
is
it
a
good
time
to
announce
GE
for
them
because
historically
Windows
say
agent,
the
images
or
in
experimental
status?
We
have
never
announced
that
supported,
but
in
fact
we
ship
them.
We
test
them,
so
anything
else
left
to
do
before
the
unknowns
that
we
support
them.
I
think.
C
A
A
B
Us
on
things
like
Amazon
and
Asher,
you
can
use
docker
images,
so
the
cloud
providers
are
allowing
you
to
use
docker
ice
container
containers
for
build
agents
and
stuff
like
that
with
their
various
plugins
and
so
forth.
So
it's
and
kubernetes
has
support
for
windows
container
pods
as
well.
So
it's
becoming
more
prevalent,
usually.
E
B
E
C
It's
so
one
comment,
probably
something
to
eat
this
before
generally.
If
we
talk
about
health
providers,
to
kind
of
reduce
the
current
agents
on
educate,
hasn't
been
reported,
they
drink
bug
tracker,
yet
I
shaded
in
the
immediate
notes,
but
didn't
treat.
If
you
want
to
use
gke,
we
need
19
online
course
instead
of
1809
so
question
whether
it
makes
sense
to
me
read
before
we
announce
G
so.
B
C
C
Yeah
one
topic,
maybe
for
sig
members,
that
we
want
to
participate
in
the
Google
season
of
dogs,
at
least
we're
doing
best,
a
first
attempt
if
there
are
any
project
ideas
which
are
related
to
platform
support
and
especially
if
the
run
matters
or
interested
to
help
these
projects
then
submit
your
project.
Ids
I
have
just
felt
the
pull
request,
which
creates
a
landing
page.
I
haven't
already
filed
it
all
followed
in
one
minute
but
Jerry.
Well,
we
can
hold
the
communication
specific
project
IDs.