►
From YouTube: New Tag or New Release Form
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
Okay,
so
we're
here
to
talk
about
an
item-
that's
been
on
the
back
burner
from
a
vision
perspective
for
for
quite
a
while.
Now
we
have
this
concept
of
new
release
form
and
we
also
have
a
new
tag
form
and
we
need
to
make
a
decision
on
if
we
want
to
go
forward
with
one
or
the
other,
mainly
we
need
to
focus
on
do
we
want
to
support
both
forms
and
both
ways
of
creating
tags
or
releases
inside
of
gitlab,
but
then
also
on
a
bigger
topic.
A
A
This
issue
that
nathan
created
a
few
months
ago
about
updating
the
new
tag
page
to
really
you
reuse,
a
new
release
form,
and
initially
this
would
say
that
we
are
aligning
and
nathan
correct
me
if
I'm,
if
I'm
wrong,
but
we
would
be
replacing
the
way
that
people
create
new
tags
from
the
new
tags
page
to
create
a
new
tag,
but
also
release.
At
the
same
time,.
B
Yeah,
that
was
that
was
kind
of
my
initial
thought.
Is
that
we'd,
the
new
release
page
and
the
new
tag
page
would
look
really
similar.
I
I
don't
know
if
I'm
100
on
board
with
that
idea
anymore.
I
think
vlad
may
have
convinced
me
otherwise,
but
that
was
my
original
idea.
Okay,.
A
C
A
But
it
would
also
mean
that
patterns
of
behavior
that
people
who
are
potentially
coordinating
releases
in
the
ui
today
could
could
be
different,
meaning
that
they
may
be
creating
the
tag
and
then
updating
the
tag
with
release
notes
after
the
fact
to
pull
it
onto
the
releases
page.
So
there's
some
behaviors
that
we
may
need
to
change
with
other
documentation
or,
just
you
know,
coaching
customers
to
do
things
differently.
A
C
Vlad
can
I
I'll
just,
I
think,
the
the
the
issue
of
having
two
forms
that
are
actually
slightly
different
and
but
feel
similar
functions.
Is,
I
don't
know
it's
a
little
bit
confusing
from
a
ui
perspective.
Do
you
think,
because
so
originally,
probably
originally,
the
new
tag
form
was
just
like
just
create
a
tag,
but
then
we've
at
some
point
we've
got.
You
know
where
you
can
also
kind
of
create
a
release.
C
D
Yeah-
and
that
was,
I
think,
the
main
feedback
from
when
we
showed
the
initial
prototypes
of
the
new
release
page,
where
you
have
the
option
to
create
this
tag
or
kind
of
expand
and
collapse.
The
the
rest
of
the
form-
and
you
see
the
release,
form
and
people
are
very
overwhelmed
with
having
all
the
information
related
to
releases
in
the
forums
page,
but
in
a
way
that's
what
github
does
as
well
right.
C
C
B
I
don't
know
I
kind
of
like
that
idea,
because
it
we
still
kind
of
keep
the
separation
between
the
tags
and
releases
like
you,
can
create
a
tag
without
a
release,
but
then
we're
always
creating
releases
through
the
same
flow.
We're
not.
We
don't
have
two
forms
to
create
releases,
so
I
think
what,
regardless
of
what
you
do,
is
you
get
rid
of
the?
B
We
should
get
rid
of
the
two
pads
to
create
releases,
and
that
would
be,
I
think,
that'd,
be
a
good
option.
C
And
so
yeah,
so
if
we
have,
we
have
some
way,
though,
to
link
so
you're.
Still
still,
you
still
go
to
the
second
page
to
create
the
release,
but
you
know,
maybe
maybe
when
it
goes
back
to
present
the
tag,
there's
a
link
that
says:
do
you
want
to
create
this?
You
know
turn
this
into
a
release
or
I
don't
know
something
like
that:
yeah
exactly
yeah,
but
then
we'll
just
go
to
the
other
page
yeah.
A
A
I
think
that
was
a
toggle,
though
oh
yeah
there
was
a
toggle.
A
Yeah,
so
the
toggle
collapse
was
the
interaction
that
wasn't
preferred,
but
here
it
would
be.
They
fill
up
the
tag
information,
they
click
the
check
box.
I
also
want
to
create
a
release,
it
clicks,
save
and
then
maybe
that's
when
it
populates
the
additional
release,
fields
that
they
could
then
fill
out
at
the
same
time.
So
then,
the
actions
in
the
back
end
is
tag
is
created
and
then
it
redirects
the
user
to
the
releases
page.
C
B
C
Would
something
like
we
just
don't
even
ask
them
up
front
and
you
just
create
a
tag
and
then
you
know
the
tag
is
created
and
then
maybe
there's
a
link
saying
create
a
release
on
this
tag.
C
So
that
you're
not
you're
not
having
to
make
a
decision
upfront,
but
the
the
the
only
negative
that
is,
it
would
be
a
two-step
because,
but
you
know
maybe
you
could
just
to
keep
it
as
simple
as
possible.
This
is
a
tag
and
then
you
know
I
would
like
to
create
a
release
from
this
tag.
A
I
like
that,
because
we
could
have
the
option
of
like
I
have
a
tag
and
then
I
have
a
maybe
a
release.
That's
been
created
and
I
want
to
associate
and
already
create
a
tag
to
that
release
like
we
would
we.
C
A
C
So
so
I
noticed
that
in
I
noticed
the
option
of
there
was
some
discussion
about
releases
with
our
tags,
which
I
know
we're
going
to
I'm
a
bit
hesitant
because
I
think
it's
going
to
be
a
big
change
to
to
do
that.
I
I
think
the
the
eventual
point
could
be
exactly
what
you're
describing
jackie,
but
I
think
we
should
take
it.
C
A
So
that
means
that
a
tag
and
a
release
in
his
world
are
exactly
the
same
thing:
they're,
not
different
in
other
enterprises
and
customer
worlds.
A
release
is
a
workflow
and
a
tag.
Is
that
moment
when
code
has
been
released
or
produced
like
a
production,
change
has
been
made
and
they
would.
That
would
be
one
event.
C
Yeah
I
completely,
I
completely
understand
that
and
and
accept
that
we,
you
know
we
we
have
to
move
to
that.
I'm
just
saying
as
part
of
this
particular
issue,
you
know
kind
of
park
that
and
then
make
it
a
subsequent
issue
of
disconnecting
the
tag
from
the
release
I
just
I
just
feel
it
would
be
too
much
in
one
issue.
A
I
I
agree
with
you
that
that
would
this
is
more
like
a
conceptual
statement
in
that
we
want
to
support
draft
releases
in
the
future,
so,
whatever
path
we
take
right
now,
we
should
think
of
that
as
an
iterative
step
to
this
idea
of
eventually
supporting
something
like
a
draft
release
in
the
future.
A
You
have
to
create
a
new
release
like
what
people
people
are
doing
today,
I
think,
are
creating
the
release
with
a
fake
tag,
fake
tag,
it's
a
it's
a
real
tag,
but
it's
not.
A
And
then
they
kind
of
rename
their
new
release
with
an
updated
tag.
Okay,
that
has
release
notes.
C
A
C
Can
I
just
make
another
general
comment
about
the
back
end
stuff
you're
talking
about
you
know
which
endpoints
are
currently
available,
etc.
In
the
api
I
mean
in
my
mind,
seeing
the
api
is
probably
one
of
the
less
difficult
tasks
right.
If
we
need
to
make
a
small
change
to
the
api,
then
you
know,
I
think
we
should
just
you
know
if
it'll
support
a
different
workflow
whatever
we
should
just
do
it.
I
think.
C
E
Yeah,
it's
yeah.
It's
definitely
quite
easy
to
change
the
releases
api
right
now.
I'm
quite
concerned
about
this
renaming
tag
right
now,
because
tag
is
also
like
an
id
basically
right
now
for
the
releases,
and
we
have
these
features.
For
example,
it's
like
static
assets
for
releases
and,
if
I
recall
correctly,
it
basically
makes
like
releases
tag
name,
something
like
downloads
and
the
pass
for
the
static
download.
E
So
basically,
if
user
changes
the
tag
name
on
the
release,
it
also
changes
the
statics,
static
path
and
yeah,
any
other
path
related
to
releases
yeah
and
since
I'm
speaking
right
now,
I
agree
with
the
previous
idea.
I
quite
like
the
idea
of
basically
adding
an
ability
to
quickly
create
a
release
from
track
after
tag
is
created,
but
not
like
adding
any
checkboxes
so
basically
like
you,
create
an
attack,
and
after
that
you
redirect
it
to
either
attack
page
or
list.
B
E
C
E
Currently,
we
have
like
two
pages
right,
one
for
tags
and
one
for
releases,
and
I
guess
it
makes
sense
to
have
a
new
release
button
on
the
releases
page
and
utah
contacts
page
and
if
it's
easy
to
add
the
release
information
after
you
create
the
attack
from
that
text.
Page
like
I,
don't
see
anything
better
than
that,
and
also
remember
that
some
people
using
tags
not
for
releases,
so
I
like.
Maybe
they
don't,
need
all
these
controls,
even
the
checkbox
will
be
redundant
for
them.
B
Not
to
get
too
deep
into
like
how
we
implement
something
like
that,
but
there
is,
I
see
in
our
in
the
pajamas.
We
do
have
a
toast
control.
We
don't
use
that
very
much
currently,
but
that
could
be
something
like
you
create
a
new
release.
It
redirects
you
back
and
then
there's
a
toast
pop-up.
That
shows
and
says
you
create
a
new
tag.
Do
you
want
to
create
a
new
release
off
this?
C
D
We
don't
use
those
in
that
context.
We
would
use
a
banner,
for
example,
in
the
the
top
to.
D
Or
I
think
that
another
component
is
a
new
one,
I'm
not
sure
if
it's
a
drawer,
but
there
is
something
that
is
like
contextual,
that
stays
on
it's
an
overlay
in
the
screen
and
I'm
also
very
fond
of
this
idea
of
continuity
because
jack.
We
talked
about
this
recently
that
trying
to
connect
the
the
functionality.
So
if
we
can
have
tags
and
then
from
text
there
is
something
in
the
ui
something
on
the
project
that
says
hey.
You
can
also
create
a
release
from
this
tag.
D
Here's
the
way
to
do
that,
a
call
to
action
or
whatever.
Perhaps
that
would
give
a
different
or
give
us
a
different
feedback
from
having
everything
in
one
form
and
overall,
instead
of
overwhelming
people
with
releases
and
texts
all
coupled
together.
I'm
curious.
A
A
Is
that
accurate
from
everybody's
thoughts
here?
Yeah,
okay-
and
I
think
I
like
that.
A
Well,
it's
like
they,
they
triggering
behaviors.
You
know
like.
A
Having
gitlab
recognize
that
this
is
a
common
path
and
making
it
really
easy
to
enter
into
the
next
step,
I
think
that's
that's
acceptable.
From
my
point
of
view.
What
I
don't
want
to
do
is
erode
the
adoption
of
releases
by
making
it
really
hard
to
create
your
release.
Once
your
tag's
been
created,
I
wouldn't
want,
say
here's
here's
the
worst
case
scenario
in
my
head
based
off
of
the
user
interviews.
A
A
I
think
that
we
can
comment
on
this
issue
and
say
that
actually
we're
gonna
close
this
out,
because
we
want
the
forms
to
be
the
same
or
that
we
want.
We
want
to
keep
status
quo.
We
don't
want
to
change
the
forms
and
then,
as
far
as
other
features
that
we
need
to
do
to
make
that
experience
easier.
C
C
E
Yeah
I
just
wrote
to
the
agenda.
I
think
we
like
keep
this
form
separate,
but
we
currently
have
release
notes
on
the
tag
page,
so
I
would
remove
them.
E
They
also
create
some
kind
of
technical
depth
and
which
I
would
be
super
happy
to
remove,
and
the
other
note
is
that
on
this
index
stacks
page
or
the
tag
page,
if
release
is
already
there,
we
should
probably
get
some
information
like
show
some
information
about
it.
Like
I
mean,
if
you
go
to
the
tax
tax
page,
you
should
see
that,
like
for
this
three,
you
can
create
releases
associated
with
this
tax
and
for
this
three
releases
already
created-
maybe
some
small
summary
about
it.
D
We
we
do
have
a
button
that
says
like
when
you
have
a
tag
that
is
not
associated
to
a
release.
There
is
a
button
and
if
you
click
there,
you
go
to
the
release
page
with
that
tag
pre-selected,
so
you
can
already
do
that,
but
indeed
we
don't
have
like
any
ways
to
sort
or
show
in
that
list
that
these
are
your
tags,
your
tags,
and
these
are
your
release,
tags.
D
I
think
that's
perhaps
what
would
facilitate.
I
think
you
would
hear
what
you
say.
E
E
Mean
any
sorting,
I
just
meant
that,
like
there
was
basically
two
cases
right
the
button
and
some
small
info.
If
we
already
have
it,
then
basically
what
we
just
discussed
about
like
the
continuous
workflow
is
kind
of
already
done.
We
maybe
just
need
to
highlight
this
button
or
something.
C
D
B
We
already
kind
of
have
that
a
little
bit
if
you,
if
you
have
release
notes
or
if
there's
a
release,
we
show
the
release,
notes
on
the
tag
page
underneath
the
tag,
and
then
we
have
a
little
link
that
says
release
and
you
click
it
and
it.
It
goes
to
the
release
and.
B
B
Oh
wow,
so
it
prints
all
the
release,
notes
underneath
the
tag
and
then
there's
a
link
to
it
right
here,
okay
and
then
the
other
thing,
I
was
going
to
notice
that
if
you
click
there
is
a
edit
button
next
to
a
tag-
and
this
goes
to
this
little
edit
release,
notes
page,
and
so
I
think
we
should
also
remove
this
page
if
we're
removing
it
on
the
other
one.
Just
just
go.
C
A
C
What
what
what
about,
if
we
add
a
you,
know,
there's
kind
of
a
filtering
at
the
top.
We've
got
filter
by
tag
name
and
we've
got
to.
We
can
add
another
entry
to
that
checkbox,
for
example,
just
show
you
know
tags
only.
D
Because
if
this
pretty
much
shows
two
types
of
tags-
and
we
do
that
in
other
places
as
well
right
to
deal
with
the
issues-
milestones,
open,
close
etc,
especially
like
in
projects
like
pajamas
and
in
gitlab,
you
see
that
this
issue,
the
the
release
description,
is
super
long.
This
page
becomes
a
mess
as
well
for
how
you.
B
B
C
I
mean
the
fact
that
we've
got
we've
got
a
number
of
different.
I
think
we've
got
three
different
places
to
basically
do
release
no
strive,
so
if
we
can,
if
we
can,
if
we
can
just
have
the
one
form
you
know,
I
think
that
would
be
a
big.
You
know
a
big
simplifier,
which
is
kind
of
you
know.
It's
always
good
to
software
is
always
better
when
it's
simple.
A
C
A
Managers
or
the
build
managers
that
are
working
across
branches
and
commits
and
declaring
a
release
candidate
like
our
delivery
team
in
the
ui
they're,
not
always
looking
inside
an
api
for
the
latest,
you
know
branch
or
change
to
production,
for
example,
so
we
may
want
to
just
validate
with
release
managers
how
that
page
plays
out.
Otherwise,
if
we
just
make
it
super
intuitive
to
create
a
release
from
the
tag
and
then
they
don't
even
have
to
go
to
the
tag
page,
they
don't
even
have
to
look
at
that
page.
A
C
I
know
this
is
a
bit
outside
the
scope
this
meeting,
but
what
about
also
yeah
like
I
had
the
issue,
creating
a
tag
and
or
release
from
a
commit
or
or
a
branch,
as
you
also
suggested.
A
Yeah
we
validated
that,
with
with
marin
earlier,
just
asked
him
a
question
on
that,
and
he
said
that
would
be
a
really
cool
thing
to
do.
Okay,.
B
C
A
Great,
like
I
feel,
like
I'm
gonna,
I'm
gonna
keep
asking
that
question
to
everybody.
I
talk
to
all
the
all
the
customers.
I
talk
to
just
as
a
solution,
validation,
looking
at
other
release
systems.
They
look
at
shaws
too.
So,
if
you're
looking
at
shaw,
then
it's
a
commit
or
a
branch.
It's
agnostic
to
what
you're.
C
C
A
C
At
some,
it's
not
a
big
saver,
but
it's
just
kind
of
like
it
just
makes
it
nicer
because
you
don't
have
to
like
copy
the
copy.
The
ref-
and
you
know
the
only
thing
is
like
on
the
branches
page,
especially
there's
already
quite
a
lot
of
stuff
there,
but
I'm
in
a
page
like
this,
which
is
not
probably
going
to
be
super
frequently
used.
C
E
A
small
question:
did
I
understood
you
right
that,
like
we're
discussing
adding
like
possibility
to
create
dark
from
like
any
sha
from
I
mean,
as
far
as
I
remember?
Currently,
you
can
create
tech
in
the
gitlab's
interface
out
from
any
git
traff.
C
Yeah,
so
so
what
that
means
there
is
the
workflow.
Is
you
know
you
go
to
the,
for
example
the
commits
page,
and
there
is
a
copy
button.
You
know
you
copy
it,
and
then
you
go
back
to
the
tags
page
and
you
paste
it
into
the
search.
So
you
know
you
can
current
yeah.
Of
course
you
can
do
it
now.
It's
just
switching
between
a
couple
of
different
pages,
yeah.
A
And
really
to
be
like
super
picky
on
this,
it
would
be
creating
a
release
from
a
branch
or
commit.
So
it's
not
necessarily.
A
E
E
Some
simple
search
for,
like
my
last
commit
or
something.
E
List
for
that,
you
can
always
like
just
write
master
there.
I
don't
know
in
the
simplest
case.
C
A
B
B
Right
now,
anytime,
you
go
to
the
new
releases,
page
you're,
creating
a
brand
new
tag.
So
if
we
wanted
to
support
that
workflow
where
you're
on
the
tag
page
and
then
you
create
a
tag
and
then
you
jump
over
to
the
new
release
page,
we
need
to
afford
the
ability
to
have
that
that
existing
tag
selected-
and
I
think
that's
that's
kind
of
a
nice
speaker
to
have
anyway
so
so.
C
B
B
B
B
C
I
was
going
to
say
I
was
I
kind
of
said:
could
you
save
it
again,
but
but
did
you
say
they'll
be
surprised
because
they
can't
see
the
release
notes
anymore
on
the
page.
E
No,
no,
I
mean
if
you
were
creating
release
releases
from
the
releases
page
by
clicking
the
new
release
button
and
you
were
entering
the
whole
information
like
no,
I
I
was
actually
mistaken
a
little
if
you
were
used
to
creating
the
releases
from
existing
tags
and
doing
this
from
the
releases
page.
Then
right
now,
you
won't
be
able
to
do
that.
To
do
so.
C
A
C
Not
to
overcomplicate
the
front
end
part
of
this,
but
would
it
be
nice
to,
for
example,
if
you
type
in
the
tag
name
that
is
created
well,
then
you
know
it
indicates
that
it's
already
existing
or
there's
even
a
drop
down
type
ahead
drop
down
on
on
the
unused
tags.
For
example,
I
don't
know,
I
would
do
it
again.
B
Yeah,
it
would
be
nice
at
the
moment
if
I
ran
into
the
other
day.
There's
there's
a
few
validation
errors
that
we
don't
catch
on
the
front
end.
So
one
is
like
if
you
try
to
create
a
new
release
on
an
existing
tag.
You
just
get
a
generic
error
message,
so
it'd
be
nice
to
like
either
validate
that
kind
of
inline
or
suggest
the
next
one,
or
something
like
that.
Yeah.
B
B
It
doesn't
work
yeah,
it
just
doesn't
work
so
and
there's
a
there's
a
few
other
like
if
your
tag
name
is
badly
formatted.
The
same
thing
happens.
I
think
there's
maybe
like
three
different
validations
that
the
backend
does,
that
we
don't
do
in
the
front
end.
E
Yeah,
that's
this
error
sounds
kind
of
strange
because,
like
the
way,
I
remember
this
api
working
is
just
okay.
We
know
already
this
tag,
so
we
don't
need
to
create
it
and
we
just
will
even
ignore
sh
s,
h
a
if
it's
different.
So
it's
it
sounds
quite
strange.
I
saw
that
api
should
just
do
whatever
you
want.
B
E
E
A
So
I
am
going
to
close
out
that
update
issue
that
nathan
created.
I
already
created
the
issue
for
that
create
a
release
from
an
existing
tag.
That'll
be
the
first
step
that
we
go
here.
A
I
think
we
can
do
that
step
with
first
and
then
the
second
and
third
steps
will
be
releasing
release,
notes,
removals
from
tags
and
then
hopefully
I'll
have
some
validation
on
workflows
that
are
around
commits
and
branches
and
how
people
want
to
experience
that
association
and
we
can
update
the
new
release
form
to
select
from
all
those
various
sources
and
then
eventually
we'll
need
to
get
to
the
draft
releases
concept
and
allow
people
to
create
a
new
release
without
a
tag
so
that
they
can
then
later
associate
an
existing
tag
once
they
create
it.
A
C
A
Now
we're
like
plus
four
versus
plus
five
awesome.
Well,
I
know
that
we're
at
time.
Thank
you
all
so
much.
This
was
super
valuable
for
me.
I
I
don't
think
we
would
have
been
able
to
do
this
asynchronously.
So
thank
you
for
meeting
face-to-face
on
this
all
right.