For small fixes that do not affect functionality the value of a JIRA may
be questioned.
The main advantages that I see:
- if 2 people find the same bug and both fix it without raising a JIRA,
you may end up with 2 different patches
- if an end-user finds the bug and searches the JIRA to see if it is
known and scheduled to be fixed, they will find the current status if
there is a JIRA issue
- end-users may also be willing to fund a fix or commit resources to
testing it, if the know that it is being worked on.
- often people get attached to their work and if they have invested a
lot of time in solving the problem without a discussion in the JIRA,
they will be really upset when the PMC or committers say "no" or "not a
good solution"
- Googling for a problem will find the JIRA before the release notes are
ready and the JIRA may have more description of the problem or enhancements.
In any case, there needs to be a policy that the Release Management team
can depend on.
Perhaps "if it is big enough or sufficiently significant to be included
in the Release Notes then it should be in the JIRA." might work.
This would allow small fixes and code cleanup to be done quickly with
minimum overhead.
The policy also should favour the RM team in terms of where the effort
is allocated.
There is more coding time available than RM time.
Anything that slows the release or adds to the work of the RM, must be
avoided even if it shifts work to the coders.
Ron
On 29/06/2017 9:42 AM, Will Stevens wrote:
I personally don't know how Jira solves any of this, but assuming it does,
fine...
The bigger problem which you have raised is that CloudStack has zero
funding. So we can't hire a project manager, or a release manager or
someone whose job it is to maintain documentation. I have been trying to
find a way to, at the very least, fund a full time release manager who can
focus 100% on the project. As the release manager for 4.9, I know it is a
full time job. I did my best, but it is a ton of work and is hard to stay
on top of.
Everyone contributing to CloudStack is donating their time. They can't make
a living off supporting ACS, so every one is doing their best with the
little time they can take away from their day job or their family life.
Yes, having clear guidelines and sticking to them helps, but without a
solid CI infrastructure backing the project and improved testing and
automation, we will always struggles with release schedules and such.
I have been involved in this project long enough to know that all the
problems you point out exist, but they are also not easily solved.
Obviously we have to work with the initiatives we have and take small steps
towards improvement, but we also have to be realistic with our expectations
because we are counting on people's generosity to move them forward.
Simplifying moving parts and streamlining the process will lead to more
contribution because there is less barriers to entry. This one reason why I
struggle to see the value in Jira as it is used today. I personally don't
understand what value it is giving us that the github PRs and Issues don't
solve.
I will remain open minded and will follow along with what people think is
best, but I think it is worth understanding what we are trying to solve for
and simplify our approach in solving it so we can get better systems in
place.
On Jun 29, 2017 9:17 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:
As a real outsider, IMHO Paul is right.
At times it seems that Cloudstack is a coding hobby rather than a project
or a production quality product.
Who decides what goes into a release? How does this affect the release
schedule?
Who is responsible for meeting the "published" roadmap (of which there
seem to be many) of releases?
How is a system admin that is not part of the project supposed to plan for
upgrade windows?
How does one know when a feature, bug fix or release will be available?
How does the PMC manage function creep in a release, maintain quality
and consistency, reject changes that hurt the overall vision or add too
much complexity?
No one seems to care about documentation but if someone did, how would
they stop undocumented features or features that contradict the
documentation from being incorporated?
Who makes sure that the documentation is correct at the time of the
release?
Release notes are not much help for someone doing a new install or
evaluating Cloudstack.
Without a JIRA entry, how does an end-user who encounters a problem know
that it has been fixed already in the next release?
Without a JIRA entry, how does the community comment on a proposed change
before it gets coded?
If changes are going to be accepted without a JIRA, is there a definition
of a minor fix that does not require a JIRA?
- does not change functionality?
- only affects an "edge case" or cleans up an exception that is not
properly handled?
- only improves code readability or future extensibility?
- does not affect documentation?
Apache projects that are popular and enjoy wide support do have strong
management.
There are other examples where great Apache software is failing to get
recognized because the PMC is not paying attention to the product
management side of things.
I use Apache Jackrabbit which is a quality product with a strong technical
team supporting it.
It has very little following because the documentation and marketing
collateral is very poor.
It gets by because the audience for it is largely software developers who
can read code and can test features to work out the functionality.
It would get a lot more attention if they paid attention to the product
management side of the project.
Cloudstack needs to avoid this situation and unfortunately this takes
effort and some discipline.
Ron
On 29/06/2017 8:03 AM, Will Stevens wrote:
Why are we still using jira instead of the PRs for that communication? Can
we not use issues in github now instead of jira if someone needs to open
an
issue but does not yet have code to contribute. If not, jira could still
be
used for that.
I think duplicating data between jira and the PR is kind of pointless. I
feel like the github PRs and the cide going in should be the source of
truth, not a random third party tool.
For the 4.9 release notes, i built a tool to generate the release notes
from the PRs merged in that release. I think that is easier and more
accurate than depending on jira since it does not track the actual code
tree.
Thats my 0.02$.
On Jun 29, 2017 5:25 AM, "Paul Angus" <paul.an...@shapeblue.com> wrote:
Such a view of CloudStack is what holds CloudStack back.
It stops users/operators from having any chance of understanding what
CloudStack does and how it does it.
Code for code's sake is no use to anyone.
Jira is about communication between developers and to everyone else.
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 [mailto:daan.hoogl...@gmail.com]
Sent: 29 June 2017 10:14
To: dev <dev@cloudstack.apache.org>
Subject: Re: JIRA - PLEASE READ
On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:
+ Release notes will be impossible to create without a proper Jira
history.
And no one will know what has gone into CloudStack.
No they are not mr Grumpy. they should be base on the code anyway, hence
on
git, not jira. I do not appose to the use of Jira but it is not required
for good coding practices and as we are not and will not function as a
corporation, jira is an extra for those that grave for it. not a
requirement.
--
Daan
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
