Ron, for this I think we would be using Github Issues if we were not
using Jira. Essentially all of the project information would be found
in the same place rather than the user having to discover all the
different systems that we use to track things and then try to make
sense of it.
*Will Stevens*
Chief Technology Officer
c514.826.0190
<https://goo.gl/NYZ8KK>
On Wed, Mar 14, 2018 at 10:04 AM, Ron Wheeler
<rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>> wrote:
I am not a Cloudstack developer and generally have no interest in PRs.
If I have a problem, I want to search the Jira
- What was the symptom - is it related to the problem that I am
having - may not be exactly the same but might be related
- How was it reproduced - is this related to what I am trying to
do - can I change my configuration decisions to avoid the issue
- What remedies were considered - could any of these have side
effects that could account for my issue
- Why was the specific fix chosen - is my problem an edge case
that was created or ignored by this decision
- Is there any discussion that could help me decide if my problem
is related.
- Is there any info in the discussion that educates me to a point
where I know what tests to run to refine my understanding my issue.
- What are the side-effects of the fix.
- Was it back ported
- What issues were discovered during backporting
I am not sure that a PR will be much use to a sysadmin if the
issue is non-trivial.
If we ask people creating PRs to add all the things that a
sysadmin requires, PRs may get too difficult to make.
OTOH, I agree with Paul that PRs without Jira issues for doc
updates and corrections that do *not affect functionality* would
not make life too difficult and might encourage people to fix doc
problems, clean code and update libraries.
Ron
On 14/03/2018 7:25 AM, Paul Angus wrote:
Oh boy! Where to start....
Ok, so wrt Rohit's original point, I'm a +1 for doc updates
and very trivial stuff a GOOD & COMPLETE title and summary in
a PR probably suffices.
Wrt Jira, for keeping track of *un*implemented changes and
*un*fixed bugs - I think that it (or something similar) is a
must. Which shouldn't leave much to be honest. As some point
a person has decided to make a code change or has found a bug,
right then the 'thing', by definition, falls into one of the
above categories.
Kind regards,
Paul Angus
paul.an...@shapeblue.com <mailto:paul.an...@shapeblue.com>
www.shapeblue.com <http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-----Original Message-----
From: Daan Hoogland <daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>>
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Let me add to the below that I do think a ticketing system is
a big help for keeping track of *un*implemented changes and
*un*fixed bugs.
On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland
<daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>>
wrote:
Boris, I hate to be strongly opinionated but I have to
violently
disagree with you on some things here;
On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com
<mailto:boris.stoya...@shapeblue.com>> wrote:
Hi all,
I do understand your point as developers if you want
to fix something
just open the PR and not deal with any extra details
like JIRA
tickets and etc, but I must say that JIRA tickets are
quite often
looked up from users as they experience an issue.
It is not more or less effort for users to look up github
PRs than
Jira tickets. They still need to be clever about search
terms and
still might miss out.
Let’s say we’ve fixed an annoying UI bug in master and
there’s no
ticket for it in JIRA. As a user, if you try to search
for this
particular issue where would you go? In JIRA or
GitHub? How would you
know which release to pickup if you’re just an
infrastructure guy and not following Github.
What is following here and why not Github but Jira.
Tracking every change with such tool is proven good
practice in SDLC,
No it is not. Absolutely not. That is what we have
revision control
systems for. Your good practice is only true for
enterprise controlled
projects. In cloudstack there are a lot of wild forks
because this
enterprisy way of controlling change has pushed people
away from
mainstream. This is a force to be reckoned with and we can
not completely
ban it, but we have to minimise it if we want to survive
as project.
it brings visibility and it’s a tool meant to be used
not only from
developers, but from everyone involved in the project.
How is this true for Jira anywhere near as much as it is
true for github?
I also got the feeling that lacking a JIRA ticket
could become a common
practice in community submission and it’s yet another
reason for me to be
-1 on this.
Another reason to be very much +1 on it. That is a good
thing. Think
about it. People submistting features and bugfixes instead
of asking for
them in a ticket. That is great.
Also I don’t think it’s causing big overhead, since
it’s being updated
mostly automatically.
No it is not. What is done automatically? put in
progress?? closing?
undertest status? Only noise is added to those tickets
automatically.
Boris Stoyanov
boris.stoya...@shapeblue.com
<mailto:boris.stoya...@shapeblue.com>
www.shapeblue.com <http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
On 13 Mar 2018, at 17:01, Khosrow Moossavi
<kmooss...@cloudops.com
<mailto:kmooss...@cloudops.com>>
wrote:
I'm completely +1 on using GH as source of truth,
both PR and issue
wise,
with Daan comment regarding Apache rules in mind.
At least it doesn't need to have "yet another"
integration to do
automated
actions on an issue (such as auto close an issue
by "Fixes NUMBER",
"Closes NUMBER") directly from commit or PR body.
Khosrow Moossavi
CloudOps
On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed
<sah...@cloudops.com <mailto:sah...@cloudops.com>>
wrote:
I agree with the relaxation as Rohit pointed
out. At this point we
should
ask if Jira is really needed. Most people here
I believe agree that it
is
not. The only reason we have Jira is to track
releases. This could
easily
be replicated in GitHub as I see that GitHub
is the place where we all
collaborate. I would be completely in if we
use GitHub issues and like
it
with Jira as we do with our PRs.
On Tue, Mar 13, 2018 at 10:03 AM Rafael
Weingärtner <
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>> wrote:
I was checking and for some reason ACS
does not have an issue tab (
https://github.com/apache/cloudstack/issues
<https://github.com/apache/cloudstack/issues>).
It might be some
configuration in the repository.
On Tue, Mar 13, 2018 at 10:54 AM, Rafael
Weingärtner <
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>> wrote:
What do you mean by issue? PR or issue
(Github issue)?
On Tue, Mar 13, 2018 at 10:53 AM, Daan
Hoogland <
daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>
wrote:
right, also when an issue is created?
On Tue, Mar 13, 2018 at 2:50 PM,
Rafael Weingärtner <
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>>
wrote:
We already have. All messages
on ACS' GH go to commits@c.a.o
On Tue, Mar 13, 2018 at 10:49
AM, Daan Hoogland <
daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>>
wrote:
Ok, one issue there is
Apache foundation rules.
If we copy every
thing
into
jira or the mail list we
are fine, where ever we
have our
discussions.
The
only thing is that we need
a Apache hosted record.
(as in not
github)
On Tue, Mar 13, 2018 at
2:09 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>>
wrote:
I prefer the workflow
in Github as you guy,
but to be fair with
Jira
ticket
system I mentioned it.
@Marc, yes Jira can
facilitate a lot the
management. However, we
do
not
use
it fully. In our
workflow, there is no
planning/roadmap for the
next
release per se. Things
seem to work in an
ad-hoc fashion. On the
other
hand, when you need to
break down milestones into
issues/tickets/tasks
and
then divide them into
sprints, and manage a
team of developers,
the
oversight provided by
Jira system is very
good; specially, when
issues
start to take more
than a single sprint
to finish.
On Tue, Mar 13, 2018
at 9:44 AM,
Marc-Aurèle Brothier <
ma...@exoscale.ch
<mailto:ma...@exoscale.ch>
wrote:
@rafael, you said:
they all required
Jira tickets to
track the
discussion
and facilitate the
management
I can see the
discussion
happening in the
PR on github, but
the
Jira
ticket
by itself doesn't
do much, except
copy/pasting the
github
discussion.
Then
it's down to
"facilitate the
management", which
I only see as
listing
the
changes for a
release as far as
I know. But this
can be
achieved
on
github
too.
As Daan mentioned,
there are those
things that are
not code
related
which
should have a way
of tracking. But
what's the
difference in
tracking
them
as a Jira issue vs
a Github issue
(they can't be a
PR)? Those
are
point
of
view exchanges
with messages &
links, with a
final status,
most
of
the
time
without a strong
link to a release
number. If they
do, they
can
be
added
to
a milestone.
So far I don't see
how things done
with Jira cannot be
achieved
on
Github.
It's just a matter
of changing habits
to simplify the
workflow
for
new
comers (and old
joiners too ;-) ).
On Tue, Mar 13,
2018 at 1:02 PM,
Daan Hoogland <
daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>>
wrote:
Will, you are
speaking my
mind; any
external
registration
tool
should
be
based on the
source. The
only reason
for having an
external
tool
without
relation to
the code is to
keep track of
what is *not* (or
not
fully)
implemented.
On Tue, Mar
13, 2018 at
12:58 PM,
Rafael
Weingärtner <
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>>
wrote:
I meant a
way of
describing
them
(changes/proposals)
further.
Sometimes
we
have
commits
only with
title, and
then the
Jira ticket
would
be a
way
of
documenting
that
commit. I
do prefer
the idea
of inserting
the
whole
description
in the
commit
body
though.
[for me]
it looks
easier
to
work
directly
with
commits
and PRs;
as you
said, we can
generate
release
notes
based on
commits
directly
[and
issues on
GH].
However, for
that,
we
need
to
fine-tune
our workflow.
On Tue,
Mar 13,
2018 at
8:40 AM,
Will Stevens <
wstev...@cloudops.com
<mailto:wstev...@cloudops.com>
wrote:
I am
+1 to
relaxing
the
requirement
of
Jira
ticket.
Rafael,
what
do you
mean
when
you
say
"Jira
tickets
are
used to
register
changes"?
I
think
ever
since
4.9
the
actual
PRs
included
in the
code
are
the
source
of
truth
for
the
changes
in the
actual
code
(at least
from a
release
notes
perspective).
This
is why
the
release
notes
can show
changes
that
only
have
PRs
and no
Jira
ticket.
At
least
my
release
notes
generator
is
built
that
way.
I
think
Rohit
has
built
a
similar
release
notes
generator,
so
I
can't
speak
to his
version...
*Will
Stevens*
Chief
Technology
Officer
c
514.826.0190
<tel:514.826.0190>
<https://goo.gl/NYZ8KK>
On
Tue,
Mar
13,
2018
at
6:42
AM,
Rafael
Weingärtner
<
rafaelweingart...@gmail.com
<mailto:rafaelweingart...@gmail.com>>
wrote:
Marc,
yes
Jira
tickets
are
used
to
register
changes.
However,
what
Rohit
and
others
(including
me)
are
noticing
is
that
there
are
certain
types
of
changes
(minor/bureaucracy)
that
do
not
require
Jira
tickets.
The
issue
is
the
wording
“change”.
What
consist
of
a
change
that
is
worth
mentioning
in
the
release
notes?
Everything
we
do
in
a
branch
is a
change
towards a
release,
but
not
everything
is
useful
for
operators/administrators
to
see.
I
would
say
that
to
fix
bugs,
introduce
new
features,
extend
existing
features,
introduce
a
major
change
in
the
code
such
as
that
standard
maven
thing
that
you
did,
they
all
required
Jira
tickets
to
track
the
discussion
and
facilitate
the
management.
On
the
other
side
of
the
spectrum,
we
have
things
such
as
removing
dead/unused
code,
opening
a
new
version
(creating
the
upgrade
path
that
we
still
use
for
the
DB),
fix a
description
in
an
API
method,
and
so
on.
Moreover,
the
excessive
use
of
Jira
tickets
leads
to
hundreds
of
Jira
tickets
that
we
do
not
know
that
status
of.
We
have
quite
a
big
number
of
tickets
opened
that
could
be
closed.
This
has
been
worse;
we
are
improving
as
time
goes
by.
I
would
say
that
to
make
this
more
transparent
to
others
(especially
newcomers),
we
need
to
discuss
it,
then
write
it
down
to
make
it
transparent
the
way
we
are
working.
On
Tue,
Mar
13,
2018
at
6:59
AM,
Marc-Aurèle
Brothier
<
ma...@exoscale.ch
<mailto:ma...@exoscale.ch>
wrote:
That's
a
good
idea,
because
people
are
more
and
more
used
to
only
create
PR
on
github,
and
it
would
be
helpful
to
be
more
explanatory
on
the
way
we
work
to
push
changes.
I
still
think
we
should
encourage
the
use
of
the
github
milestone
as
Rohit
did
with
the
4.11.0
(
https://github.com/apache/clou
dstack/milestone/3?closed=1)
to
list
the
changes
in
the
release
notes
with
the
help
of
the
labels to
tag
the
PRs
instead
of
relying
on
the
jira
ticket
(it
requires
to
have
another
login).
As
far
as
I
can
remember,
the
JIRA
tickets
are
used
to
list
the
changes
of
a
release,
but
nothing
else.
Or
am
I
missing
something?
Marc-Aurèle
On
Tue,
Mar
13,
2018
at
9:57
AM,
Rohit
Yadav
<
rohit.ya...@shapeblue.com
<mailto:rohit.ya...@shapeblue.com>>
wrote:
All,
To
make
it
easier
for
people
to
contribute
changes
and
encourage
PR/contributions,
should
we
relax
the
requirement
of a
JIRA
ticket
for
pull
requests
that
solve
trivial/minor
issues
such
as
doc
bugs,
build
fixes
etc?
A
JIRA
ticket
may
still
be
necessary
for
new
features
and
non-trivial
bugfixes
or
changes.
Another
alternative
could
be
to
introduce
a
CONTRIBUTING.md
[1]
that
explains
the
list
of
expected
things
to
contributors
when
they
send a
PR
(for
example,
a
jira
id,
links
to
fs
or
other
resources,
a
short
summary
and
long
description,
test
results
etc).
Thoughts?
[1]
https://help.github.com/articl
es/setting-guidelines-
for-repository-contributors/
-
Rohit
<https://cloudstack.apache.org>
rohit.ya...@shapeblue.com
<mailto:rohit.ya...@shapeblue.com>
www.shapeblue.com
<http://www.shapeblue.com>
53
Chandos
Place,
Covent
Garden,
London
WC2N
4HSUK
@shapeblue
--
Rafael
Weingärtner
--
Rafael
Weingärtner
--
Daan
--
Rafael Weingärtner
--
Daan
--
Rafael Weingärtner
--
Daan
--
Rafael Weingärtner
--
Rafael Weingärtner
--
Daan
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
<mailto:rwhee...@artifact-software.com>
skype: ronaldmwheeler
phone: 866-970-2435, ext 102 <tel:866-970-2435%2C%20ext%20102>
