►
From YouTube: Jenkins Governance Meeting March 20, 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
We
have
a
claim
to
GitHub
trust
and
safety
as
one
of
the
items
on
the
agenda
news,
action
items,
jira
license
changes,
CDF
topics,
Community
activity
and,
as
a
final
item,
possibly
adjusting
our
meeting
time
for
the
European
change
to
Daylight
Saving
Time.
Any
other
topics
that
need
to
go
on
the
agenda.
A
B
B
Private
information
that
was
posted
without
consent,
copyrighted
source
code
or
password
of
BMC
Software
Inc,
if
it's
a
password
if
it
refers
to
the
string
computware.
So
that's
a
bit
awkward,
so
I
know
that
Tim
reached
out
to
the
committers
to
understand.
What's
going
on.
At
the
same
time,
I
filed
a
pull
request
because
I
mean
I,
don't
know
where
this
is
going,
but
I
would
rather
not
get
us
kicked
out
of
GitHub
because
they
file
a
bunch
of
claims.
B
B
So
then
we
received
a
message
from
one
of
the
maintainers
of
the
plugin
in
question
that
they
were
going
to
fix
it,
and
they
did
so
today
by
rewriting
the
repo
history
in
some
manner,
I
think
so,
a
bunch
of
commits
changed
which
obviously
isn't
ideal
and
I
pointed
out
to
them.
B
Well,
while
the
immediate
notification
from
BMC
was
addressed,
it
would
not
address
the
general
problem
of
an
organization
claiming
its
own
published
source
code
as
private
information
and
messing
with
our
organization
based
on
that,
and
we
haven't
heard
back
from
them
since
and
Alex
printed
out
like
half
an
hour
ago
or
so
that
they
recently
re-licensed
several
of
their
plugins
under
a
non-free
license.
They
were
previously
MIT
and
now
now
some
proprietary
100
page
thing
that
I
haven't
even
bothered
reading,
which
is
against
our
hosting
guidelines.
B
So
now
the
question
is:
how
do
we
proceed
here?
My
preferred,
although
of
course
quite
disruptive
approach
would
be
suspend
everything
from
BMC
and
figure
out
how
to
proceed
from
there,
whether
they
even
want
to
remain
hosted.
What's
going
on
with
the
automated
copyright
claim
to
GitHub
trust
and
safety,
and
so
on,
doing
maybe
even
need
to
delete
or
move
artifacts
out
of
the
way.
B
That's
another
concern
in
this
case
the
copyrighted
source
code
location
was
in
tests,
but
if
they
were
to
claim
source
code
in
production
code,
while
it's
not
GitHub
I
mean
our
artifactory
hosts
Source
jars
and
then
they
say
well
you're
or
might
say
well
you're,
not
supposed
to
publish
that
right.
B
C
Let
me
ask
a
quick
question:
when
did
we
receive
the
mail?
Was
it
last
week
or
some
sort
of.
C
Okay,
if
it
was
Friday-
and
they
stayed
three
business
days
and
include
Friday-
that
would
mean
we
need
to
act
until
tomorrow,
which
seems
a
bit
short
but
yeah
I'm.
Definitely
in
favor
of
this
approach,
because
if
this
is
one
of
those
dmca
claims
you
can
find
on
GitHub
GitHub
is
pretty
eager
to
take
down
these
repositories
pretty
fast.
B
So
for
full
transparency.
B
D
E
A
So
the
the
message,
then,
is
it's
a
request.
The
the
simplest
response
for
us
is
we
suspend
distribution
of
all
BMC
compyware
plugins
until
this
is
resolved
and
unless
it's
resolved
in
an
acceptable
fashion,
OSI
compliant
Alliance,
they
stay
suspended
now
Daniel,
you
mentioned
deleting
more
things
so.
B
Right,
so
what
we
can
also
do
is
we
can
block
further
plug-in
releases
until
the
situation
is
resolved.
We're
basically
messing
with
the
permission
files
and
the
third
thing
we
can
be
doing
is.
We
can
delete
all
previously
published
releases
of
these
plugins
from
artifactory
and
when
I
say,
delete
I
mean
create
a
private
repository
and
move
the
artifacts
over
basically
being
non-destructive,
except
it
appears
gone,
and
if
the
situation
is
resolved,
we
can
always
move
things
back.
B
More
complete
removal
of
all
of
their
stuff,
obviously
a
lot
more
or
some
more
effort
that
we
may
not
even
need,
because
so
far
as
nobody
has
complained
about
artifactory.
As
far
as
I
know,.
E
So,
for
me
it
looks
like
quite
a
drastic
measure,
so,
first
of
all
yeah,
if
you
removed
on
the
article
serious
license
valuation,
then
I
am
plus
one
for
that,
but
removing
all
the
versions
that
are
oci
compliant
I
think
it
would
be
too
much
and
for
me
actually,
yes,
Daniel
said
we
have
never
had
complaints
regarding
artifactory.
So
for
me,
removing
non-compliant
Works
should
be
enough,
but
actually
the
trick
is
that
the
complaint
has
filed
against
the
GitHub
repository.
E
E
E
E
Bmc,
who
knows
yeah
for
me,
the
concern
is
that
if
we
keep
it
on
the
main
Repository,
though
the
flag
itself
won't
go.
B
I
mean
which
is
also
for
me
for
to
restore
publication.
I,
would
like
a
resolution
of
the
GitHub
trust
and
safety
issue
right,
because
if
they
change
the
license
file
around
and
say
yeah
we'll
we
re-resolve
the
situation
by
rewriting
repo
history.
Although
I
haven't
looked
into
detail,
what
exactly
they
did
there,
but
still
might
mean
we
have
sort
of
a
strike
against
us
or,
however,
GitHub
tracks.
These
things.
E
If
so,
we
can
just
say
that
means
that
okay,
we
can
transfer
it
to
your
GitHub
organization,
then
you'd
do
whatever
you
want
and
then
file
new
hosting
request.
Once
you
addressed
all
concerns.
A
A
E
A
E
We
want
to
once
all
the
issues
are
solved,
but
yeah
I'm
not
sure
that
it's
going
to
happen
because
yeah
from
what
I
saw
in
the
comment
history
right
now,
it's
not
given
that
they
would
revert
to
the
license
and
if,
even
if
so
it
may
take
ages
because
of
legal
involvement.
B
Right,
but
what
would
moving
the
repository
accomplish
compared
to
making
it
private
so
GitHub
suggests
in
their
email
that
the
sensitive
information,
which
is
the
string
computer
and
the
Java
doc
opening
comment
start
is
sensitive
information
that
well.
We
can
just
to
make
it
private
right
and
then
go
from
there,
of
course,
because
in
both
cases
the
problem
is,
it
needs
to
be
resolved
in
some
manner,
preferably
by
them
telling
GitHub.
Oh
our
bad.
We
didn't
mean
to
send
this
email.
A
Yeah
so
then
I
was
thinking.
If
we
make
the
repository
private
as
recommended
by
GitHub,
we
resolve
github's
concern
right.
The
their
concern
is
private
information,
as
as
non-sensitive
as
the
word
Compuware
is,
should
not
be
disclosed,
so
it's
the
repositories
private.
If,
then,
we
want
to
transfer
that
private
repository
to
the
plug-in
maintainers
we
can
do
that
to
their
organization.
We
can
do
that
as
well,
but
if
we
make
it
private
initially,
that
seems
like
an
immediate
win.
B
E
The
transfer
will
be
permanent,
as
well
as
the
publishing
if
they
do
not
fix
the
licensing
and
the
computer
vlogging
yeah.
For
me,
it's
rather
less
important
thing,
because
it's
non-brainer
that
they
can
reverse
this
claim,
because
yeah
there
is
no
sensitive
content
except
the
Java
string.
B
I
mean
the
always
I
think
so
so
a
major,
immediate
concern
for
me,
as
I
mentioned
the
GitHub
trust
and
safety
thing,
because
if.
D
B
Right
they
have
like
10,
plug-in
repos.
They
file
a
GitHub,
trust
and
safety
issue
against
each
of
them
and
GitHub
says
yep
we're
not
going
to
deal
with
these
criminals
anymore,
and
then
there
has
been
Jenkins
CI
organization
in
the
past
and
so
for
me,
that's
sort
of
the
immediate
concern
now.
Obviously
we
per
our
hosting
guidelines
we
don't
want
to.
B
We
don't
want
to
publish
OSI
stuff,
which
was
where
the
suspension
comes
in,
but
to
protect
the
Jenkins
project.
The
trust
and
safety
thing
seems
the
more
urgent
one.
A
B
Right,
the
next
problem
is,
if
we
make
the
repository
private,
it
detaches
everything
else
from
the
network,
so
they
lose
the
fork
relationships
which
will
make
development
more
annoying
for
The
BMC
folks,
because
clicking
on
create
pull
request
becomes
more
difficult,
but
that's
probably
going
to
be
their
problem.
B
Not
that
seems
correct
yeah,
so
the
documentation
would
be
gone,
but
at
the
same
time
we
just
would
suspend
the
plugin,
so
that
would
those
would
be
gone
anyway.
Now
the
question
is,
in
my
pull
request:
I
suggest
the
suspension
of
all
of
the
computware
and
BMC
stuff.
Basically,
I
looked
at
the
maintainer
email
addresses
and
everyone
with
a
BMC
email
address
got
their
stuff
suspended,
whether
that's
more
than
we
need
because
so
far
it
seems
both
the
license
thing
and
obviously
GitHub
trust
and
safety.
B
So
far
is
only
interested
in
one
plugin.
It
seems
limited
to
to
the
things
previously
owned
by
computware,
whether
we
should
make
the
scope
of
this
pull
request
smaller
or
whether
we
should
just
remove
everything
in
an
attempt
to
perhaps
get
them
to
more
quickly
resolve
the
situation.
E
So
the
publisher,
the
plugins
that
part
seems
clear.
Remove
personally
I,
don't
have
a
strong
preference,
I
mean
the
amount
of
work
for
GitHub
or
cut
means
is
basically
the
same.
You
convert
the
repository
to
private,
you
create
a
team
to
Grant
the
access,
and
then
you
revert
everything
once
they're
fixed.
E
G
I,
don't
think
that
would
be
sufficient
to
protect
us,
because
if
this
was
filed
by
some
kind
of
corporate
effort
that
was
hunting
down
strings
and
filing
these
complaints,
then
I'm
sure
that's
not
the
only
string
in
their
database.
They
would.
They
would
likely
have
a
large
set
of
passwords
that
they're
searching
for
so
I
I.
Don't
I,
don't
think
that
the
single
string
copy?
Where
is
the
only
thing
that
they
would
be
looking
for.
E
A
Yeah
I
I,
think
that
makes
sense.
I
certainly
would
not
expect
that
to
be
the
only
password
to
be.
That
would
be
a
problem
so
Oleg
back
to
your
your
suggestion.
It
was
we
could
proactively
search
for
or
search
for,
suspect,
strings
in
The,
BMC
or
bmcn
Compuware
repositories,
and
if
we
detect
them,
then
decide
to
make
those
private
as
well.
B
I
mean
the
problem
with
that
is:
where
do
we
go
from
there
right?
What
can
the
maintainers
do
to
make
us
make
the
repositories
public
again.
E
D
E
Mostly
they
revert
their
own
clean,
then
probably
write
us
written
information
that
they
have
no
legal
concerns
about
the
content
of
these
repositories
so
that
we
can
save
it
for
the
future,
should
they
both
go
crazy
again.
B
Right,
basically,
you
want
a
proactive
confirmation
that
the
other
repositories
they
have
not
yet
complained
about
are
fine.
E
G
I
have
three
proposals
that
we
could
discuss:
one
for
a
GitHub
repositories,
one
for
future
releases
and
one
for
past
releases.
I
think
those
are
the
three
the
three
things
we've
been
talking
about.
So
here's
here's
a
pro
here's
one
proposal
for
each
of
those
topics.
We
can.
We
can
modify
this
proposal
but
I'm
kind
of
just
collecting
what
we've
been
discussing
so
far.
G
Oh
yeah,
no
I'm
in
favor
of
that
can
we
let
me
see,
let
me
change
that
then
to
say:
spend
distribution
of
all
copyware,
B
and
C
plugins.
Does
that
does
that
work,
Daniel.
B
No,
so
those
are
two
independent
axes,
so
suspend
distribution
means
they
don't
show
up
anymore
in
the
Json
and
on
plug-in
string,
concile
and
a
different
axes
is
that
that
implies.
The
first
indirectly
is
remove
the
public,
artifacts
and
artifactory,
so
we
no
longer
distribute
the
maven
artifacts
of
these
plugins.
G
B
Basically,
identify
which
releases
happen
with
the
non-free
license
and
just
to
spend
those
releases.
E
G
B
Where
do
you
see
left
pad
happening
this?
This
isn't
workflow
API.
B
So
one
of
the
topics
was
removing
all
artifacts
and
Oleg
mentioned
left
pad
happening
in
our
infrastructure,
but
realistically
we're
discussing
com,
viewer,
plugins
and
not
you
know,
workflow,
API
or
mailer,
so
I
don't
really
see
left
pad
happening
and
the
additional
problem
is
the
plug-in
repository
with
the
claim
was
computer
common
configuration,
which
is
a
dependency
of
a
lot
of
the
company
aware
plugins.
So
there's
already
a
necessary
mini
left
pad
happening
because
of
that
alone.
E
Was
an
attack,
distribution
attack
or
a
package
npm
that
half
of
other
npm
packages
depended
on.
So
basically
it
led
to
various
kinds
of
build
issues
even
and
also
dependency
issues
for
those
pulling
PMS
attempt
to
impact
that
one
of
the
companies
starting
okay.
A
G
A
B
It
well
yeah,
but
dependencies
are
realistically
at
the
level
of
Maven,
artifacts
or
okay,
all
right
plugins,
rather
than
GitHub
repositories.
One
could
be
done
fairly
easily
with
little
side
effects
got
it.
A
Thank
you
thanks
for
the
clarity
okay,
so
it
feels
like
we
do
have
these
these
proposals
for
discussion
agreement
that
the
first
is
the
is
this
likely
the
simplest
one
for
us
to
get
agreement
on
what
show
how
we
shall
process?
How
shall
we
proceed
any
further
discussion
needed
on
this
one,
I'm
prone
to
say:
let's
call
for
a
hear
people's
objections
or
vote
yeah.
B
B
So
at
this
point
we
can
take
it
private,
but
if
the
maintainer
says
it's
cool,
we've
done
the
thing.
We
basically
have
no
way
of
confirming
it,
and
if
we
tell
GitHub
trust
and
safety
hey,
we
did
the
thing,
but
we
took
the
repo,
also
private.
They
will
tell
us
well,
we
cannot
look
at
it
if
it's
private
so
seems
like
a
catch
22
situation.
If
we
make
it
private
and
then
tell
the
maintainers
to
figure
it
out.
B
B
Alternatively,
we
can
make
it
private
and
then
do
the
thing
below
where
we
say
oh
well,
it
was
mentioned
earlier.
We
need
a
confirmation
from
them
that
they
have
no
objections
to
the
repositories
that
they
maintain
right.
E
B
A
Okay,
so
are
we
ready
to
call
for
I'm
I'm,
sorry
I'm,
still
not
seeing
exactly
the
the
path
forward
so
Daniel,
do
you
have
a
recommended
path
forward?
It's
make
just
the
specific
repos
private
make
them
all
private.
G
G
F
G
B
To
be
on
this
block
releases
for
the
plug-in
stuff
had
adopted
a
non-free
license,
or
do
we
plug
everything.
F
G
B
G
E
Well,
we
block
one
we'll
actually
give
them
a
warning
in
the
pull
request,
so
I
think
it
should
be
enough.
B
E
So
basically,
that
repository
permission,
data
request
that
blocks
all
of
them.
So
basically,
this
is
the
warning
for
the
rest
of
the
plugins.
E
G
E
A
B
Me,
oh
like
what
was
your
point
with
MIT.
Well,
basically,.
E
The
point
is
if
the
plugins
were
distributed
on
the
JPL,
like
it
happens,
for
a
few
plugins
within
our
okay
system,
that
the
fact
that
they
rewrote
the
history
maintains
us
to
remove
all
the
artifacts,
because
we
cannot
be
remain
compliant
with
the
GPL
license,
but
for
MIT
license.
I.
Think
that
alternative
2
would
mean
of.
B
No
because
the
source
jars
still
have
the
sources,
it
doesn't
matter,
whether
the
repo
exists
or
not
so
yeah,
you
always
yeah
Alex,
that's
related
to
one
of
your
open
pull
requests
to
update
sender
too.
We
have
a
few
plugins
that
have
no
sem
and
but
they're
all
Source
charge.
So
as
far
as
I'm
concerned,
that's
no
problem,
but
you
know
just
a
side
note:
okay,.
A
G
Some
you
myself,
sorry
I
forgot
to
mute
myself
while
I
was
typing,
I
I
think
I've
clarified
the
first
one
enough
for
me
to
be
able
to
understand
it.
So
there's
actually
six.
If
you
consider
the
idea
of
transfer
of
transferring
because
it
would
be
transferring,
but
in
addition
to
making
it
private
I
think
I
think
that's
what
Oleg
was
was
saying
earlier
and
they
and
and
I
think
my
complaint
was
invalid,
because
I
forgot
that
I
had
wrote
up
at
the
top.
That
would
be
pending
blah
blah
blah.
G
A
G
So
the
key
point
is
that
this
is
not
pending
an
OSI
license,
because
the
issue
of
marking
the
repositories
private
has
nothing
to
do
with
OSI
and
purely
to
do
with
GitHub
trust
and
safety,
whereas
for
the
bottom,
two
suspending
distribution
and
removing
from
artifactory,
the
confirmation
is
dependent
on
both
the
trust
and
safety
issue
and
the
OSI
compatible
license,
at
least
for
alternative
one
right
yeah.
These
proposals
look
complete
to
me.
A
G
A
A
G
I
have
a
strong
preference
for
alternative
to
on
the
repositories,
private
and
as
far
as
blocking
future
releases
I'm
in
favor
of
that
I
guess.
This
would
be
my
vote
if
you
want
to
consider
it
that
or
but
for
the
second
bullet
point
I'm
I'm
in
favor
of
that
and
as
far
as
suspending
distribution
and
favor
of
alternative
one
and
as
far
as
removing
from
artifactory
I'm
in
favor
of
alternative
to.
A
B
Block
future
releases
yep,
definitely
because
otherwise
they
just
create
more
trash.
That
I
need
to
delete.
B
I
would
like
to
abstain
on
the
artifact
repository
one,
because
I
would
vote
for
alternative
one,
because
alternative
two
is
way
more
annoying
to
implement
so
as
the
one
who
needs
to
click.
The
buttons
I
vote
for
clicking
viewer
buttons,
which
is
perhaps
not
the
purest
motivation.
B
Yeah
I
can
basically
move
over
all
of
the
top
level
artifacts
directories,
rather
than
the
versions
that
we
don't
like
individually
got
it.
Okay,.
B
A
A
A
A
E
And
I'll
find
abuse
me
so
well,
basically,
I
take
everything
except
alternative:
zero.
E
I
would
prefer
to
take
it
safely,
but
yeah.
C
C
C
D
A
A
D
F
Go
next
one
alternative
one.
F
A
Okay,
so
let's
go
from
top
to
bottom
I.
Think
we've
got
some
that
are
clear
winners,
so
here
that
one
wins
right
sounds
good
to
me:
okay
and
Daniel
I
assume
you're
the
person
who
would
actually
Implement
that
or
is
do
we
need
to
talk
to
somebody
else.
I,
don't
know
who
the
org
admins
are
for
that
one
I
think
I
can
do
that
too.
Okay,
great
all
right,
the
next
one,
this
one
we
have.
Oh
I,
should
put
the
action
item
here,
just
a
minute,
Daniel
back.
A
A
Okay,
oh
oh
good,
you're
taking
action,
so
I
don't
have
to
put
it
there.
Thank
you
thanks.
Very
much
perfect.
Okay,
good
next
block
future
releases,
pending
restoration
of
OSI
compatible
lion,
license
that
one's
a
clear
winner,
I
think
that's
already
expressed
in
your
no
it's
not
expressed
in
an
artifact
permissions
or
updater.
Yet,
but
is
this
one
that
you
would
get
the
action
out
of
Daniel
or
is
it
something
else
something
any
one
of
us
could
do?
A
E
I
agree
that
it
would
get
the
attention
yeah
I'm,
not
sure.
Well,
it
may
happen,
but
they
move
or
out
and
cross
the
plugins
on
their
own.
But
let's
see
sure
yeah.
E
For
that
I'm,
okay,
if
I
was
in
a
decision
just
on
my
own
I,
would
rather
go
for
two,
because
it's
less
destructive
but
yeah
even
taking
the
votes.
Okay,
we
go
with
one.
B
So,
just
for
the
record,
these
plugins
have
a
combined
total
of
around
200
installations
that
we
are
aware
of.
So
it's
not
again.
This
is
not
workflow
API.
This
is
not
mailer
email
list.
Anything
like
that.
Yeah.
G
A
B
B
Me,
okay,
thank
you
I
doubt
I
really
doubt
that
becomes
necessary,
but
it's
nice
to
have
that
safety
net.
Thank
you
great.
A
B
How
do
we
reach
out
to
maintainers
and
explain
the
situation
to
them
and
what
we
expect
from
them
as
follow-up.
A
So
I
sent
email
to
the
maintainers
earlier
this
morning,
I
sent
email
to
Dave
dresser,
one
of
the
maintainers
and
I
think
I
was
going
I
I'd
assumed
somebody
from
the
board
and
I'm
happy
to
volunteer
sends
them
an
email.
Saying.
Look
here
are
the
decisions
we've
made
based
on
this
here?
Are
your
your
Rich,
your
your
pending
these
actions?
This
is
what
we've
done
and,
and
you
need
to
take
actions
or
this
will
be
the
ongoing
state.
B
Right
so,
based
on
what
we
decided,
we
are
now
about
to
suspend
distribution
of
around
10
plugins.
So
there's
probably
a
few
more
people
who
inform
should
be
contacted
and
informed
about
this
and
where
you
can
also
request.
Further
action
be
taken.
A
Right
so
the
way
I
would
the
way
out
I
think
I
would
do
that
is
I
will
look
in
repository
permissions
updater
for
the
the
maintainers
of
those
plugins.
Look
in
accounts.jenkins.io
for
their
email
addresses
I'm
an
administrator
there,
so
I
can
read
those
and
send
email
to
those
email
addresses
saying
this
is
what
we're
doing.
This
is
what
we
have
done.
A
B
And
how
they
can
have
us
restore
distribution.
F
B
As
a
as
a
quick
side
note,
when
I've
previously
reached
out
to
maintainers
about
security,
vulnerabilities
I've,
always
also
I've,
often
also
checked
the
account
app
I.
Don't
know
whether
a
decent
of
connect
information
is
still
a
problem
based
on
the
current
jira
configuration,
but
it
was
in
the
past
so
that
the
jira
email
address
was
invalid
and
they
would
not
get
information
emails
from
there,
but
they
had
a
correct
contact
address
in
the
account
app.
A
I
was
intending
to
only
use
the
account
app
because
that's
the
one
that
they
have
to
use
for
password
reset
I
wasn't
even
going
to
look
at
jira.
Oh
okay,
is
that?
Okay,
that's!
That
was
my
thought,
because
that's
where
I
frequently
go
if
I
need
to
convert
a
Jenkins
account
name
to
an
email
address
seems
seems
fine,
yep,
okay,
based
on
email
and
if
they
have
a
bogus
email
address
well
address
in
accounts.jenkins.io.
A
And
Daniel,
could
you
provide
the
list
of
the
specific
plugins
that
way,
I'm,
not
guessing
which
ones
are,
are
owned
and
you
and
I
risk
having.
A
B
Which
also
goes
beyond,
for
the
record
also
goes
beyond
computware.
There
are
also
a
few
B
BMC
plugins,
specifically
that
look
maintained
by
BMC
folks
and
I
mean
that
was
just
you
know.
B
A
A
Okay,
we're
up
against
only
four
more
minutes
till
our
hour.
I'd
propose
to
skip
news
and
action
items
unless
there
are
items
that
you
want
to
specifically
highlight
in
them.
A
Okay,
next
year,
license
changes
are
complete,
nothing
else
to
say
there,
except
thanks
to
atlassian
and
thanks
to
the
Linux
Foundation
CDF
topics,
I'm
going
to
I've
scheduled
to
do
a
presentation
to
the
CDF
technical
oversight
committee,
April
12,
on
the
status
of
the
Jenkins
project.
I'll
create
the
presentation
share
it
with
all
of
you,
so
that
you
can
see
it
give
comments.
Etc
and
I
specifically
asked
in
the
last
meeting
for
confirmation,
they're,
okay,
with
it
being
a
wider
project
review,
not
just
a
technical
topics
review
and
they
specifically
wanted
it.
A
A
So
next
topic,
then,
was
on
community
activity
just
to
be
have
people
aware,
artifactory
bandwidth
reduction
project
keeps
going,
I
finally
gave
up
and
publicly
disclosed
the
abusing
IP
address
and
still
not
made
significant
progress
on
it.
But
artifactory
is
going
to
attempt
to
block
at
the
IP
level.
A
Google
summer
of
code,
we've
got
22
draft
proposals
now
up
for
review
thanks
everybody,
April
4
is
when
proposals
submit,
and
the
last
topic
for
this
group
was
the
one
that
I
most
wanted
to
be
sure.
Usually
in
the
past
we
changed
the
meeting
time
for
daylight
savings
so
that
we
would
keep
a
consistent
time
of
day
for
our
European
contributors
does,
that
is
that
a
preference
Oleg
for
you
Alex
for
you
Daniel,
for
you
Bruno,
for
you
or
would
are
you
okay
with
us,
staying
at
UTC
and
Uli?
D
A
So
I'll
double
check
with
Uli
Hoffner.
Consider
the
question
opened
and
not
resolved
at
this
point.
Daylight
Saving
is
invoked
in
Europe
a
week
or
two
from
now
is
that
right,
yeah.
A
All
right
and
Bruno
do
you
have
a
preference
that
you
wanted
to
note.