►
From YouTube: 2023-04-05 Delivery team weekly APAC/EMEA
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
B
C
D
Everyone
welcome
5th
of
April,
it's
like,
so
this
is
our
APAC
Emirate
time
delivery,
weekly
and.
D
Do
I
just
verbalize
that
look
I
like
should
I
just
move
it
into
discussions.
We.
E
So
it
is
management
coverage
for
Easter
break,
since
we
have
a
lot
of
public
holidays
on
the
next
Friday,
the
7th
and
next
Monday,
the
10th
of
April.
A
lot
of
people
are
off,
especially
like
release
managers,
Reuben
and
Ahmad,
jumped
in
to
cover
the
two
slots,
mainly
with
we
have
some
limited
availability
on
Monday,
just
for
three
four
hours
on
the
afternoon
of
emea
but
America
time
zone
release
management
shift
has
gonna,
be
unaffected.
E
A
Yes,
good
morning,
I
wanted
to
gather
some
feedback
regarding
The
Click
house
issue.
I
opened
I
think
last
week
to
get
some.
You
know
like
some
discussions
about
this.
A
In
summary,
it's
just
like
about
using
clickhouse
to
supplement
or
to
Aid
Prometheus,
because
some
some
of
the
metrics
are
not
accurate,
like
giving
like
some
exact
numbers
are
not
like
Prometheus
way
of
work,
so
maybe
like
using
clickhouse,
could
help
with
this.
So
yeah
just
wanted
to
get
some
opinions
about
this.
B
Clickhouse
would
be
very
useful
for
things
like
like
Amy
or
McKelly
recently
wanted
things
like
number
of
releases
per
month,
or
you
know
number
of
something
per
something.
That's
very
difficult
to
get
in
Prometheus
from
ql
yeah
clickhouse
would
be
much
better
for
that.
There
is
a
clickhouse
working
group
that
is
currently
discussing
feasibility
and
other
things.
So
maybe
in
a
couple
of
quarters
we
might
have
access
to
a
clickhouse
instance,
but
yeah.
B
That's
the
major
drawback
that
we
don't
currently
have
a
clickhouse
instance,
and
it
might
be
some
time
before
we
get
one.
F
Yeah
and
I
think
that,
just
to
add
some
color
on
the
feasibility
stuff
I
tried
this
through
briefly
with
McKellar
the
other
day,
the
concerned
about
the
increasing
cost
for
small
self-host
customers,
where
it
drives
up
quite
a
lot,
but
for
our
kind
of
scale.
F
C
I
I
just
wanted
to
add
my
two
cents.
Basically
skarbick
pointed
very
good
comment
in
in
this
issue
that,
before
getting
into
and
building
like
the
whole
new
Empire
and
changing
the
gears,
I
I
would
love
to
see
I'd
like
to
get
everything
from
from
Prometheus
that
everything
that
we
we
can
and
I
I
do
believe
that
well
I'm,
not
against
click
house
click
house
is
pretty
cool
solution.
C
I
I
really
love
it,
but
from
the
Effectiveness
point
of
view,
what
I
read
from
from
from
this
issue,
we
are
trying
to
solve
some
tiny
box
or
not
Tiny
Box,
like
something
Miss
design,
I,
would
say
of
our
metrics.
C
We
are
trying
to
solve
misdesign
of
our
metrics
by
introducing
the
whole
new
Tech
stack
and
in
regards
of
the
issues
that
you
pointed
I.
I
do
believe
that
we
already
discussed
that
and
those
issues
are
most
likely
solvable
by
not
introdu
by
by
getting
rid
of
aggregations
over
aggregations,
and
we
have
all
these
counters
and
all
these
things.
Those
are
aggregations
over
aggregations,
we
are,
and
if
we
start
collecting
data
per
deployment
per
job
per
release
or
whatever
those
issues
will
go,
will
go
away.
C
I'm
pretty
sure
with
that.
But
I
think
that
again
like
this
is
like
a
balance
between
always
a
balance
between
effort
versus
value.
I,
don't
think
that
we
we
can
gain
a
lot
of
value
from
from
clickhouse.
C
However,
maybe
not
on
that
field,
because
originally
clickhouse
is
kind
of
all
up
database
and
it's
very
good
for
things
like
traces
and
it's
also
a
push-based
model
instead
of
pull-based
model
and
I
do
believe
that
clickhouse
is
not
designed
for
the
metrics.
It's
designed
for
for
all
up
data.
C
And
yeah
I
I
have
a
little
concern
of
implementing
like
the
whole
new
stack
only
because,
because
we
want
to
solve
certain
issues,
I
would
like
to
see
clickhouse
solving
actually
like
bringing
the
the
value
that
we
cannot
get
with
with
Prometheus
and
everything
that
is
related
to
the
metrics,
like
it's
Prometheus,
specialization
I
think
we
just
doing
that
wrong.
E
A
Yeah,
like
I
the
point
about
the
aggregation
to
be
honest,
I
I'm,
not
sure
if
Prometheus
even
has
something
like
Point
like
like
just
like
something
without
aggregation,
because
it's
an
aggregation
system
after
all,
so
I'm
not
entirely
sure
if
actually
Prometheus
is
able
to
determine
like
exact
numbers.
A
I,
don't
think
this
is
how
it's
designed,
but
like
regarding
the
metrics
I.
Think
what
I'm
trying
to
solve,
mainly
with
the
click
house,
is,
as
Ruben
mentioned,
something
like
exact
numbers
about
like
something
like
in
time
like
or
from
this
period
of
Time.
How
many
things
are
there.
D
So
this
actually
feels
like
maybe
a
slightly
different,
like
initial
kind
of
discussion.
That
needs
to
happen
so
I
from
the
issue
and
I
know
because
you
kind
of
assigned
everyone
onto
this
issue
like
it
sounds
like
a
kind
of
discussion
of
like.
Should
we
be
using
click
house
a
lot,
but
actually
maybe
there's
a
kind
of
pre-conversation
that
that
is
useful
for
system
to
take,
which
is
like
like
what
is
the
problem
and
try
and
actually
identify
like?
D
B
D
B
Was
going
to
suggest,
we
can
open
an
issue
to
sort
of
do
something
with
the
deployment
completed
metric,
so
you
know
in
the
process
of
using
it
or
building
a
dashboard
using
that
metric,
maybe
we'll
figure
out
some
stuff,
maybe
we'll
figure
out
what
is
not
possible.
What
is
possible
yeah.
D
A
Another
thing
as
I
just
like,
because
we
started
the
discussion
I,
just
like
encourage
everybody
like
who's
like
interested
to
discuss
it
more
in
the
issue,
because
I
like
we
didn't
get
like
like
a
lot
of
discussion
from
a
lot
of
people.
So
if
anybody's
like
is
interested
just
like
keep
discussing
there.
C
F
C
I
I
didn't
I,
didn't
comment
because
all
this
with
the
all
this
release
management
thing,
you
don't
even
have
Focus
time.
So
you
need
to
focus
in
order
to
comment
on
that.
But
I
again,
like
I,
think
that
we
definitely
should
use
cloud
clickhouse
and
it's
pretty
cool.
C
But
imagine
we.
We
have
this
very
nice.
Well,
nice,
okay,
not
nice,
but
very
rich
libraries
based
on
jsonnet
and
we
have
a
slows
and
we
have
like
a
a
lot
of
metrics
kind
of
framework
which,
which
is
already
there
and
it's
based
on
Prometheus.
And
now
we
we
we
come
and
say
like:
okay,
guys
we
are
using
clickhouse
and
then
that
literally
means
that
we
don't
have
a
support
from
other
teams
who
are
actually
using.
C
Who
who
who
built
this
framework,
and
we
need
to
rebuild
everything
from
scratch
right,
because
it's
not
fully
compatible
and
again.
A
Yeah,
like
just
adding
it
on
top
for
some
metrics
like
fully
replacing
because,
like
initially
I
rewarded
it
as
replacing,
but
it's
actually
was
just
in
the
title
of
the
issue.
So
I
replaced
this
fixed
this.
So
it's
mainly
like
for
supplementing
Prometheus.
So.
G
Then
I
think
that
what
Reuben
was
suggesting
is
a
good
idea
right,
so
finding
out
information
that
we
need
and
I
think
the
delivery
deployment
started
and
completed.
So
it
could
be
an
example
and
just
given
us
an
overview
right
so
in
Prometheus,
so
you
describe
the
problem.
We
wanted
to
count
deployment
by
whatever
the
things
you
know.
The
problem
is
and
say
what
we
have
in
Primitives
is
this:
we
can't
get
this
number
and
maybe
they're
someone
with
more
experience
like
Vladimir
can
say.
G
Indeed,
this
use
case
can
be
done
by
toggling
the
metrics
and
try
to
figure
out
if
we
can,
on
the
other
hand,
in
the
same
issue,
we
still
say
this
can
be
modeled
in
Click
house
this
way
and
showing
us
the
type
of
query
that
we
can
get
and-
and
we
continue
from
there
right-
because
it's
more
it's
more-
a
focus
of
the
discussion
where
we
can
actually
understand
what
is
missing
and
what
we
will
gain.
We
will
gain.
C
Also
one
one
more
thing
like:
if
we
considering
this
for,
like
a
specific
metrics,
then
we
introduce
kind
of
edge
cases
and
exceptions
right
so
like
we,
we
do
everything
in
Prometheus
and
then
those
two
particular
metrics
we
do
in
a
click
house.
C
I
would
better
solve
the
problems
in
a
generic
way,
rather
than
pinpointing
some
some
some
edge
cases
from
Michael.
If
we
want
to
move
to
clickhouse
for
for
metrics,
let's
just
move
everything,
not
just
specific
metrics,
I
I,
don't
know,
but
it
will
in
it
will
introduce
a
lot
of
complexity.
I
would
say,
because
you
always
need
to
think
about
those
edge
cases.
D
So
sounds
like
we
have
a
few
ideas
and
actions.
So
let's
take
that
back
onto
the
issue,
so
we
get
that
all
together,
but
yeah
I
think
that
sounds
like
they
also
like
you
know,
good
points.
So,
let's,
let's
pull
that
stuff
together.
D
G
So
I
wanted
to
sort
of
face
this
idea.
Where
did
she
even
discuss
a
tiny
bit?
So
there
is
this
rail
7
upgrade
that
is
coming
and
in
order
to
the
risk
and
everything
we
the
target
date
for
this
is
16-2
right.
So
the
idea
is
that
in
162
we
merge
the
thing
and
hope
that
nothing
breaks
and
we
do
business
as
usual,
so
something
that
came
out
during
the
first
call.
G
The
sinkhole
was
actually
the
idea
of
trying
to
do
some
kind,
some
sort
of
experimental
deployment,
those
things
that
we
have
been
discussing
in
the
past
that,
but
that
are
not
were
not
feasible,
for
something
like
Ruby
3,
which
is
a
bigger
type
of
change.
So
this
merge
request
seems
to
have
all
the
necessary
characters,
sticks
to
experiment
manually,
experiment
with
it,
because
we
don't
have
tooling
around
that.
G
G
So
the
idea
is
that
maybe
I
mean
I,
don't
want
to
say
when
when
is
not
important,
when
we
think
is
possible,
we
just
deploy
something.
We
promote
something
and
then
say:
let's
build
the
package.
Would
that
change
on
top
and
maybe
the
first
time
we
stop
after
Canary
staging,
because
we
don't
want
to
go
any
further,
but
the
idea
is
that
this
will
give
them
packaged
version.
So
they
can
query
on
metrics
and
things
like
that.
G
15
minutes
we
can,
but
the
most
important
thing
is
that
it
will
roll
back
by
itself.
That's
the
the
interesting
part
because
we
are
merging.
Basically,
we
are
putting
something
that
is
unmerged
on
Master
directly
on
the
outside
branch,
which
is
ephemeral
by
Nature,
because
the
next
autoplay
Branch
would
be
created
from
Master
again.
So
we'll
have
everything
there
was
in
the
previous
package:
minus
the
rail
7
upgrade.
G
There's
a
lot
of
manual
stuff
to
do
to
look
around
this
I
will
not
consider
spending
time
on
building
tooling
for
this,
because
it's
a
it's
a
one-off
we
want
even
to
we
want
to
know
if
it's
possible
Right,
but
this
is
kind
of
a
good
candidate.
When
we
say
maybe
we
can
find
some
UA
UI
only
type
of
changes.
G
The
way
we
do
deployments
today
is
that
things
has
to
be
merged
on
master,
so
the
recovery
time
in
terms
of
deployment
development
is
much
higher
because
then
they
will
have
to
revert
and
everything
here
is
it's
completely
different,
because
we
give
them
a
package
that
the
package
will
live
for
hours
no
more
and
they
can
gather
information
and
go
back.
I
mean
they're
already
in
development,
it's
not
merged,
so
the
next
one
is
not
a
concern
right.
So
if
something
goes
wrong,
the
next
package
will
not
have
it.
G
Well,
yeah,
that's
the
thing:
it's
for
the
risk
in
validating
the
solution,
increase
everyone,
let's
say
confidence
in
it,
because
the
end
goal
is
that
we
would
like
to
treat
the
real
seven
upgrade
as
a
regular
migration
as
a
regular,
merge
request
right.
So
if
this
gave
us
confidence,
then
we
say:
okay,
we're
done.
Let's
merge
it
and
we'll
be
in
the
next
package.
G
No
because
we
are
not
merging
it,
so
they
are
that's,
so
they
are
already
keeping
this.
It's
a
long
lived
branch
and
they
keep
it
updated
and
rebased
on
top
of
things
that
are
changing.
So
that's
part
of
the
challenge
they
have,
and
this
is
one
of
the
things
that
say
they
consider
the
work
done
now.
We
are
kind
of
telling
them
keep
it
baking
for
two
months
right.
G
So
this
type
of
approach
will
kind
of
reinforce
our
understanding
that
is
still
working
as
well
as
kind
of
give
developers
some
kind
of
practical
things
to
work
on
right.
So
they
have,
they
can
see
the
metrics.
They
can
see
how
it
behaves,
they
can
make
changes
in
adjustment
and
and
keep
the
thing
live
instead
of
say,
let's
suppose,
oh
this
half
foot
for
two
months
and
then
we
are
back
on
Square
zero.
C
G
Yeah
I
mean
this
is
something
this
is
not.
This
is
not
the
case
right
now.
I
understand
that
we
should
fix,
so
they
are
working
iteratively.
So
right
now
they
have
28
commits.
But
this
is
not
what
we
will
do
right.
So
we
want
them
to
have
a
squashed
commit
that
they
can
pick
into
the
auto
deploy
Branch
because
they
can't
pick
the
merge.
Merge
never
happened
right.
G
So
what
I'm
saying
here
is
that
if
maintainers,
that
reviewed
this
work
say
that
this
is
ready,
they
think
that
this
should
can
be
merged
today
and
we,
as
a
company,
decided
to
postpone
this
for
two
months,
because
we
don't
want
to
merge
grade
seven
with
breaking
change
of
16.0
and
things
like
that.
So
we
are
de-risking
everything.
That's
why
we
are
doing
this
as
well
as
there
are
some
kind
of
impact
with
backboarding
right,
because
every
release
will
be
three
times
back
and
we
don't.
G
G
This
will
be
in
any
case
right,
so
because
the
moment
we
switch
backboards
may
be
affected
by
the
fact
that
may
not
work
on
on
previous
rails
version,
but
at
least
we
are
kind
of
reducing
the
number
of
changes
in
between,
and
so
this
is.
This
is
why,
oh,
this
is
taking
time,
but
the
work
seems
to
be
done
so
if
they
say
that
it's
okay
to
merge,
they
can
create
a
single
commit
to
put
on
top
of
Auto
employers,
and
we
just
merge
it
on
auto
reply.
C
And
another
question:
so
if
we
are,
if
you
are
thinking
that
to.
C
Deploy
with
16.2
well,
actually,
we
are
not
we're
we're
we're
not
gonna
We're
Not
Gonna
maintain
15x
anymore
at
that
stage,
right,
yep,
okay,
yeah!
That's
that's
a
good
idea!
Yes,.
G
It
can
happen
right
if
something
is
really.
We
had
exception
in
the
past
for
something
very
big
that
we
backborted
more,
but
I
mean
it's
specific
to
some
fixes.
That
is
really
important.
Then
someone
will
check
those
fixes
in
rates
seven
as
well
and
before
16.0.
D
So,
just
in
the
interest
of
time
I
think
generally,
it
sounds
like
a
great
proposal
Alessio
if
the
developer,
like
development
team
for
the
rails
team,
also
agree,
then
at
that
point,
can
we
maybe
spend
some
time
with
Vladimir
and
Myra
and
figure
out,
like
you
know,
practical
steps
that
we
want
to
make
sure
we
have
in
place
to
to
try
and
actually
see
if
we
can
do
this.
D
Great,
so
is
there
any
final
stuff
anyone
wants
to
bring
up
on
this
recording.