►
From YouTube: Core Devs Meeting
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).
B
B
C
C
A
Sure
I
can
start
with
that,
so
cuz
sticker
market
is
still
in
the
audit
process.
As
far
as
I
know,
we
are
making
really
good
progress
within
core
UI,
andre,
shipped
basic
custom,
PRC
20
token
support
today,
I
believe
Eric's,
making
some
improvements
to
wallet,
transaction
history
and
way
we
retrieve
transactions
and
persist
transactions
and
Julian's,
making
good
headway
on
the
new
ENS
registration
and
verification
flow,
which
we're
moving
into
the
application
for
various
reasons,
and
there
are
notes
I
can
share
if
you're
interested.
The
one
point
that's
relevant
to
others
on.
A
This
call
is
just
that
with
tribute
to
talk
running
into
a
lot
of
problems
with
ipfs,
and
we
aren't
necessarily
able
to
host
information
well
or
not
retrieve
the
information
that
we're
hosting,
which
we
talk.
The
manifests
not
quite
sure
why,
but
basically
we're
looking
into
other
solutions
for
that
one
option
being
to
have
our
own
hosted,
ipfs,
getaway
and
the
other
to
be
or
the
other
being
to
actually
switch
over
to
hosting
the
feature
on
swarm
instead.
A
E
E
Okay,
because
I
found
out
that
apparently
the
the
hashing
firm
ipfs
is
actually
non
non
deterministic,
so,
depending
on
the
way
that
we
chunk
how
you
chunk
those
files
when
you're
uploading
them,
the
hash
could
be
entirely
different,
which
kind
of
defeats
the
point
so
I'll
be
asking
I'll
be
asking
the
swarm
guys
if
that's
still
an
issue
this.
If
that
is
an
even
issue
with
swarm,
this
Thursday
on
Friday
you're.
A
F
C
D
D
Meanwhile,
for
the
scalability
part,
we
would
look
at
side
chains,
namely
appear
way.
We
currently
stuck
with
this.
With
this
issue,
we
contacted
the
the
POA
team
and
they're
they're
looking
into
this
issue.
We
also
looked
at
Radian,
but
it
seems
it's
not
really
in
a
ready
state
or
usable
state
for
our
particular
use
case.
D
Then,
liquid
funding
I've
been
trying
to
push
that
past
the
finishing
line
or
our
goal
now
is
to
compile
the
list
of
workflows
needed
and
and
deploy
to
to
may
not
as
as
soon
as
we
can
so
this
this
upcoming
week,
then
for
well.
What's
that
you
want
to
embark
to
yeah
for
yeah,
so
for
apart,
we've
been
doing
a
lot
of
things
under
the
hood,
namely
that
we
we
started.
C
F
I
great
pick
that
up
nice.
In
terms
of
like
that,
the
blog
series
we
have
going,
we've
done
a
lot
of
work
here
at
this
weekend
watching
week.
I
have
the
original
draft,
the
interactive
draft,
one
token
economics
for
eNOS
usernames
finished,
or
at
least
like
the
initial
draft
waiting
on
some
of
the
for
through
it
and
feedback
on
what
we'd
like
to
include,
which
is
probably
mostly
going
to
be
gathering
available
data
and
coming
up
with
reasoning
behind
the
defaults
we
choose
during
that
draft.
But
it's
a
it's
pretty
interesting.
C
C
C
G
The
problem
with
coming
now
is
that
mostly
everything
that
we
are
building
is
a
doubt.
So
of
doubt
that
we
mean
here
is
this
is
equity
organization
that
is
able
to
take
decisions
in
a
decentralized
way.
This
is
what
we
are
calling
Dao
here
and
that's
why
we
keep
funding
is
being
called
a
doll
just
because
of
this
case
of
it's
being
able
to
fund
swarms
being
decentralize
it.
G
That
was
one
of
the
purposes
of
the
original
data
and
and
then
we
also
have
this
topic-
democracy
that
is
not
used
to
fund
swarms,
but
you
configure
eight
smart
contracts
in
a
decentralized
way
to
replace
the
only
Ulmer,
and
this
ins
also
adds
a
dow
and
yeah.
So
we
should
not
count
everything
dows,
then
we
that
that's
confusing
not.
C
G
C
H
H
F
Just
had
our
weekly
a
swarm
meeting
on
that
one,
it
doesn't
seem
like
there's
a
lot
of
updates
there.
Andre
I
did
some
work
as
a
POC.
That's
that's
ready
and
I
think
the
topic
democra
or
the
topic
discussion.
This
is
on
the
agent
of
her
for
discussion
of
litter
day.
All
in
this
call,
yeah.
A
There
yeah
I
can
give
a
quick
update,
so
the
team
isn't
working
on
a
couple
things.
One
is
making
sure
that
everything
is
now
trapped
inside
a
break,
there's
a
training
Happiness,
often
at
3:30.
If
anyone
wants
to
join
so,
basically,
all
the
major
swarms,
as
well
as
our
launches
are
able
to
be
visualized
and
tracked,
and
what
are
the
dependencies
interpreting
like
that?
So
that's
one
project
that's
been
happening.
Also,
there's
an
it
has
been
attempted.
A
Try
and
streamline
some
of
the
review
process
is
that
in
fact
that
have
been
happening
so,
for
example,
is
something
ready
for
is
something
ready
for
launch?
Is
something
ready
to
go
from
ideation
to
specification
and
things
like
that
and
having
a
clear,
documented
process
for
that,
because
right
now
you
know
things
are
updated
inside
of
the
github
ideas
repo,
but
then
no
one
really
no
one
really
folders
up
and
you
can't
really
black
hole
so
that
those
are
the
main
process
related
things
over
I
can
making
it
clear
kind
of
review
process
yeah.
E
Yeah
exactly
that
and
just
the
sort
of
instigator
in
terms
of
wanting
to
clarify
the
review
process,
we
found
in
a
few
different
areas,
we've
been
kind
of
getting
to
us
the
latest
stage
in
the
sort
of
implementation
process,
where
it's
being
clear.
This
and
things
haven't
been
well
specified,
so
we're
just
trying
to
like
make
sure
we're
getting
a
lot
better
at
that.
C
C
I
You
hear
me
now:
yes,
cool
thanks,
yeah,
a
quick
update
on
what
we're
working
on
on
the
keycard
team
so
for
the
integration
within
status,
app,
Demetri
and
nastya
I've
solved
all
the
high-end
medium
severity
bugs
so
there's
a
bill
coming
in
in
the
coming
days.
So
next
step
is
to
implement
the
new
I
mean
the
updates
that
been
done
by
mostly
Andre
and
Esther
to
the
onboarding
and
logging
strains
this,
as
well
as
the
ledger.
Hopper
integration
we
also
working
on
the
multi
account
support
within
status
wellit's.
So
we
still
in
a
research
phase.
I
I
I'll
share
with
you
the
link
to
the
merge
field,
counter
team
page
where
you
can
find
all
the
links.
If
you
want
to
join
these
discussions,
I'll
add
that,
on
the
good
part,
Andreea
is
in
charge
of
this,
and
andraia
has
also
started
to
look
at
the
designs
for
disability
account,
work
and
last
thing
we're
working
on
is:
we've
started
some
concrete
discussion
about
support
of
point
of
sale
scenarios
for
end
of
August
for
at
Berlin,
so
we
basically
trying
to
answer
the
question:
can
we
do
something,
but
that
time,
what
would
it
be?
C
F
C
J
Yeah,
thank
you
so,
basically,
as
you
probably
already
know,
we
would
like
to
move
away
from
having
a
single
topic
for
whisper.
We
had
a
few
proposals,
but
the
main
issue
was
that
basically
it's
it's
difficult
to
make
it
back
or
compatible
like
you
know,
like
it's
borderline
impossible
because
of
the
way
and
applicational
structure,
so
we
run
directly
a
whisper
there's,
no
other
layer
on
top
of
that.
So
we
have
no
knowledge
of.
You
know
how
many
clients
that
are
on
the
other
side.
J
We
use
the
move
to
cast,
so
we
sent
to
a
public
key
and
we
have
no
central
place
where
we
think
we
have
account
information
and
so
basically
there's
no
way.
We.
We
know
that
the
users
pin
up
on
your
device,
and
so
we
talked
about
it
and
one
solution
proposed
was
to
move
to
a
device
to
device
communication.
So,
instead
of
sending
a
mess
to
a
single
account,
public
key
I
send
a
message
to
all
the
devices
this
user
has,
you
know
not
all
of
them,
maybe
three
devices
or
whatever.
J
In
that
way,
we
can
actually
start
making
negotiation
about
copy,
because
basically
I
knew
exactly
which
device
I'm
targeting
it
I'm,
not
eating
them.
They
won't
receive
the
message
anyway,
and
so
next
step
would
be.
Do
you
have
a
protocol
to
basically
negotiate
a
new
topic
so
that
we
can
move
away
from
there
from
the
share
topic?
So
I've
made
a
proposal
on
discuss
of
you
had
a
chance
to
take
a
look
at
it.
J
A
space
simple,
basically
like
the
ideas
that
we're
gonna
have
version
information
with
each
device
which
propagate,
if
is,
if
one
bit
of
device
is
sending
a
mess,
send
a
message
to
another
device
that
has
a
compatible
version.
It's
gonna
do
it.
If
you
Hellman,
it's
gonna,
run
DC
on
the
argument
over
his
own
public,
his
own
private
key
and
the
public
key
of
the
receiver,
and
it's
gonna
be
done
a
topic.
You
know
like
it's
gonna,
be
a
secret
key
and
then
with
our
topic,
and
we
use
the
secret
key
for
this
topic.
J
So
the
first
message
is
not
gonna
be
sent
on
this
topic,
because
the
other
user
would
not
know,
but
the
user
will
start
the
either
sending
the
message
we
listen
to
this
topic.
He's
gonna
send
a
message
on
the
share
topic.
The
other
device
is
going
to
receive
this
message.
It's
gonna
drive
the
same
key.
It's
gonna,
listen
as
well
today
as
the
topic.
So
at
this
point
both
devices
are
listening
to
the
same
topic.
J
The
next
message,
the
receiving
end
will
send
will
be
on
the
new
topic
and
once
the
initial
one
initially
sent
a
message
we
receive.
This
message
will
know
that
this
topic
has
been
a
knowledged
and
the
conversation
can
continue
on
topic.
So
that's
only
for
the
case
for
the
simple
case
where
there
are
two
devices,
but
it's
complicated
from
the
part.
That's
me,
you
can
have
multiple
devices,
and
so
basically,
if
you
have
multiple
devices
before
you
can
actually
everyone
can
move
on
to
new
topic
you
need.
J
It
may
need
to
be
each
devices
of
knowledge,
this
new
topic,
and
so
that's
what
basically,
this
proposal
explores.
You
know
how
do?
How
can
we
make
things?
I
can
make
it
work,
and
so
it's
not
easy,
meaning
that
you
know
like
again
we're
dealing
with
most
your
flying
devices
and
so
a
mobile
phone
can
be
switched
off
for
a
day
or
so
and
that's
not
uncommon.
You
know,
like
you
might
not
start
there,
he
might
have
desktop
running,
but
no
you
mobile,
app
running
and.
G
I'm
sorry
real
cute,
but
the
the
the
issue
about
multiple
device
is
I
think
the
way
we
implemented
the
multiple
device
supports
is
wrong.
We
should
not
use
the
same
key
for
the
same
four
different
devices.
So
if
we
had
another
key
for
another
device,
maybe
we
can
that
could
be
easier
to.
So
what
do
you
think?
It's.
J
Identical
so
the
issue
I
mean
I.
I
agree
with
you
completely
agree
with
you
there's
you
know
like
multiple
devices.
We
should
not
have
the
same
key.
That
I
completely
agree
with
you,
and
the
thing
is
that
you
know
like
you,
don't
sit
still
the
same
problem
at
some
point.
You
don't
know
if
this
device
is
offline-
and
you
know
you
don't
really
want
to
send
you
know
you
don't
want
to
negotiate
a
topic
individually
with
each
with
each
device,
because
otherwise
there's
no.
J
If
you,
if
you
have
to
send
a
message
to
share
topic,
then
you
know
you,
you
lost
all
the
bandwidth
saving
right.
So
if
I'm
targeting
three
devices
and
one
of
them
is
still
on
the
topic,
I
will
have
to
send
a
message
on
the
share
topic
and
its
cover
topic
and
essentially,
if
there's
no
bandwidth
saving,
so
you
would
still
have
the
same
problem.
But
I
I
agree
with
you
that
multiple
device
is
much
better
if
we
have
separate
key
for
each
device.
So.
I
J
C
In
the
same
way,
it's
like
when
we,
for
instance,
switch
to
some
other
format
of
that
you
know
protocol
encoding,
correct.
We
use
further
back
instead
of
transit
or
we
use
not
slice,
maybe
something
else
together
with
whisper,
something
to
be
able
to
graduate
speech.
If
we
have
this
device
negotiation,
it's
open
strikes
more
way
to
more
ways
to
upgrade
protocol
in
different
ways.
G
G
The
primary
device
will
be
probably
the
smartphone
or
I'm,
not
sure
exactly
the
I
know
idea,
but
then
they
make
a
secure
connection
directly
outside
whisper
and
then
they
synchronize
the
the
information
they
maybe
use
the
the
whisper
to
establish
this
connection,
but
not
choose
the
messages
in
context
and
whatever
so
I
was
imagining
a
different
way
to
solve
the
problem
of
synchronization
between
devices.
So
maybe
we
can
have
that.
We
can
have
this
solution,
that
you're
proposing
for
separation
of
topics.
E
But
one
thing
here
is
that
say:
for
example,
Dean
has
worked
on
a
mobile
network
over
the
past
few
couple
of
days
and
got
like
a
hacky
version
of
running.
So
there's
the
ability
to
have
different
transports,
but
I
think
the
underlying
mechanism
of
synchronization
should
run
irrespective
of
the
transport
that
is
running
on
top
of.
J
Yes,
so
that's
that's
how
it
stands
at
the
moment.
So
just
to
you
address
the
point,
so
like
the
solution,
you
know
like
the
Ricardo
solution
in
this
kind
of
solution
generally
like
rather
in.
If
you
look
at
other
protocols,
they
tend
not
to
use
this
kind
of
resolution
because
you,
you
can't
have
you
can't
rely
on
one
device
being
online
or
one
device
not
being
no
cannot
be
lost.
If
you
lose
that
device,
you
have
a
master
device.
J
Then
if
you
rely
on
a
master
device,
then
if
you
lose
that
master
device
becomes
problematic
so,
like
generally,
what
they
do
is
they
use
either
always
online
server.
So,
like
you
could
you
could
have
the
same
cells
using
this
woman
IPS
example?
So
you
have
a
single
point
and
you
know
they
every
device
synchronize
with
that
and
that's
the
source
of
truth.
But
if
you
have
multiple
source
of
truth,
you
know
we
are
among
your
devices
that
becomes
problematic
if
you
rely
too
strongly
on
one
or
the
other.
J
So,
like
seems
like
at
the
moment,
we
they
all
share
information
among
them
devices
already
and
they're,
both
via
the
room.
You
know
like
anyone
can
bribe.
You
know
the
basic
like
free
master
devices
that
synchronize
across
them.
We
don't
want
to
rely
too
strongly
on
one
device
being
the
master
and
you
don't
want
to
rely
too
strongly
on.
J
Essentially
this
synchronization
happening.
You
know
the
case
much
as
much
most
people
tend
to
use.
The
descender
will
target
three
devices
rather
than
target
one
device,
and
then
these
device
sinks
that's
bound
to
fail.
That's
not
gonna
work
extension,
so
you
know
we
can
discuss
it,
but
these
things
needs
to
be
technical
civilization.
J
B
G
So
I
agree
with
your
points
and
we
probably
can
find
that
find
a
solution
that
that
some
tweaks,
all
these
points
that
you
that
you
maintain
it
but
yeah
but
I,
think
that's
more
important
than
the
synchronization
of
devices
is
the
reduction
of
the
traffic,
the
network
traffic
traffic
and
at
all
so
I
think
that
that
this
should
not
be
a
blocker.
So
maybe
we
can
disable
this
week
minimum.
G
F
I
have
a
have
a
question
regards
there
like
how
this
may
work
in
the
inside
deal.
Ideal
scenario
say,
for
instance,
we
go
with
this,
and
the
main
whisper
topic
becomes
basically
a
negotiation
topic
that
allows
peoples
are
then
offload
into
fragmented
topics.
As
we
scale
it,
users
does
that
negotiation
topic
just
become
become
just
as
congested
as
it
is
now,
even
if
we
have,
even
if
we've
moved
a
good
portion
of
the
actual
conversation
elsewhere,.
J
J
J
If
we
left
to
support
still,
you
know
we'll
have
potentially
to
send
again
back
on
to
the
discovery
topic
with
this
ascension.
Like
we
start
from
the
discovery
topic,
then,
if
we
have
any
information
about
the
devices
and
we
potentially
use
the
partition
topic,
then
we
negotiate
the
topic
on
whatever
we
decide.
We
know
whatever
is
available
discovery
topic
for
all
the
devices
and
partition
topic
for
newer
devices.
J
So
eventually
we
know
like
we
can
imagine
that,
eventually,
with
the
less
and
less
traffic
we're
going
to
discover
topic
more
traffic,
we
put
partition
topic
which
will
essentially,
we
know
how
it's
gonna
scale.
It's
got
scales
similar
to
what
they
discover
topic
skills.
Now,
at
the
moment,
we
have
DDI
files
in
different
topic
and
we
assume
the
keys
are
randomly
distributed
across
them
and
then
once
these
two
devices
of
a
conversation
they're
going
to
move
on
to
the
to
their
own
topic,
essentially
yeah.
C
B
C
F
C
But
then
it's
also
the
question
we
need
maybe
some
other
negotiation
mechanism
like
think
about
it
like
later
on
why
we
still
have
enough
time,
so
we
can
introduce
it
for
the
new
versions,
but
still
use
that
for
the
old
versions
and
yeah
very
gracefully
phase
out
the
old
one
yeah
cool.
Is
there
anything
else
for
this?
C
G
G
So
the
question
is
about
the
handshake
topic:
I
think
it's
not
the
way,
we're
calling
it,
but
is
this
use
it
only
for
the
legacy,
clients
or
the
new
proposal?
Everyone
have
to
use
the
same
topic
or
maybe
the
topic
is
wasted
on
the
public
key
of
the
receiver,
just
to
clarify
that
I
didn't
get
it
well.
So.
J
Basically,
okay,
so
say
that
you
know
like
you,
oh
okay,
so
it's
me
and
you
we
both
have
the
device
as
it's
done.
If
we
have
no
information
about
each
other,
we
will
use
this
discovery.
Topic.
I
will
send
your
message,
discovery
topic,
and
so
the
iron
shake
will
happen
on
discovery
talking.
It's
just
gonna,
be
one
message
like:
oh
you
know
they
boy
you
know
depends,
but
you
know
one
message:
if
you
reply
to
this
message,
you
reply
already
on
the
new
topics
like
it's
gonna,
very
quickly,
move
today.
J
So
if
we
have
no
information
on
the
devices,
this
is
not
generally
the
case
because
the
bias
information
are
propagated,
but
yada
clean,
and
so
you
know,
I've
from
experience
most
of
the
time,
I
send
a
message
to
you.
I
already
have
information
about
your
device.
If
I
already
have
information
about
your
device,
we're
gonna
move
on
to
a
button
and
she
will
have
been
an
efficient
of
it,
which
is
basically
five
thousand
times
theoretically
less
bad
and
with
intense.
Then.
C
So,
basically,
I'll
try
to
I'll
try
to
tell
all
the
branches
of
this
tree.
So,
first
of
all,
if
I
have
no
information
about
you,
I
will
start
negotiating
with
you
on
the
the
discovery
on
this
old
topic
and
if
you
are
not
responding
to
my
ten
shapes,
then
our
1-1
conversation
just
happens
of
the
partitions.
C
Okay,
then,
if
we,
if
I,
don't
know
anything
about
you,
but
you
respond
to
the
handshake
on
the
discovery
topic,
then,
when
you
go
she
ate
on
the
discovery,
but
talk
on
the
separate
topic
that
we
negotiated
and
the
third
version.
If
I
already
know
something
about
you,
informaton,
oh
your
device,
then
we
negotiate
on
the
partitioning
topic
and
then
move
to
some
specific
topic.
So
they're,
like
this
branches,
I
understand.
E
So
the
sort
of
thing
I
mean
essentially
I,
don't
want
to
publish
the
users
public
key
on
ENS
vns
user
names,
but
rather
treat
that
public
key
as
a
sort
of
like
an
inbox
or
listening
in
books.
This
would
be
the
partition
topic
and
that
gives
the
the
end
users
the
ability
to
voluntarily
reach
out
to
the
the
requester,
but
they
would
also
do
that
under
a
different
public
key,
which
would
be
essentially
like
a
mask
which
every
chat
would
end
up
having
its
own
unique
public
key
anyway.
E
G
C
C
F
We
had
a
tack,
we
had
a
security
squad,
your
desktop
through
hacker
one
and
in
the
process
of
fixing
it
some
and
building
a
post-mortem
about
it.
We
were
still
in
the
process
of
doing
and
getting
out
so
we're
not
gonna
talk
too
much
about
that
security
issue.
There's
no
real
problems
there.
Just
to
broadcast
that
out.
F
It's
become
clear.
That
I
think
that
that
the
the
PR
process
needs
I'd,
say
maybe
additional
automation
or
transparency
or
clarity
in
terms
of
when
pr's
are
sent
and
merge.
That
doesn't
necessarily
mean
that
the
work
is
finished
and
we're
not
and
I'm
I'm
having
a
hard
time
I.
Imagine
others
are
in
terms
of
finding
where
the
baton
gets
passed
and
who
choose
taking
responsibility
as
well
as
what
needs
to
be
done
for
this
particular
issue
to
be
finished
outside
of
the
PR,
for
instance.
F
This
particular
thing
and
I
could
probably
talk
more
on
this,
but
the
PR
was
sent
and
merged.
It
did
makes
I
fix
the
issue.
Other
things
needed
to
be
done
for
the
issue
to
be
fixed
and
and
I
was
not
quite
sure
on
when
she
wouldn't
she
needed
to
start
testing
or
what
you
need
to
start
testing
on
before
she
could
say.
Yes,
this
is
you
know
the
issues
been
fixed
and
I
validated
it,
and
so
I
want
to
have
a
conversation
there
on.
F
What
we
can
do
are
on
the
PR
process
to
make
this
this
process
much
more
clear
in
terms
of
what's
required,
of
getting
the
actual
work
done
and
who's
gonna
take
responsibility
for
that
and
like
maybe
well
what
we
can
do
in
DevOps
Terr
to
automate
this
process
boss
process
in
terms
of
how
you
structure
your
PR,
I,
don't
know
Anna.
Do
you
want
to
adding
anything
to
this.
H
Yeah,
it's
hard
to
to
add
more
details
without
actually
mentioning
the
issue,
but
I
will
try.
So
let's
say
it
concerns
only
issues
that
would
result
result
in
some
hot
fixes
done
on
desktop
or
mobile,
or
maybe
on
both
types
of
the
app
we
have
so
like,
if
you,
for
example,
as
a
developer,
prepared
the
PR
but
like
how
it
would
help
me
as
a
tester
I
need
like
a
very
precise
information
on
what
should
be
done
next
in
order
to
us
for
us
to
push
the
hotfix
out.
H
So
PR
is
like
just
a
start
right,
like
testing
needs
to
check
it.
Probably
if
it's
a
hotfix
testing
does
not
need
to
check
the
PR
itself
because
developer
already
checked
it,
but
testing
would
need
some
release
built
created
from
a
boil
up
of
a
desktop
up
or
for
both
desktop
and
mobile,
and
then
testing
would
need
to
start
it,
and
this
is
like
the
gap.
I
see
right
now
that
again
we
have
some
assumptions
that
it's
it's
enough
to
merge.
The
PR
build
the
release,
build
and
it's
over.
Like
it's,
it's
ready.
It's
done.
H
It's
pushed
the
like
problem
that
sometimes
it's
not
enough.
Oh
like
release
builds,
are
failing
and
again
we
don't
have
like
exact
owner
of
this
thing
like
test
team.
Would
ping
Jakob
Jakob
would
look
why
Jenkins
is
failing
and
it
just
takes
longer,
especially
when
you
have
this.
You
know
times
that
actually
ticking
and
it
you
need
to
deliver
the
hotfix
as
soon
as
possible.
H
Actually
each
minute
counts
so
like
just
making
sure
that
when
you
created
a
PR,
you
kind
of
care
about
it
and
pull
it
to
the
next
state,
and
the
next
state
would
be
again
probably
delivering
the
release
built
that
contains
a
fix,
I
really
don't
care.
I
would
be
that
PR,
a
bunch
of
tears,
change
of
the
junk
and
setting
really
don't
care
I,
just
like
on
the
testing
site.
I
need
a
clear
signal
on
here.
Is
your
release
build?
This
is
the
changes
we
have
done.
That
would
fix
the
problem,
start
testing
it.
F
Okay,
thanks
Anna,
that's
we
have
a
clear
like
that's
a
that's
one
identified
problem
in
the
PR
process.
We
need
to
basically
make
it
more
clear
that
this
is
required.
These
are
the
required
steps.
They
need
to
be
done
before
testing
can
start.
Is
there
any
that?
Can
anyone
else
here?
It's
got
us
any.
Maybe
issues
that
they're
currently
having
with
the
PR
process
so
that
we
can.
We
can
take
a
look
at
how
to
fix
that
a
good
time
to
speak
up
if
you're,
if
you're
pissed
off
about
something
or
annoyed.
C
C
It
should
be
a
little
bit
because
sometimes
it's
it's
obvious
that
yeah
we
it's
very
easy
to.
Oh
I
push
this
PR,
so
I
fixed
it
and
it's
done,
but
sometimes
it's
like
yeah
just
you
need
to
actually
follow
up
on
your
PR
to
make
sure
it's
included
and
the
right
commits
are
included,
and
things
like
that.
F
Or
if
or
if
you
need
to,
you
need
to
reference
other
PRS
and
the
state
of
those
things
if
they're
dependent
upon
like
if
something
is
dependent
upon
you
finishing,
but
the
actual
released
as
a
good
cut,
until
maybe
one
or
two
others
are
finished.
Based
on
that
dependency,
you
need
to
work.
Those
need
to
be
referenced
appropriately
so
like
what
can
we
do
to
make
sure
that
gets
done
automatically
so
that
people
aren't
working
based
on
assumptions
of
others?.
B
B
B
So
it's
difficult
to
get
the
second
with
you
in
in
order
to
be
able
to
merge
and
I
regularly
have
three
or
four
pull
requests
open
and
unless
I
go
out
solo
on
status
and
pink
mag
people
about
it,
they
will
stay
there.
So
I
don't
know
if
it's
a
question
of
making
it
clear
that
those
are
as
shorts.
We
use-
and
maybe
we
could
add
something
to
the
titles
saying
like
an
estimation
of
the
size
or
the
time
taken
for
the
review.
F
B
B
H
Some
extent
that
helps
but,
for
example,
I,
do
create
such
issue
umbrella
issue
for
normal
release
like
release
number
12
as
a
teen,
you
can
even
check
in
the
github
so
just
to
track
how
release
is
going
would
to
be
included.
What
other
steps
to
be
done
besides
including
issues
and
testing,
but
the
like
again,
the
trick
for
hotfix
was
it.
H
It
was
not
quite
clear
what
else
should
be
done
and
it
was
even
not
super
clear
to
other
developers
in
the
team
like
okay,
there
is
a
PR
and
there
is
some
as
appear,
but
we
still
don't
know
I,
have
it
done
or
not
like
if
this
pair
would
be
merged
to
the
release.
I'm.
Sorry
again,
I
am
I
will
not
talk
about
the
details
so,
but
it
was
some
binaries
to
be
whatever
built,
not
in
the
bill
that
we
usually
useful
for
the
release.
B
I
think
I
remember
the
situation.
I
happened
to
see
the
the
disguise
about
this
and
I
think
to
people
saying
okay,
this
needs
to
be
an
eunuchs
built
needs
to
be
changes
going
on,
but
yet
I
think
right
now,
since
not
everyone
is
up
to
date
with
how
NYX
is
working
is
probably
not
clear
how
things
get
updated
and
you
know
hopefully
with
time
that
also
will
be
clear
on
people's
minds
and
more
present.
G
G
H
How
we
usually
don't
like
how
it's
usually
done
for
typical
PR,
we
like
we
do
test
built
for
the
PR
only
and
then
when
it's
tested,
okay,
it's
merch
to
the
nightly,
so
there
is
no
problem
there.
It's
like
it's
a
normal
release,
sorry
not
released,
but
it's
a
normal
process
for
typical
pairs
here,
I'm
talking
about
the
PR
that
is
supposed
to
fix,
let's
say
a
critical
issue
or
security
issue,
and
we
need
to
release
hot
fix
for
it.
Okay,.
F
H
Yes
and
like
from
my
point
of
view,
we
can't
automate
it
because
at
that
moment
they
don't
know
in
like
enough
to
say
if
this
is,
and
this
like
would
fix
it
or
whatever
would
be
enough.
Probably
the
author
legs,
the
developer
created
PR
that
is
supposed
to
fix.
The
issue
knows
a
bit,
especially
if
this
person
is
knowledgeable
in
like
some
area
like
desktop
I,
don't
know
wallet
anything.
H
G
It's
difficult
for
you
to
attest,
for
example,
a
complex
Onam
anomaly
on
the
under
the
interviewed,
for
example,
let's
say
a
function
that
you
do
inside
of
the
of
the
app
that
you
don't
know
how
to
do
it
because
it's
you
need
like
some
exploits
something
like
that's
prepared
to
test
it.
So
that
would
be
the
problem
on
understanding
if
it's
fix
it
or
not,
and
it
may
be,
then
these
hot
fixes
that
are
needed
they
could
come
with
with
a
test
exploit
or
maybe
something
like
that
to
make
it
easier
for
you
to
test.
F
Okay,
I
think
I'd.
A
lot
of
this
could
be
solved
by
just
having
more
of
a
standardized
template
for
what's
required
in
terms
of
getting
a
hot
like
getting
a
hot
fix
through,
and
so
when
people
are
writing
these
things
out
in
submitting
PRS,
they
can
it's
just
there's
a
there's,
a
certain
amount
of
things
that
you
have
to
include
in
these
types
of
PRS,
so
that
everyone,
the
organization,
can
understand
what
needs
to
be
done
before
it's
considered
finished,
as
opposed
to
just
saying
you
know,
I
fixed
it
go
ahead.
It.
G
In
this
case
with,
there
is
the
case
of
a
security
vulnerability
enough
security
fix
how
the
users
would
be
informed
to
update
them.
But
let's
say
that
is
something
very
critical
and
then
the
users
would
need
to
plated
like
I.
Don't
see
any
way
to
send
a
message:
a
there
is
a
new
version
of
stages.
You
should
update
it.
Maybe
it's
something
that
we
should
start
thinking
of
having
maybe
something
related
to
the
work
of
Jared
on
the
smart
contracts
for
releasing
status.
G
F
The
only
way
we
can
do
that
that
can't
be
spammed
is
if
we
have
a
a
sigil
either
service
that
we
can
have.
Control
of
that
is
hooked
into
the
app
itself,
at
least
so
far
as
I
can
tell.
Maybe
we
could
do
it
there,
a
smart
contract
and
so
that's
controlled
by
multi-sig.
We
can.
We
can
message
through
that
that
the
app
is
hard-coded
with,
in
terms
of
like
an
emergency
type
of
situation,
where
you
can
send
the
various
message
that
will
automatically
pop
up
with
some
modal,
but
in
terms
of
using
whisper.
F
Rigor,
hotfix
/
security,
high
fixed
process,
so
that
it
becomes
more
clear
in
terms
of
how
these
things
get
fixed
and
what
needs
to
be
done
until
we
can
consider
them
fixed
and
and
then
how
to
pass
the
baton
on
various.
There
are
stages
along
that
process
so
that
it's
not
like
I,
don't
I,
don't
want
to
have
anything
that
we
do
in
terms
of
development
ever
be
driven
by
assuming
things
I
assume.
This
is
what
needs
to
be
done
before.
C
So
then
it's
discussed
coast
or
something
like
that
ya
know,
yeah
and
I
think
that's.
It's
also
shouldn't
be
mixed
with
a
normal
release
process
and
because
hot
fixes
they
require
a
little
bit
different
because
for
the
normal
releases
we
usually
can
just
divorced
years.
Just
postpone
the
release
ins.
Do
it
like
a
few
weeks
later,
but
it's
not
true
for
critical
security
issues,
and
so
it
requires
a
little
bit
more
attention.