►
From YouTube: Jenkins Governance Meeting May 4, 2022
Description
Jenkins Governance meeting May 4, 2022 with topics including:
* News
* Action Items
* CDF request to survey active maintainers of CDF projects
* Forums and community topics
A
thanks
for
being
here,
remember
that
we
abide
by
the
jenkins
code
of
conduct,
so
topics
for
the
agenda
today,
news
action,
items,
linux
foundation,
survey
and
then
forums
and
topics,
and
those
are
the
only
ones
that
I
had
are
there
other
top,
oh
and
anything
gavin
that
you
want
to
bring.
We
had
plug-in
site
last
time.
Is
there
anything
else
you'd
like
to
highlight
there.
B
A
A
Packaging
has
the
release.
Checklist
is
in
progress,
so
alex
is
running
the
release,
checklist
and
he'll.
I'm
sure
report
when
release
checklist
is
complete.
For
instance,
we
probably
still
need
docker
images,
some
other
things
in
progress,
but
that
I
see
no
reason
why
that
won't
be
a
successful
release.
It
looks
good
thanks
to
everyone
who
contributed.
A
A
A
I
haven't
heard
any
report
back
yet
so
how
about
we
give
me
an
action
item
to
ask
for
a
status
report
on
the
number
of
of
registered
survey
participants,
because
one
of
the
worries
is:
if
they
don't
get
enough
participants,
they
may
not
get.
May
not
understand
what
what
benefit
we're
receiving
or
what
our
maintainers
need.
B
A
Right
good
point,
so
they
don't
know
how
they
will
benefit,
how
they
or
the
project
will
benefit
from
the
survey
right
and
that's
that's
a
good
good
point.
So
if
it's
just
a
a
survey
for
the
joy
of
surveys,
that's
much
less
motivating
than
yeah.
If
we
learn
from
this
survey
that
we
need
to
provide
these
services,
we
might
provide
those
services
good
point,
thank
you
and
you
know
again
for
the
future.
A
The
motivation
for
the
survey
in
the
in
the
survey
invitation,
email,
yeah,
good
point
and,
and
it
points
to
a
problem
I
wasn't
sure
what
the
benefits
would
be.
I
know
they'd
asked
to
do
the
survey,
but
it
wasn't
clear
to
me
what
gain
might
we
receive
from
it?
Good
thanks,
gavin,
all
right,
any
anything
else.
On
the
cva
cdf
request
to
survey
maintainers.
A
B
The
only
one
I
added
was
the
one
at
the
end,
someone
posted
to
the
forums
this
week
that
they
developed
a,
I
think,
a
desktop
application
as
a
drinking
dashboard
and
I'm
always
encouraged
to
you
know,
bring
them
up
when
they
come
up
as
cool
projects.
So
I
have
not,
unfortunately
had
a
chance
to
try
it,
so
I
don't
have
anything
else
to
say
about
it,
but
it
looks
like
a
standard
little
tool
that
shows
a
pretty
high
level
overview
of
your
drinking
server
or
your
drinking
jobs.
A
We
can
hear
you
just
fine
yeah.
Are
you
sorry?
I
got
muted,
okay
got
it
excellent.
So
one
of
the
one
of
the
hot
topics
here
is
the
next
lts
baseline
is
now
we're.
Now,
at
the
point
of
about
three
weeks,
we
are
just
three
weeks
since
the
date
had
been
planned
to
be
selected.
I'd
ask
for
a
two
to
four
week.
Stabilization
period,
we're
now
at
2.3
2.346,
and
it
was
released
on
tuesday
and
fixes
a
few
more
issues.
A
Okay,
next
piece
of
news
for
me
was
that
the
java
on
which
were
based
has
been
rolled.
Recently.
It's
been
released,
a
new
version.
In
particular,
it
was
important
that
we
get
java
1703
out,
because
there
was
a
security
issue
reported
there.
We
didn't
think
jenkins
would
be
affected
by
it,
but
it's
much
easier
to
update
to
a
new
version
of
java
than
to
explain
to
people
why
we're
not
affected
and
have
them
be
persuaded.
A
A
A
I
and
I've
still
got
to
do
those
things
so
that's
still
pending,
but
it
feels
like
september.
Lts
is
a
good
fit
based
on
thanks
very
much
to
the
work
of
basel
crowe
and
others.
Who've
made
made
great
strides
in
assuring
that
the
tooling
is
ready
and
that
we
can
do
java
java,
11
native
builds
in
that
time.
A
A
Right
now,
exactly
which
would
mean
we
would
be
doing
it
in
a
common
pattern
within
the
next
few
weeks.
Now,
I'm
not
sure
we're
ready
to
do
it
quite
that
quickly,
but
it's
it's
in
that
time
frame
right,
because
we
want
multiple.
We
would
like
to
have
a
good
long
period
where
the
weekly
is
already
telling
people
hey.
B
C
A
plug-in
that
that
updates
their
minimum
core
baseline
to
a
release
that
requires
java
11
will
themselves
require
java
11.,
but
the
plug-in
maintainer
has
the
choice
as
to
when
to
update
their
core
baseline
and
most
plug-in
maintainers.
Don't
choose
a
weekly
release
as
their
baseline
in
order
to
give
themselves
access
to
the
widest
yeah
adoption.
I.
B
Mean
you
say
that,
but
also
when
tables
div
came
out,
everyone
did
that
because
they
had
to,
and
it
was
a
very
confusing
and
upgraded
process
because
update
center
isn't
the
greatest
at
saying
why
the
plugin
is
available
just
says
it
isn't
available
for
your
version.
People
are
like,
but
I'm
on
the
latest
version
and
you're
like
yep.
C
So
yeah,
I'm
hoping
that
we
won't
work
that
we
won't
require
any
plug-in
maintainers
to
update
their
baseline
to
a
weekly.
I
think
that
has
been
the
case
for
some
user
interface
changes,
including
tables
to
divs,
as
well
as
some
of
the
icon
changes
that
have
been
done
recently,
but
that
should
not
be
the
case
for
the
java
11
transition.
Yeah.
A
Of
any
more
descriptive
term
right,
good
good
point,
so
so
the
the
idea
there
is.
We
would
roll
to
require
java,
11
and
weeklies,
but
we
don't
mandate
and
there's
no
compelling
reason
for
us
to
mandate
that
plug-in.
Maintainers
must
update
to
use
one
of
those
weekly
versions
as
their
minimum
jenkins
version,
because
there's
not
there's
not
any
any
compelling
reason
that
I
know
of
to
force
that
unless
they
need
to
do
it
for
something
else
like
for
some
ui
change.
B
C
A
A
So
yes,
and
using
september
instead
of
june,
is,
is
we
hope,
a
quieter
lts
with
regards
to
to
ui
changes
right,
so
we've
got
really
important.
Ui
changes
in
june
has
some
really
june.
Ui
changes
are
significant
and
and
really
quite
impressive,
but
they
they
need
more
care
and
more
work.
So
we
didn't
do
didn't
want
to
do
the
the
require
job
11
in
that
same
lock,
step
yeah,
good
point.
B
A
B
B
Right
well
because
I
know
the
one
there's,
the
the
one
that
said
about
boost
the
bootstrap
and
the
class
loader
and
stuff
like
that,
and
I
think
that
the
guava
update
you
know.
If
we
see
that
error,
we
can
just
usually
say
hey.
You
know
we
read
this
form
post
but
remember
to
look
at
this
form
post.
So
I
was
just
thinking.
You
know
something
like
that
where
we
just
know
that
that's
an
error,
you
deal
with
it
this
way.
C
Yeah
I
like
that
idea
and
the
maybe
that
could
be
as
simple
as
linking
to
the
upgrade
guide,
which
ideally
would
have
all
of
that
information.
One
of
the
most
important
pieces
that
I
think
we
need
to
communicate
is
if
a
user
is
having
a
problem.
What
information
do
they
need
to
include
when
they
file
a
bug
report
and
we've
included
that
in
the
upgrade
guide
for
the
guava
upgrade
and
several
other
changes
that
we've
made?
C
So
I
think
the
the
expectation
would
be
that
we
also
include
that
information
here,
oh
tables
to
div.
So
it's
the
other
example.
You
know
we
right
included
that
in
the
upgrade
guide
you
know
when
you
filed
the
ticket
include
x,
y
and
z,
so
having
that
as
a
canned
response
ahead
of
time
would
be
great.
B
I
would
love
to
see
like
a
automated
triage
bot
for
both
the
forms
and
my
github,
where
you
know
I
see
that
you
mentioned
bootstrap
and
close
loader.
I
think
this
is
your
response.
If
it's
not
someone
will
look
at
it
soon.
You
know
because
it's
exhausting
sometimes
to
do
those
initial
triage
right,
that's
a
longer
term
project,
but
you
know
the.