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
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-----Original Message-----
From: Daan Hoogland <daan.hoogl...@gmail.com>
Sent: 14 March 2018 10:05
To: dev <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>
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> 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
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
On 13 Mar 2018, at 17:01, Khosrow Moossavi <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>
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> wrote:
I was checking and for some reason ACS does not have an issue tab (
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> 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
wrote:
right, also when an issue is created?
On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
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>
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> 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
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>
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> 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
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
<https://goo.gl/NYZ8KK>
On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
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
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>
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
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
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
