►
From YouTube: Jenkins Governance Meeting April 3, 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
the
Jenkins
governance
board
meeting
it's
April
3rd
2023.,
thanks
for
being
here,
topics
on
the
agenda
for
today
include
the
BMC,
the
claim
from
BMC
to
GitHub
trust
and
safety.
News
action
items
several
items
there
then
I
had
put
CDF
topics
and
Community
activity.
Are
there
any
other
topics
that
anyone
wants
to
be
sure
we
cover
in
this
meeting
today.
A
Okay,
then,
let's
go
ahead
and
get
started
so
first,
two
weeks
ago,
when
we
last
met,
we
we
received
a
note
from,
or
we
had
Daniel
Beck
join
us
and
share
the
work
he
was
doing
in
handling
a
claim
that
had
been
filed
to
GitHub
trust
and
safety.
A
Regarding
private
information
that
they
said
had
been
disclosed
in
a
on
a
unwillingly
or
unwittingly
disclosed
in
a
repository
of
the
Jenkins
project.
The
claim
was
flawed
at
best,
but
we
took
action.
You
can
see
the
actions
taken
in
the
the
entry
from
two
weeks
ago.
Since
that
time
the
claim
has
been
rescinded,
confirmed
by
GitHub
that
it's
been
rescinded,
confirmed
by
BMC
that
it's
been
rescinded.
The
plugins
that
were
distributed
under
an
open
source
license
have
been
restored
to
distribution.
A
Okay,
so
next
piece
then,
is
on
the
news:
Jenkins
releases
are
upcoming.
Tomorrow,
we've
got
a
weekly
the
day
after
we've
got
a
an
LTS
Chris
Stern
is
the
LTS
release
lead
as
part
of
those
weeklies.
We've
got
a
change
of
the
pgp
repository
signing
key
for
Debian
and
RPM
packages.
The
Debian
repositories
seem
to
be
the
most
impacted
and
are
getting
the
most
questions
thanks
to
Alex
for
his
work
on
helping
to
answer
people's
questions
resolve
their
concerns.
A
We've
announced
it
in
multiple
places
and,
yes,
we
know
we
need
to
get
better
at
doing
this.
The
last
time
we
did
it
was
three
years
ago
and
we've
not
done
this
nearly
well
enough.
We'll
do
a
we'll
do
a
a
retrospective
after
we
get
through
the
work.
A
Now
we've
got
Oleg,
who
added
a
note
that
he's
changed
affiliation.
He
now
works
for
wiremock
and
availability
continues
about
the
same
any
questions
or
comments
on
the
news.
A
Okay
and
we
may
come
back
to
oleg's
change
of
affiliation,
he
just
joined
us
so
on
the
action
items,
the
top
several
no
further
progress
since
our
meeting
last
week
or
two
weeks
ago.
As
far
as
I
know,
we've
got
eccla
the
sub
projects,
convergence
and
the
Chinese
Jenkins
site
Oleg.
Did
you
want
to
give
any
comments
on
your
change
of
affiliation?
Congratulations!
Well,.
B
Yeah
I
think
actually
nothing
really
changes
for
Jenkins,
except
the
fact
that
if
you
have
any
issues
with
so
among
test
automation,
we
have
been
Jenkins
here
and
there.
You
know
whom
the
pink
great.
B
But
radio
for
me,
yeah
was
unable
for
conjunctions
as
much
as
I
would
like
recently,
but
it's
not
really
related
to
my
employer
but
to
all
the
other
stuff.
B
Next,
thank
you
plan.
A
few
talks
about
Jenkins
finishing
some
beats
around
Jake's
file
Runner
and
what
else
I
plan
yeah.
One
month
ago,
I
gave
a
talk
on
open
source
roadmaps
and
basically
it
was
a
retrospective
on
what
ran
went
wrong
with
Jenkins
public
roadmap,
because
personally
I
believe
that
it
didn't
fly.
B
A
Great
thank
you.
So
next
I
I
see
Daniel
Becker's
joined
us
Daniel.
We
had
just
covered
the
claim
from
BMC
to
GitHub
trust
and
safety.
Thanks
very
much
for
your
work
on
it.
Is
there
anything
that
you
wanted
to
note.
In
addition
to,
what's
already
been
noted,
publicly
nope,
okay,
thanks
thanks
again
for
your
effort
on
that
thanks
very
much
so
I
still
have
an
action
item
to
Archive
the
governance
meeting
notes.
Gavin
Mogan
has
politely
declined,
he's
not
ready
to
continue
that
effort.
I'll
carry
it.
Forward
I've
got
more
work
to
do
there.
C
Yeah,
there's
not
much
to
share,
but
since
I
had
brought
this
topic
to
the
board
earlier.
Regarding
Shannon
Molex
request
to
maintain
his
link
to
his
blog
inside
of
the
plugin
I
thought.
I'd
give
an
update
on
this.
Since
it's
been
concluded
now
and
his
repository
has
been
transferred
to
the
Jenkins
GitHub
organization,
the
build
has
been
moved
to
Jenkins
from
GitHub
actions,
and
the
release
process
has
been
converted
to
our
standard
CD
process.
C
So
this
project
is
wrapped
up
and
I
was
I
was
so
pleasantly
surprised
to
also
see
that
some
of
our
front-end
contributors
even
improved
the
display
of
the
plug-in
website
to
display
the
older
versions,
the
pre-cd
versions
of
build
monitor
at
the
bottom
of
the
list
and
sort
the
whole
list
correctly
with
the
the
new
versions
at
the
top.
C
So
this
effort
has
really
been,
has
really
fully
been
completed,
with
everything
from
the
build
automation
all
the
way
to
the
display
on
the
plug-in
side,
and
it
now
looks
and
feels
like
a
full
full
member
of
the
Jenkins
project
with
no
it's
not
it's
not
otherwise
visible
as
something
that
we
transferred
later
on.
So
that's
really
all
there
is
to
say
about
build,
monitor
it's
one.
It's
it's
one
of
ours
now,
so
that's
it.
A
Thanks
very
much
thank
you
for
taking
that
through
to
completion,
much
appreciated
on
the
CDF
topics.
I
had
three
items:
digicert
signing
certificate,
renewal,
progress
that
I
wanted
to
discuss.
Then
project
presentation,
April,
12
and
LFX
tools,
working
group.
Are
there
any
other
CDF
topics?
Oleg
that
you
wanted
to
add
or
to
be
sure
that
we
included.
B
Maybe
because
okay
12
was
really
suspicious.
A
B
Yeah,
basically
not
that
many
other
updates
from
the
CDF
at
the
moment.
So
there
was
a
cycle
of
defining
kcdef
and
Jenkins
awards
for
this
year,
so
the
announcements
will
go,
live
I
believe
in
a
week
or
two,
but
otherwise
no
big
news.
A
B
Maybe
it's
internal
announcement
because
yeah
in
the
outrage
committee,
so
maybe
they
will
be
internal
announcement
first
announcement
to
participants
and
then
Public
Announcement
that
silicon,
as
you
mentioned,
it
makes
a
lot
of
sense
by
the
way.
If
you
want
to
go
in
there.
B
B
Yeah
so
I
finally
got
the
ground
from
the
Linux
Foundation
to
visit.
Kubecon
I
will
be
there.
I
checked
whether
there
would
be
any
CDF
events,
apparently
not,
but
yeah.
There
might
be
some
drinks
related
agenda.
A
Great,
thank
you
all
right.
So
going
back
to
the
the
other
CDF
topic,
so
others
are
aware:
we've
the
Jenkins
code
signing
certificate
the
certificate
we
use
to
sign
the
war
file
and
the
MSI
installer
has
expired.
It
expired
March,
the
30th,
the
war,
the
expiration
of
the
signing
on
the
war
file
is
not
a
terribly
big
concern,
but
the
MSI
installer
is
a
big
deal.
Most
Windows
users
won't
use
an
installer,
that's
not
signed,
and
so
I
sent
a
proposal
to
the
board
to
the
release
officer.
A
A
Okay,
other
topic
I
had
put
on
was
the
LFX
tools
working
group.
So
what
the
ls,
the
Linux
Foundation
tools
working
group,
is
looking
at
a
potential
replacement
or
upgrade
to
supersede
the
dev
stats
facility
that
we've
been
using
for
a
number
of
years.
We
use
it
to
track
participation
and
involvement
at
a
course
level
in
the
Jenkins
project,
and
so
we're
actively
involved
in
those
discussions
and
we'll
continue
those
discussions.
A
B
Because
yeah,
what
concerns
me
that
LFX
insights
is
not
a
featured
complete
if
you
compare
it
with
Dev
stats,
so
I
wonder
whether
there
would
be
any
impact
there
should
be
no
impact
on
automation,
because
yeah
would
be
head
forward
to
meeting
Community
starts.
It
was
quite
weak
and
I.
Don't
think
we
use
it
anymore,
but
are
there
any
other
dependencies
that
we
might
have
understood?
I've.
C
C
The
agenda:
let's
have
some
questions
about
the
key
signing
part
if
we
still
have
time
to
talk
about
that
sure,
go
ahead,
so
there
there
were
some.
There
are
some
people
complaining
about
the
existing,
stable
Repository
not
being
signed
by
apt
until
we
do
the
next
LTS
release,
which
is
coming
up
this
week
and
I
wasn't
clear
if
I
think
the
ACT
I
think
the
action
was.
C
C
So
because
I
don't
I,
don't
know
very
much
about
this,
but
it
seems
to
me
that
that
this
wouldn't
be
an
uncommon
scenario
for
for
a
key
to
expire
and
for
existing
old
releases
to
be
unavailable.
So
I'm
not
sure
what
this,
what
the
standard
practice
is,
but
I
think
it
might.
It
might
be
the
case
that
you
could
resign.
You
know
older
releases
with
a
new
key
and
publish
that
I'm,
not
I'm,
not
too
sure
about
this,
though.
C
C
Of
course,
now,
with
only
two
days
left,
it's
it's
probably
not
worth
doing
that
from
a
time
and
effort
perspective,
but
you
know
if
we're:
if
we're
gonna
have
this
problem
again
going
forward.
That
might
be
something
to
think
about
or
or
I
might
just
be
wrong
and
there's
just
maybe
no
way
to
deal
with
this
problem
retroactively,
but
I
was
I
was
still
a
bit
curious.
Do
you
have
any
insight
on
whether
that
was
possible
or
whether
we
just
chose
to
do
it?
A
I
think,
as
far
as
I
can
tell
from
the
comments
by
Michael
Prokop,
it
is
possible
to
sign
old
releases
again
with
the
new
key
without
disrupting
those
things.
So
so
we
could
have
done
it
and
it's
also
possible
to
sign
packages
with
multiple
keys
so
that
and
between
those
two
things,
I
think
we
could
have
made
this
process
much
much
smoother
for
the
users
than
we
did
right.
The
Debian
process,
saying
hey
you're,
going
to
be
down
for
a
week,
is
really
uncomfortable.
C
Yeah
and
from
my
point
of
view,
there's
really
nothing
wrong
with
us
making
that
mistake
or
not
having
the
time
or
the
resources
to
do
that.
I.
That's
completely
understandable
from
my
point
of
view,
because
you.
C
Perfect
and
nobody
has
infinite
resources
Etc,
but
I
was
a
little
bit
confused
about
how
that
was
communicated
to
users,
because
I
saw
many
of
these
tickets.
C
We
just
told
them
to
wait
another
week
and
then,
when
they
complained
there
was
just
no
response
after
that,
so
I
think
I
think
we
could
have
done
a
better
job
of
acknowledging
from
our
side
that
that
it
could
have
been
done
differently
and
not
necessarily
being
apologetic,
but
just
I
I,
don't
think
we
acknowledged
I,
don't
think
we
acknowledge
that
as
much
as
we
could
have
and
I
I
think
users
generally
prefer
when
we're
fully
transparent
with
them
about
both
our
strengths
and
our
weaknesses,
because
at
least
at
least
that
creates
a
complete
understanding.
C
Whereas
if
we're
silent
about
it,
then
they
could
be
confused
about
whether
it's
intentional
or
not.
But
you
know
I,
that's
my
only
comment
is.
We
could
have
been
a
lot
more
open
about
the
fact
that
we
just
simply
screwed
up
here-
and
this
is
it's
fine
to
screw
up,
but
I,
don't
think
we
were
very
I,
don't
think
we're
very
transparent
about
it.
Right.
A
A
A
Any
other
concerns
or
comments
from
others,
Alex
I
know
you
were
involved
in
those
conversations.
Are
you
okay,
with
with
with
that,
as
an
an
acknowledgment
that
hey
I
know
the
infra
team?
We
were,
we
were
surprised
right,
it
was
it
shouldn't
have
been
a
surprise.
We
knew
about
this
we've
known
about
it
for
three
years.
When
we
set
the
key
expiration,
we
knew
it
was
going
to
expire,
and
yet
we
missed
the
opportunity
to
do
it
well
before
the
dot
two
LTS.
A
A
So
I
don't
know
yet
we'll
talk
about
it
in
the
retrospective
one
of
the
things
that
the
Michael
Prokop
mentioned
was
that
if
you
sign
with
multiple
multiple
keys
and
you
create
a
separate
package
that
has
supervises
the
keys,
then
you
can
do
the
upgrade
much
more
smoothly
and
I,
but
I
need
to
learn
a
lot
more
about
Debian
packaging
before
I'm
ready
to
say:
oh,
that's
how
we
should
do
it.
So
the
answer
right
now
is
I.
Don't
know
what
the
best
practice
is.
A
D
D
Okay,
that's
a
yeah,
just
a
quick
note
on
the
communication
thing
I've
seen
various
tickets
that
complained
that
the
stable
packages
are
not
the
edit.
The
stable
pages
are
not
updated
on
packaging
and
get.jenkins.io,
which
is
currently
a
limitation
within
the
build
cycle
like
we
can't
update
the
pages
unless
manually
outside
of
releases
because
they
are
generated
once
the
LTS
release
takes
place
and
a
few
people
pointed
out
that
this
is
indeed
a
bad
practice
to
not
up
the
documentation
outside
of
releasing
something.
A
E
Yes,
I'm
I'm
less
interested
in
the
technique
of
how
exactly
it
will
be
solved,
but
rather,
if
I
understand
the
current
problem
correctly,
it
was
that
we
discovered
too
late
that
the
key
is
expiring,
so
the
LTS
release
was
already
created,
so
there
was
no
LTS
release
for
which
we
can
already
use
the
new
key.
E
So
to
prevent
the
problem
that
happened,
it
did
not
happen
as
much
with
the
weekly
release
because
last
week
there
was
a
weekly
release
right,
so
I
I'm
wondering
especially
I
think
we
have
several
keys
on
a
semi-regular
schedule
that
need
rotating.
A
Helped
right
and
that's
in
fact
exactly
what
the
infra
team
uses.
They
have
a
calendar
that
has
these
kind
of
notifications
on
it.
The
the
early
warning
on
this
one
was
not
early
enough
right,
and
that
was
that
was
part
of
the
problem.
Is
it
it
I,
don't
recall
if
this
one
was
the
pgp
key
was
not
on
calendar
or
was
not
early
enough.
C
A
C
That
would
that
would
need
to
be
done,
form
form
because
LTS
releases
are
every
four
months
or
sorry
three
months
apart,
so
and
and
then
doing
the
work
to
prepare
for
that
would
probably
take
around
a
month.
So
yeah
like
four
to
six
months
since
about
right
for
how
long
we'd
need
to
to
orchestrate
this
successfully
exactly.
A
And
that's
I
think
that's
and
we
may
want
to
consider
hey.
Should
we
rotate
every
year,
even
though
the
keys
expire
every
three
years,
so
we've
always
got
you
know
there
are
all
sorts
of
things
like
that.
That
I
think
we
will.
We
will
discuss
in
the
retrospective
and
try
to
find
a
better
path
forward.
A
The
last
time
we
did
it
three
years
ago
we
knife
edge
transitioned
on
a
week
when
we
did
the
weekly
and
the
LTS
within
a
day
of
each
other,
and
that's
the
only
reason
we
didn't
get
better
complaints,
then
right,
because
we
did
it
on
exactly
that:
weekly
weekly
plus
LTS
transition
period,
but
that's
still
not
a
very
palatable
thing,
because
it
was
still
broken
for
a
day
right.
It's
it's
much
more
glaring
when
it's
broken
for
a
week,
but
it
was
broken
for
a
day.
A
Okay
next
topic,
I
had
then
was
this
artifactory
bandwidth
reduction
progress
project,
so
jfrog,
our
sponsor
of
artifactory
for
the
Jenkins
project,
has
asked
us
to
reduce
the
bandwidth
used
by
that
by
that
server.
The
bandwidth
it's
using
is
enormous.
Well,
thanks
to
log
files,
they
provided.
We
found
a
host
at
Alibaba
that
was
downloading
from
20
to
30
terabytes
a
month
by
itself.
A
They
have
now
banned
that
IP
address
and
we're
hoping
that
that's
already
a
dramatic
Improvement
they've
asked
for
further
improvements,
and
we
may
have
to
make
use
model
changes
in
the
artifact
repository,
but
we've
made
good
progress
thanks
to
that
ban
and
the
help
of
the
artifact
caching
proxy.
This
is
something
that
the
infra
team
has
created
to
provide
Cloud
local
caches
of
the
artifacts
instead
of
downloading
them
all
from
repo.jenkinsci.org.
A
Okay,
so
the
next
one
is
Google
summer
of
code,
we're
delighted
that
we've
got
over
28
proposals
already
submitted
to
Google
for
a
Google
summer
of
code
2023
in
the
Jenkins
project
that,
in
fact,
I
think
John
Mark
told
me
it
was
38
because
it's
double
the
number
we
had
last
year
and
we
haven't
reached
the
end
point
yet.
The
end
point
is
tomorrow
when
applications
close
so
we're
delighted
with
the
progress
there.
C
Don't
be
surprised
if
you
see
me
tinkering
around
with
launchable
in
the
next
few
weeks,
so
I'll
be
I'll,
be
making
a
lot
of
little
changes
here
and
there
to
try
to
get
all
the
data
flowing
in.
C
A
Thanks,
yes,
and
so
just
for
everyone's
background,
I
kosuke
kawaguchi
has
provided
access
to
the
launchable
so
that
we
can
do
some
experiments.
Basel
started
those
I've
got.
This
hope
that
we
can
find
a
way
to
reduce
the
cost
of
our
infrastructure.
Basel's
got
an
even
bigger
picture
view
that
he
would
like
to
find
a
way
for
us
to
get
feedback
much
sooner
to
Developers,
without
having
enormous
costs
or
enormous
time,
delays
to
get
that
feedback
to
them.
C
I'm
going
I'm
going
to
be
writing
a
document
that
goes
into
all
of
this
in
a
lot
of
detail,
because
there's
a
lot
of
parts
to
it,
whether
it's
how
to
define
test
Suites,
how
to
define,
build,
how
to
define
test
sessions,
flavors,
there's
a
lot
of
Concepts
in
launchable
and
also
what
what
some
of
the
benefits
are.
C
You
know
there
are
a
lot
of
different
use
cases,
some
of
which
apply
to
us,
some
of
which
don't
it
can
be.
The
distinction
can
be
fairly
subtle,
so
I'm
planning
on
writing
a
document
that
explains
all
of
this.
But
to
summarize
it
you
think
we
can
benefit
in
three
places.
I
think
we
can
benefit
in
bond,
builds
to
reduce
costs.
C
We
can
probably
benefit
in
core
builds
to
reduce
the
number
of
Windows
tests
that
are
running
and
also
potentially
to
do
ath
letes
as
part
of
core
builds
and
I
think
we
can
also
benefit
an
ath
itself,
just
as
just
as
we
could
in
Bomb
by
by
reducing
costs
there,
although
the
costs
are
not
as
bad
in
ath,
but
there's
it's
a
similar,
similar
structure.
C
So
those
are
some
of
the
places
that
I
see
we
could
improve,
but
I'll
have
more
in
writing
pretty
soon
about
my
current
am
I
every
time.
I
think
I
understand
all
of
this
launchable
stuff.
A
few
days
go
by
and
I
realized
that
I've
misunderstood.
Something
and
I
have
to
do
it
over
again.
So
it's
been
a
learning
process
for
me
as
well,
but
I
think
I'm.
C
After
reading
the
documentation,
I
thought
I
understood
everything
then
I
started
implementing
it
and
I
realized
that
I
didn't
understand
it
at
all
and
now
that
I'm
implementing
it
I
think
I
understand
it,
but
I'm
sure
that
in
a
week
from
now,
I'll
be
going
back
and
telling
past
basil
that
he
didn't
understand
it
today
so
and
I'm
getting
feedback
from
the
launchable
support.
Folks
as
well
the
whole
time,
so
we
should
be
getting
pretty
close
to
a
working
prototype,
but
having
having
the
song.