Going back to my previous point.
Whatever makes the preparation of Release Notes easier should drive the
policy.
It sounds like Will is favouring a complete abandonment of the JIRA.
Does this change the end-user's process for reporting bugs or requesting
new features?
Ron
On 30/06/2017 9:09 AM, Will Stevens wrote:
Back to jira. I personally have never searched jira for an issue. I search
github prs for issues often though to see what code is actually pending for
different issues. I dont think i am alone in that.
My stance is that unless we have a solid reason for using jira which we can
not solve with github at this point, we should reconsider our use of jira.
Now that we have gitbox setup, i think we have the ability to use Issues as
well as PRs. I think it is much wiser to keep the discussion around the
code much closer to the code and not in a 3rd system. By using jira we
encourage people who are contributing to the discussion to never look at
the code because it is not available in the same screen. I think it is much
more useful to discuss changes with the context of the code at your finger
tips. Comment on specific lines of code, review the conformance to the
style guide, etc...
Also, I think the argument that jira somehow helps with release notes is
being made by people who have never created the release notes. When using
jira, you are assuming that everyone has jira in their workflow and the
status of a ticket is always right. This is almost never the case and there
is a huge amount of man effort to try to manage that delta. My colleague,
Pierre-Luc Dion, has historically created the majority of release notes up
until 4.9, when I scripted based on the PRs actually merged (as I was the
4.9 RM). My script tried to associate jira tickets if it could find them,
but not every piece of code merged had a ticket (which will always be the
case). There will always be a PR for a change, there wont always be a jira
ticket. That alone should mean that we should be doing release notes based
on the PRs and not the jira tickets. Also, Pierre-Luc does not have the
time to spend a week building the release notes anymore for every release,
he is a busy man...
Anyway, these are my two cents. As always I am open to other opinions and
points of view. I would encourage us to try to understand and pinpoint what
we think adding jira to the flow actually achieves. Now that we have the
gitbox integration I feel like we should move the vast majority of the
development and issue related workflows closer to the code.
Sorry for the wall of text...
On Jun 30, 2017 6:52 AM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
Hello,
I've created a DISCUSS thread to... discuss this subject separately from
the original Jira issue.
Sorry Paul for hijacking your Jira rant.
Alexander Hitchins
------------------------
E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587
-----Original Message-----
From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com]
Sent: 29 June 2017 20:41
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ
That is what I am saying. Apache can (and does) handle donations, and there
have been discussions about donations that can be directed to projects at
the donation time (someone that knows about the topic could provide some
help here?).
So, the foundation part looks covered for me....I think we need something
else.
On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey <ma...@gonsource.com> wrote:
Rafael,
I agree. I am not saying move away from Apache.. I am saying setup a
"foundation" to handle donations and even development management..
Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC
-----Original Message-----
From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com]
Sent: Thursday, June 29, 2017 3:28 PM
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ
ACS is an Apache project, not a foundation per se; donation goes to
Apache.
I know that there is some discussion/work to create a way for donating
things (not just money) to projects, but I do not know how that is going.
I do not think we need to create other foundation and move away from
Apache (because that is what this move would look like....)
But still, I wonder, even if we had a CloudStack foundation, would
that make organizations that rely on it to donate/contribute more
actively? Is that the real problem?
On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey <ma...@gonsource.com> wrote:
Alex,
I agree.. The only "good" way that we will get more adoption is to
treat it like an Enterprise product. But that would require investment.
Investment with money, not just time.
As an example, I use pfSense alot in my projects. If I put in a
pfSense router, I take 2-5% (depends on scope) of the GDM and donate
to the pfSense project. I do this because pfSense makes me a lot of
money and I want it to get better.. The only way it will get better
is by supporting it. And even if I was a coder, "supporting" it with
code
only goes so far.
And as mentioned, we create a CloudStack Foundation that is a 501C
corp so it's a non-profit and tax deductible for people donating.
So the next question is who would we speak with to get this ball
rolling or even a discussion started?
Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC
-----Original Message-----
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: Thursday, June 29, 2017 1:49 PM
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ
If it isn't being treated as a product it will be very impossible to
market it as enterprise ready.
I know we all know this.
Similar sized projects under the Apache banner must have the same
issue, what is the best way to gather experience of these projects?
See how they handle these growing pains.
A cloudstack foundation entity funded by companies earning from
cloudstack seems a good way forward.
Another tuppence, this is getting expensive.
On 29 Jun 2017, at 18:18, Ron Wheeler
<rwhee...@artifact-software.com>
wrote:
I understand that it is a volunteer organization.
I do not know how many (if any) of the committers and PMC members
are
funded by their organizations (allowed or ordered to work on
Cloudstack during company time) which is often the way that Apache
projects get staffed.
Clearly it is hard to tell someone who is being funded by a
company to
fix a problem or who is working on their own time, to do or not do
something.
On the other hand, the PMC has to build a community culture that
is
good for the project.
That means describing a vision, planning and enforcing a roadmap,
and
maintaining a focused project "marketing" effort.
There is a lot of extremely talented individuals working on
Cloudstack
and it appears to have a very strong and valuable code-base.
To me the key question is about the PMC and the core committers'
ability
to make Cloudstack a "product" that can compete for market share and
acceptance.
Is Cloudstack at a point in its development where it should be
treated
like a product?
- sufficient functionality to compete
- sufficient user base to be a competitor in the market
- production reliability and stability
- business model for supporting companies to justify their
continued support
This may not require more effort but requires different policies
and
different activities.
There has to be someone or a PMC that can say "No".
- This change can not be included in this release because it will
delay
the release.
- This change adds an unacceptable level of complexity
- This bug fix will have to wait for the next release because it
is too
late to test it and fix the docs.
- This fix breaks the docs
- The release can not be made until this doc is updated.
Does the core group want to make it a competitive product or is it
sufficient for the interested players to continue in its current form?
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
--
Rafael Weingärtner
--
Rafael Weingärtner
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
