►
From YouTube: Jenkins Governance Meeting July 10, 2023
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
everyone:
this
is
Jenkins
governance
board
meeting,
it's
the
10th
of
July
2023.,
thanks
for
being
here,
topics
I've
got
on
the
agenda
for
today
include
news
and
action
items
and
Community
activity.
I,
don't
have
any
other
topics
other
than
those
three.
Are
there
any
topics
that
need
to
be
added
to
the
agenda
other
than
those
three.
A
So
first
topic
was
the
news
item.
Thanks
to
Chris
Stern
and
Alex
Brandis
and
others
Jenkins
2.401.2,
released
on
time,
June
the
28th,
the
next
LTS
Baseline
will
be
selected
two
days
from
now,
Wednesday
2.414
looks
promising.
2.413
looks
good,
so
looking
forward
to
that,
and
thanks
in
advance
to
Chris
Stern
for
his
work
on
2.401.3
that
will
be
coming
up
at
the
end
of
this
month.
A
A
A
I've
also
started
the
retrospective
on
the
signing
certificate
renewal
process,
and
this
is
a
long
list
of
historical
items
and
mistakes
at
a
number
of
points.
There's
still
plenty
to
do
here
to
think
through
this
to
work
through
it
and
to
be
ready
to
present
it,
but
others
are
welcome
to
comment
on
this
document
to
to
offer
their
insights
Etc.
There
are
plenty
of
things
that
went
wrong
in
the
signing,
signing
certificate,
updates
and
lots
of
ways
we
can
improve.
A
Two
open
two
action
items
that
had
no
progress:
the
conversion
from
sub
projects
as
sigs
to
working
groups;
I've
not
done
it
yet
there's
a
lot
of
work,
hiding
there
and
retiring
the
Jenkins
Chinese
documentation
site.
The
first
step
has
been
done
in
that
the
Chinese
link
is
gone
from
the
top
level
page,
but
the
Chinese
pages
are
still
responding
and
I.
Think
that
still
gives
us
the
risk
that
Chinese
users
will
follow
installation
instructions
in
Chinese
that
are
simply
wrong.
B
A
Not
just
search
engines
from
bookmarks
from
all
sorts
of
places
where,
where
Chinese
content
is,
is
still
there
and
some
of
the
pages
are
valid
if
they're,
unchanged
from
when
the
translation
was
done.
But
the
install
guide,
for
instance,
is
completely
different.
There's
no
no
update
for
system
D
in
the
Chinese
install
pages,
so
they're
completely
perplexed
when
they
read
the
instructions
there.
B
I
just
wanted
to
mention
a
related
topic.
It's
part
of
the
work
on
as
part
of
the
work,
I'm
upgrading
HTML
unit
and
generally
modernizing
plugins
that
deprecated
the
translation
assistance
plugin,
because
it
was
several
years
since
it
was
last
updated
and
released,
and
also
because
the
server
that
it
was
transmitting
translations
to
has
been
shut
down
for
a
very
long
time.
B
So
you
know
I'm
not
really
sure
what
the
status
of
our
translation
infrastructure
is
because
I
know
that
there
were
some
efforts
to
some
efforts
to
use
that
that
new
service
I
think
it
was
called
crowded,
but
I'm
not
I'm,
not
sure
how,
if
that's
something
that
we're
still
using
or
if
it
is
something
that
we
are
using.
B
If,
if
it's
documented
anywhere
or
if
it
kind
of
works
out
of
the
box,
because
this
translation
assistance
plug-in
was
very
well
integrated
with
Jenkins
I
mean
you
could
just
go
to
the
bottom
of
any
page
and
click
a
button
and
start
translating
things
so
I
don't
know
if
it's
quite
that
simple
with
crowd
and
if
you,
if
you
have
more
steps
that
you
need
to
go
through
and
if
those
are
documented
somewhere
but
but
yeah
I,
think
in
general
I
think
we
have
decent
infrastructure
for
translation.
B
You
know
in
when
we
move
to
Java
11.
We
we
migrated
to
utf-8
for
all
of
the
properties.
Files
in
Jenkins,
core
and
I
think
that's
helped
a
lot
of
people
because
they
don't
have
to
deal
with
the
encoding
problems
that
we've
had
in
the
past.
So
we've
made
some
progress
there,
but
yeah
in
general
in
general,
I
think
there
might
be
some
more
polish
that
we
could
add
to
the
whole
translation
infrastructure,
although
I
think
I
think
crowding
is
working
pretty
well
overall.
A
C
Yeah
to
comment
on
the
translation,
I
think
translation
assistance.
Plugin
is
the
proper
name,
the
server
for
that
shutdown
like
in
2020,
or
something
like
that.
But
you
could
or
still
can
use
the
plugin
locally
to
submit
translation
proposals
to
the
local
instance.
Jenkins
runs
on,
but
you
can
no
longer
contribute
the
spec
to
the
plugin.
C
In
case
this
is
a
valid
use
case
for
some
people,
but
I
just
check
they
are
like
12
or
13
plugins,
using
the
12
plugins
using
crowded
at
the
moment,
integrated
with
GitHub.
If
I
see
that
correctly
so
I
think
that
builds
a
solid
base,
but
yeah
you're
right,
Jenkins
score,
isn't
integrated
with
it.
Yet.
A
Well
and
I
I
admit
I'm
quite
impressed
with
cloud
in
because
what
it
it
is
not
as
tightly
integrated
with
the
Jenkins
experience
as
as
the
translation
assistance
plugin
was,
but
it
provides
translation
memory
and
translation
suggestions
that,
at
least
for
me
as
a
as
a
as
a
poor
speaker
of
Italian.
It
does
a
much
better
job
for
me
than
the
translation
assistance.
Plugin
did
no
I'm
I'm,
probably
the
wrong
person
to
do
Italian
language
translations.
You
can
hear
from
my
my
accent
that
I
do
not
have
an
Italian
accent.
C
Yeah
that
works
basically
out.
It
remembers
what
you
have
submitted
to
other
plugins
and
other
projects
within
crowded
and
offer
suggestions
matching
the
context.
Something
is
in
also
I
have
to
admit.
I,
don't
really
know
how
the
translation
assistance
plugin
used
to
work
under
the
hood,
so
my
knowledge
is
pretty
limited.
There.
A
A
All
right
thanks,
Basel
next
topic,
then
was
Community
activity,
and
here
this
is
just
my
poorest,
my
poor
summary
of
how
things
have
been
happening
in
the
community
in
the
last
two
weeks,
so
that
we
had
four
Google
summer
of
code
projects.
That's
presented
their
midterm
evaluations.
Last
Thursday
recording
is
available,
along
with
the
slides
thanks
to
all
four
thanks
to
those
who
mentored
and
are
mentoring,
the
projects
will
continue.
Midterm
evaluations
are
due
to
Google
by
this
Friday
and
the
Jenkins
project.
A
The
artifactory
bandwidth
reduction
project
needs
more
progress
right
now.
Jfrog
has
asked
us,
please
it's
time
to
lock
the
it's
time
to
prepare
for
the
the
future
state,
where
the
cached
repositories
like
repo
one
like
the
eclipse
jkit
repository,
are
private
instead
of
public,
and
so
we've
got
to
do
a
series
of
evaluation
changes,
modifying
parent
Palms,
with
prototypes
to
switch
from
Reading
from
repo.jenkinsci.org
to
instead
read
from
each
of
the
provider
repositories.
A
The
jget
repository
repo
one
Etc
they're
willing
to
allow
us
to
continue
to
use,
have
the
cached
copies,
but
they
need
to
be
private
so
that
if
we
need
to
use
them
ourselves,
we
have
to
authenticate
to
repo
in
order
to
use
them
any
questions
on
the
bandwidth
reduction
project.
That's
one
that
has
me
worried,
but
we've
we're
making
we'll
be
making
progress
over
the
course
of
the
next
month
or
two.
A
A
It's
been
all
references
to
it
have
been
removed
from
Jenkins
core
and
a
feature
flag
has
been
implemented
that
allows
a
Jenkins
core
user
to
actually
turn
off
prototype
completely
now
right
now
that
doesn't
help
much
because
there
are
some
key
plugins
that
have
not
yet
integrated
and
released
their
removal
of
prototype.js,
and
you
can
see
the
status
of
those
in
this
tracking
sheet
thanks
very
much
to
Basel
and
to
to
others
who
are
maintaining
this
puzzle.
I
think
it
may
just
be
you
whoever
it
is.
Thank
you.
Thank
you.
A
It's
a
beautiful
piece
credentials
and
declarative
pipeline
are
the
two
really
big
ones,
and
then
we
get
down
into
the
still
big
ones,
but
not
as
big
get
parameter.
For
instance,
Basel
I
think
you've
submitted
an
adoption
request
for
that,
one
so
that
one's
coming
others
further
down
need
more
and
more
more
work.
B
C
B
Is
this
is
looking
a
lot
better
this
week
than
in
previous
weeks,
and
if
you,
if
you
go
back
to
that
list,
I
can
I
can
give
some
updates
pipeline
model
definition.
I
need
to
change
that
to
Yellow
because
it
was
merged
over
the
weekend,
but
it
still
hasn't
been
released
yet
similar
to
Blue
Ocean
and
get
parameter.
B
B
Uno
Choice
we've
got
a
contribution
from
the
community
which
I've
already
proved
and
which
is
simply
awaiting
a
little
bit
more
testing
by
the
maintainer
before
it's
merged
and
released,
but
I
think
we're
looking
very
good
with
that
one.
So
many
thanks
to
to
Rahul
for
contributing
that
fix.
It
was
a.
B
It
was
a
fairly
difficult
change
to
implement
and
I
was
really
happy
to
see
how
this
one
turned
out,
because
we
also
added
or
I
should
say,
Rahul
also
added
a
lot
of
automated
front-end
testing
prior
to
developing
this
fix
so
we're
in
a
lot
better
shape.
Maintaining
this
plug-in
now
and
in
a
much
more
confident
state
to
implement
future
refactoring
and
and
other
changes,
so
yeah
Uno
choice
is
looking
pretty
good.
B
I've
also
got
an
adoption
request
for
categorized
view,
which
might
take
another
week
or
two
to
clear,
but
that
one
that
one
should
also
be
in
good
shape
once
I
get
release
permissions
most
of
the
items
below
categorized,
View
I
still
don't
have
pull
requests
open.
The
docker,
Hub
notification
plug-in
is
maintained
by
some
cloud-based
internal
team
and
I
have
also
pinged
that
team,
so
that
one
I
think
should
be
okay,
but
the
ones
that
I'm
worried
about
are
mostly
corporate
maintained.
B
Plugins,
like
fortify,
is
maintained
by
a
corporate
team,
not
not
a
cloud-based
one,
but
some
other
company
and
similarly
synopsis
coverity
is
another
corporate
maintained,
plug-in
same
with
q-test
same
with
openstack
openstack
Cloud
same
with
as
your
app
service
same
with
Oracle
Cloud
infrastructure
compute
same
with
chat
work,
so
I'm
not
really
sure
how
we
should
approach
these
in
the
long
term,
because
it's
almost
impossible
for
a
Community
member
to
go
and
test.
These
changes.
B
They're
typically
Integrations
with
some
sort
of
third-party
software,
you
know
whether
that's
fortify
or
q-test
and
without
access
to
these
proprietary
packages,
it's
almost
impossible
to
do
testing
if
these
changes.
B
So
these
really
need
to
be
done
by
someone
who
uses
the
Plug-In
or
by
the
corporate
teams
that
have
developed
these
Integrations,
and
so
that's
why
I
haven't
submitted
any
pull
requests
to
them
at
the
same
time,
I've
gotten
very
little
in
the
way
of
responses
to
the
various
issues
that
I've
filed
where
I've,
where
I've
asked
some
of
these
corporate
teams
to
take
a
look
at
the
use
of
prototype
and
I.
B
Well,
that's
that's
one
of
my
theories
anyway,
but
yeah
I'm,
not
sure
what
we
could
do
to
more
strongly
encourage
these
corporate
teams
to
tackle
the
Prototype
removal,
but
I,
don't
think
it's
something
that
a
Community
member
could
Implement
without
actually
being
a
user
of
this
software.
Unfortunately,
so.
A
A
D
Yeah,
so
development,
wise
or
as
the
kind
of
problem
is
similar
to
tables
to
divs.
No,
so
I
don't
remember
exactly
how
we
went
about
there,
but
I
think
we
set
a
date
that,
at
this
point,
tables
to
this
will
be
merged.
Your
plugin
will
needs
to
be
adapted.
D
We
will
file
the
issues
for
you,
we'll
we'll
take
care
of
the
most
popular
plugins
and
after
that
it
was
up
to
the
maintainers
I
mean
with
these
many
plugins
and
the
problems,
and
actually
you
know
not
being
able
to
test
any
potential
changes
that
we
might
be
able
to
submit.
This
is
the
basically
the
only
way
to
go
about
doing
that.
B
We
don't
have
to
decide
it
right
this,
the
second
but
If
people
could
start
thinking
about
what
timelines
would
make
sense.
I
think
that
would
go
a
long
way
as
Daniel
just
alluded
to
you
know
once
once
we
have
a
better
timeline,
then
that
would
be
strong
motivating
factor
to
address
these
issues
and
I
I.
Don't
think
that
this
could
be
done
for
the
next
LTS
release
would
be
something
that
we
could
only
consider
for
the
the
LTS
following
the
next
one
at
the
earliest.
But
yes,.
A
B
Yeah
or
or
the
one
after
that
I
mean
I'm,
not
in
a
hurry
to
to
do
this,
but
whatever
whatever
we
decide
on
was
something
that
we
should
communicate
very
clearly.
So.
D
So
we
we
have
a
little
more
flexibility
than
with
tables
to
divs.
If
I
remember
correctly
there,
we
decided
to
basically
merge
the
change
immediately
after
the
LTS
cut
off
so
to
have
the
most
weekly
releases
before
we
cut
the
next
LTS
Baseline
to
take
care
of
regressions.
This
change
looks
extremely
safe
and
well
understood,
and
it's
in
core
already
as
an
optional
flag.
So
I
don't
think
that
problem
applies
there.
So
at
any
point
in
the
next
three
months
should
be
fine.
In
my
opinion,.
B
Yeah
I
mean
I
also
am
aware
of
some
proprietary
plugins
that
need
to
be
adapted
that
are
not
on
this
list,
because
they're
not
open
source.
But
that's
that's
why
my
my
gut
feeling
is
that
the
next
12
weeks
would
be
fairly
aggressive
and
it
might
need
to
be.
You
know
the
next
24
weeks
that
were
looking
at
rather
than
the
next
12
weeks
to
be
to
make
sure
that
everyone's
really
on
board.
D
Well,
next
12
weeks
means
it
will
be
in
LTS
within
18
weeks,
right,
yeah,
also
something
to
consider.
B
Yeah
well
I
think
this
ultimately
comes
down
to
who
wants
to
be
driving
this
effort
to
remove
it
from
core
and
I've
haven't
been
taking
that
role
myself,
because
Tim
has
the
draft
pull
request
to
switch
off
the
flag,
so
I
wanted
to
make
sure
that
others
are
involved
in
the
conversation,
but
yeah,
it
seems
seems
like
the
sooner
we
can
agree
on
when
we
want
to
do
this.
The
better
and
I
don't
want
to
make
that
decision
myself.
A
I
think
that
makes
sense,
so
it
feels
like
it
may
be
a
there.
I
mean
there
are
still.
There
are
still
items
very
high
on
the
list.
That
say
it
would
be
a
really
bad
thing.
If
we,
if
we
merge
that
into
Jenkins
core
right
with
credentials
and
declarative
pipeline,
it
weekly
would
be,
would
be
terribly
disrupted
if
we
merged
too
soon
there,
but
having
the
discussion
and
the
developers
list
at
least
to
say.
Okay,
should
we
should
we
look
forward
and
try
for
a
merge
within
16
weeks
and
and
then
that
conversation
about
okay?
A
I
I
think
that
it'd
be
okay.
If
I
started
that
conversation
Basel,
do
you
you
do
you
have
any
objections?
If
I
start
that
conversation
to
try
to
ask
about
that
just
to
get
people
thinking
about
it,
I
I
think
I
think
you
may
be
right
that
12
weeks
may
just
be
too
aggressive,
given
given
the
number
of
things
that
need
to
be
done,
particularly
not
just
proprietary
plugins
from
my
employer
from
cloudbees,
but
also
proprietary
plugins
from
other
other
large
companies
right
from
synopsis
and
from
from
others.
A
B
Yeah
yeah
I
mean,
if
you're
interested
in
having
that
starting
that
conversation,
that's
fine
with
me.
I
I,
don't
mind
starting
it
either,
but
I
was
just
I
was
just
waiting
until
more
of
these
rows
had
turned
green,
but
yeah
I.
Think
I
think
it's
an
important
discussion
to
have
great.
D
I
was
wondering
about
the
feature
flag.
How
has
your
experience
with
that
been?
Are
we
aware
of
users
who
enable
it
and
just
try
it
or
you
know,
is
there
non-developer
use
of
this?
Do
we
know
that.
A
There's
at
least
one
because
we
had
one
bug
report
in
community.jenkins,
our
one
reporting
community
at
jenkins.io,
hey,
I,
turned
off
prototype.js
and
things
fell
over
badly
and
they
fell
over
badly
because
because
it's
some
very
high
on
the
list,
things
haven't
yet
removed
their
use
of
prototype.js.
So
we
know
there's
at
least
one
usage
of
that
feature
flag
out
in
the
community.
A
E
Okay,
when
we
were
doing
good
Java
support
Etc.
Basically,
this
information
was
added
on
demand
because
we
have
analytics
engine
well,
thanks
a
lot
to
Daniel
and
all
the
contributors,
but
the
data
itself
is
being
conjected
there
on
demand.
E
What
was
mentioning
that
I've
been
actually
working
with
open,
Future
and
open
Telemetry
community
and
I
many
times
I
mentioned
Jenkins.
Has
one
of
potential
adopters
for
future
open
feature
engine
once
it
really
becomes
vendor
neutral.
So
maybe
we
could
integrate
it
to
get.
Some
statistics
on
feature
plugs
in
a
more
genetic
way,
but
it's
well.
It's
definitely
well
outside
this
particular
thing.
A
So
Basel
I
think
you
can
probably
best
describe
it
there.
My
sense
was
that
puzzles
expect
well,
I'll
be
quiet,
Basel
I'd
rather
have
you
say
it
in
your
words
than
me
say
it
in
mine.
B
Sure
I
feel
very
strongly
that
anything
with
more
than
a
thousand
installations,
with
with
very
few
exceptions,
should
be
green
on
this
spreadsheet
and
so
I
from
my
personal
quality
bars
that
there
needs
to
be
a
fairly
strong
justification
for
anything
that
has
more
than
a
thousand
installations
to
be
not
green
and-
and
there
are
some
of
these
exceptions
like
the
translation
assistance
plugin,
which
I
deprecated
and
there
may
be
other
exceptions
to
that,
and
but
even
even
the
things
that
are
below
a
thousand
I
still
try
to
look
at
them
on
a
case-by-case
basis,
and
some
of
them
are
truly
abandoned.
B
B
E
So
I
guess
offering
detached
plugin
could
still
be
a
kind
of
plan
B,
because
for
me
the
concern
would
be
not
this
plugins
per
se,
but
all
the
custom
plugins
everywhere.
We
cannot
really
control,
and
you
know
for
a
fact
that
majority
of
them
will
be
eventually
tested
when
these
instances
upgrade
to
real
CS.
So
I
wonder
whether
we
could
just
approach
like
with
previous
removals
ship,
a
plug-in
that
is
immediately
deprecated
and
at
least
have
a
plan
B
and
at
the
same
time
have
more
freedom
opportunism.
E
They
think
once
the
quality
bar
is
matched.
D
There
is
no
configuration
attached
to
this.
Unlike
you
know,
Matrix
job
external
monitor,
job
junit
plugin.
They
all
had
user
data
attached
to
them.
So
I
think
it's
a
different
situation.
D
Well
then
it's
not
detached,
then
it's
just
a
separate
plugin,
like
the
one
I
wrote.
E
B
B
These
Escape
hatches,
because
you
never
know
when
it's
safe
to
rip
them
out
and
if
you
really
remove
it
fully
without
having
an
escape
hatch,
you'll
get
feedback
very
quickly.
If
it's,
if
something
stops
working,
whereas
if
you
have
the
escape
hatch,
someone
might
be
using
it
and
not
telling
you
about
it,
and
then
you
never
really
know
when
it's
safe
to
remove
defeat
the
the
old
code.
B
D
D
C
B
Yeah
most
most
plugins
are
doing
extensive
JavaScript
on
the
front
end,
probably
the
most
sophisticated
one
that
I've
seen
was
the
Uno
Choice
active
choices,
plug-in
which
I
didn't
really
know
about,
but
this
plugin
does
some
very
sophisticated
reactive
JavaScript
to
to
add
and
remove
parameters
on
the
front
end
based
on
selections.
So
that
was
very
interesting
to
me,
because
I
didn't
know
that
we
had
stuff
like
that
out
there
in
the
ecosystem,
but
most
most
of
our
Front
End
is
Extremely,
either
extremely
simple
or
implemented
with
something
other
than
prototype.
B
A
Thank
you.
Any
anything
else
that
we
need
to
discuss
with
regard
to
prototype
is
like
the
next
stop.
Is
a
discussion
in
the
Jenkins
developer
list
about
getting
a
rough
timing
on
on
when
and
I
think
basel's
right
that
it's
probably
not
in
the
next
12-week
cycle,
but
12
weeks
after
that,
maybe
a
very,
very
good
time.
A
Great
all
right,
thank
you.
Next
topic
was
HTML
unit
three,
so,
whereas
prototype
JS
is
an
upgrade
of
production
code,
HTML
383
unit
3
is
test
code,
but
it's
widely
used
and
quite
important
to
how
Jenkins
does
its
testing,
and
so
the
and
the
upgrade
from
two
to
three
was
a
breaking
change.
So
it's
there
are
now
hundreds
of
pull
requests
open
and
those
pull
requests
are
making
progress
through
the
system.
So
I've
not
seen
anything
that
indicates.
This
is
going
badly
just
that
there's.
B
Yeah
and
the
spreadsheet
most
of
the
work
is,
in
the
you
know,
twenty
thousand
to
one
thousand
range,
and
that's
that's
always
the
most
difficult
part
of
any
of
these
ecosystem-wide
projects
in
the
sense
that
there's
there's
a
lot
of
plugins
that
are
within
that
range,
where
they
are
big
enough
to
be
actively
maintained,
but
they
are
still
widely
used
enough
that
we
need
to
be
be
somewhat
concerned
about
them.
B
So
yeah
there's,
that's
probably
the
the
area
that
that
needs.
The
most
attention
in
here
is
that
that
range
that
we're
looking
at
now
of
I,
don't
know
20
000
to
5
000
or
something
like
that.