Perhaps a Release Tsar would be a better solution.
The RM needs to have absolute control over what is in or out.
Reasonable discussion allowed and then a decision once the RM feels that
the case has been fully explored and that a positive vote is expected.
The importance on meeting deadlines needs to have a higher priority. If
a feature/fix can not meet the quality/testing threshold on time then it
gets dropped from the RC and scheduled for the next release.
A few cycles of a bit of ruthlessness should get everyone`s intention
and shorten the release cycle.
Meeting release schedules would also reduce the pain of a feature being
deferred.
According to the schedule proposed last
year,(https://cwiki.apache.org/confluence/display/CLOUDSTACK/%5BPROPOSAL%5D+2016-2017+Release+Cycle+and+Calendar)
Cloudstack 4.9.10 (LTS) , 5.04.0 (LTS) as well as 5.1.3.0
(maintenance) 5.2.1.0 (Maintenance) were released June 2017.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
seems to be pretty reasonable. The RM probably needs to moderate the
vote and explain what -1 votes mean to product credibility if they delay
the release. Negative votes because someone`s new feature did not make
it should be ignored.
Ron
On 30/06/2017 12:09 PM, Paul Angus wrote:
We could probably split this topic down also....
I think I may have mentioned previously 😊 my view on how we have somewhat shot
ourselves in the foot with the release process this time around. I think that
for the most part, people have been well intentioned, and have been trying to
'make this release as good as possible' which is counter-productive, as it's
been introducing new blockers.
I'm not sure we have a problem in our 'loosely-agreed' process, it's just that
repeatedly people have ignored it.
WRT a full-time release manager, I suspect that they would find that "you can lead a
horse to water, but you can't make it drink". They would not be able to compel
anyone to 'hurry up and fix that bug you created', although I guess maybe they could pull
a feature if the author(s) didn't sort it out.
Because ultimately a release manager, paid or otherwise should only be doing
what the 'community' decides the release manager's role is. So we need to be
clear about how we want releases to work before worrying about who manages that.
Kind regards,
Paul Angus
paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-----Original Message-----
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 30 June 2017 15:05
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof
I am in complete agreement with you. Also on your other reply regards to a FT
release manager.
If 'we' don't go down this line, more and more people will follow the
Cosmic/Schuberg Philis path or even use Cosmic instead.
I'm encouraged by your response. Sounds like a few others hold the same
concerns.
Alexander Hitchins
------------------------
E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587
-----Original Message-----
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: 30 June 2017 14:54
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof
Yes, Schuberg Philis, a very active community member forked Cosmic off of
CloudStack and has been developing their fork for their needs.
I do think we need to have a more consistent front on this matter. I think it
would make a big difference on the quality, release cadence and perception of
the project.
On Jun 30, 2017 9:48 AM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
Thanks Will,
I understand it's something that comes with a big bag of troublesome worries.
If this topic comes up again in any discussions, I'd be interested to hear
their thoughts on what I see as the alternative; without a dedicated
RM/PM/Captain, people will fork off CS so they can achieve the same thing, and
CS ultimately looses out long term. I can't remember the name of the fork, but
I think I'm right that a previous large CS contributor/user forked off as they
wanted greater management in the areas we are discussing here.
Alexander Hitchins
------------------------
E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587
-----Original Message-----
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: 30 June 2017 14:31
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof
Apache has been historically against the idea of a cloudstack foundation and
there is a bit of a pandoras box there which we will want to be careful about
opening.
Apache added direct contribution, but it was unusable for us historically
because it required a minimum contribution of 50k, which none of us can afford.
However, there have been some changes to the board recently which are in our
favour if we want to put pressure to lower that to say 5-10k.
Even if we do solve for smaller direct contributions, we will have to jump
through hoops to be able to use those funds for a dedicated release manager. I
do think this is a possibility if we manage our needs and communications very
well. I had some preliminary discussions with some apache foundation folks to
express these specific concerns. I played off the fact that i know they dont
want to entertain a cloudstack foundation and tried to see if i could get them
to move on the direct contribution mechanism to make it usable for us,
specifically with the goal of hiring a full time release manager. I definitely
had their ear and they acknowledged the problems we are facing (and currently
discussing). They expressed concerns about being able to hire someone with the
direct contributions, but brainstormed a bit to potentially hire an agency who
actually does the hire and they pay the persons salary through the agency with
the direct contribution funds.
All to say, there are potential options here, but there be dragons, so we have
to handle this topic with care.
On Jun 30, 2017 9:12 AM, "Ron Wheeler" <rwhee...@artifact-software.com>
wrote:
https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly
support, pleasecontact us <https://www.apache.org/founda
tion/contributing.html#Fundraising>and we will do our best to satisfy
your wishes."
1) Is Apache willing to allow projects to set up their own
foundations? I doubt but someone would need to check this out.
Does the PMC have the project charter or the agreement that was signed
when Cloudstack moved.
2) Has anyone tried to contact Apache about directing support to
Cloudstack.
I am not convinced that lack of paid staff is the issue.
This discussion reminded me of this.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change
http://www.lightbulbjokes.com/directory/p.html
Ron
On 30/06/2017 6:48 AM, Alex Hitchins wrote:
As per Giles's comment to the previous thread, I thought I would
start a discussion on the subject to canvas peoples thoughts,
opinions
and fears.
My question for discussion, is there is any mileage in someone
creating a "CloudStack Foundation" as a non-profit entity, funded
largely by key CloudStack players with the sole function of employing
dedicated resource (part or full time) to handle all releases and
other essential 'back office' functions. The idea being it's in
everyone's interest to chip in a little each to fund core project and
release management.
The idea might be utterly irrelevant, pointless and/or straight up daft.
I urge you all to let me know.
Something for you all to think over this weekend.
Alexander Hitchins
------------------------
E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587
-----Original Message-----
From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
Sent: 30 June 2017 09:51
To: dev@cloudstack.apache.org
Subject: RE: JIRA - PLEASE READ
All
This thread seems to have turned into 2 quite different discussions:
1. The use (or not) of Jira - which was the original discussion
2. Ways/means of encouraging (and paying for more structured
contributors)
I know that it could be argued that these are related. Could I
suggest opening up a thread on "release and project management and
funding it" and keeping this thread to the original discussion
(I will weigh in on both of these at some stage)
Kind regards
Giles
giles.sir...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
-----Original Message-----
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 29 June 2017 18:49
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
