RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Paul Angus]

Taken from a talk on CloudStack testing [1]...

There are Many, many, MANY permutations of a CloudStack deployment…. 
• Basic / Advanced 
• Local / shared / mixed storage 
• More than 8 common hypervisor types/versions 
• 4 or 5 Management server OS possibilities 
• That’s 144 combinations only looking the basics.

[1] 
https://www.slideshare.net/ShapeBlue/cloudstack-eu-user-group-trillian?qid=74ff2be0-664c-4bca-a3dc-f30d880ca088==_search=1

Trillian [2], can create any of those, and multiple at the same time, but the 
amount of hardware required to do that means that we have to pick our battles. 
Running the blueorangutan bot command '@blueorangutan matrix' in a PR will run 
the smoke test suite against a PR using 3 environments, one each of KVM, 
XenServer and vSphere and takes around 8 hours.

But that is only looking for major regressions.  A full component test run 
takes around 5 days to run and is riddled with bugs in the tests. 

Ultimately these are still of limited scope, few people are as diligent as say 
Mike T in creating practical marvin tests for their code / features.

[2] https://github.com/shapeblue/Trillian

Therefore we need hardware to run tests on, but more importantly we need the 
tests to exist and work in the first place.  Then we can really do something.



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 21:34
To: dev@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: RE: [DISCUSS] - Releases, Project Management & Funding Thereof

Consultation with users is something that should definite be done. Canvas as 
many as possible.

I agree that most people will be running test environments before full rollout 
of any technology, I guess see it a little from a CTO eyes - why shortlist a 
technology that doesn't even endorse its own releases?

Hopefully we will get some more replies to this thread from other CloudStack 
enthusiasts to help shape this conversation.

I'm setting up a new development environment now to get my hands mildly soiled. 
Going the Windows route again. Fancy a challenge for the weekend.




Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Sent: 30 June 2017 21:08
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof


On 30/06/2017 3:28 PM, Alex Hitchins wrote:
> We can't validate all scenarios no, hence suggesting several common setups as 
> a reasonable baseline. I like the idea of users posting their hardware and 
> versions as a community endeavour.
>
> I strongly feel there should be an established, physical setup that the 
> release team have access to in order to validate a release.

This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major site 
would have a test setup and might be very happy to have the dev team test on 
their setup.
This would save them a lot of resources at the expense of a bit of time on 
their test environment.

> If this was some random cat meme generator on GitHub, I'd accept the risk in 
> running an untested version. For something I'd be running my business on 
> however I'd expect there being some weight behind the release.
>
> Perhaps I have unrealistic expectations!

Not at all.
Your expectations might be the key to making a pitch to the user community for 
some help from people and organizations that are not interested in writing code 
but have a major interest in testing.
In addition to access to test equipment, this might actually get new people on 
the team with the right skills required to extend the test scripts and test 
procedure documentation.

Does anyone have a list of the configuration specifications that are required 
to test a new release?

Would it help to approach major users of Cloudstack with a direct request for 
use of their test equipment and QA staff in return for early access to new 
releases and testing on their hardware?

Ron

>
> Alexander Hitchins
> 
> E: a...@alexhitchins.com
> W: alexhitchins.com
> M: 07788 423 969
> T: 01892 523 587
>
> -Original Message-
> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> Sent: 30 June 2017 20:13
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] - Releases, Project Management & Funding 
> Thereof
>
> On 30/06/2017 2:19 PM, Alex Hitchins wrote:
>> Releasing against a defined reference rig would be a very good idea, 
>> especially if we could replicate several.
>>
>> It concerns me slightly that we are building a platform we want to promote 
>> people to deploy in enterprise environments with the caveat 'run at your own 
>> risk'.
> There is no choice as near 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

Consultation with users is something that should definite be done. Canvas as 
many as possible.

I agree that most people will be running test environments before full rollout 
of any technology, I guess see it a little from a CTO eyes - why shortlist a 
technology that doesn't even endorse its own releases?

Hopefully we will get some more replies to this thread from other CloudStack 
enthusiasts to help shape this conversation.

I'm setting up a new development environment now to get my hands mildly soiled. 
Going the Windows route again. Fancy a challenge for the weekend.




Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Sent: 30 June 2017 21:08
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof


On 30/06/2017 3:28 PM, Alex Hitchins wrote:
> We can't validate all scenarios no, hence suggesting several common setups as 
> a reasonable baseline. I like the idea of users posting their hardware and 
> versions as a community endeavour.
>
> I strongly feel there should be an established, physical setup that the 
> release team have access to in order to validate a release.

This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major site 
would have a test setup and might be very happy to have the dev team test on 
their setup.
This would save them a lot of resources at the expense of a bit of time on 
their test environment.

> If this was some random cat meme generator on GitHub, I'd accept the risk in 
> running an untested version. For something I'd be running my business on 
> however I'd expect there being some weight behind the release.
>
> Perhaps I have unrealistic expectations!

Not at all.
Your expectations might be the key to making a pitch to the user community for 
some help from people and organizations that are not interested in writing code 
but have a major interest in testing.
In addition to access to test equipment, this might actually get new people on 
the team with the right skills required to extend the test scripts and test 
procedure documentation.

Does anyone have a list of the configuration specifications that are required 
to test a new release?

Would it help to approach major users of Cloudstack with a direct request for 
use of their test equipment and QA staff in return for early access to new 
releases and testing on their hardware?

Ron

>
> Alexander Hitchins
> 
> E: a...@alexhitchins.com
> W: alexhitchins.com
> M: 07788 423 969
> T: 01892 523 587
>
> -Original Message-
> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> Sent: 30 June 2017 20:13
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] - Releases, Project Management & Funding 
> Thereof
>
> On 30/06/2017 2:19 PM, Alex Hitchins wrote:
>> Releasing against a defined reference rig would be a very good idea, 
>> especially if we could replicate several.
>>
>> It concerns me slightly that we are building a platform we want to promote 
>> people to deploy in enterprise environments with the caveat 'run at your own 
>> risk'.
> There is no choice as near as I can tell.
> It seems that there are too many combinations of hardware, network 
> configurations and OSs to guarantee that a release will work on all of them 
> and still get a release delivered.
> As Will pointed out, the Release Team does not have access to every 
> combination where previous releases are in production use, to test the new 
> release candidate.
>
> Currently it may be  not very explicit about what are the fully tested 
> configurations and from what Will said, I gather that there is no policy 
> saying what the minimum test set is to declare a release ready to go.
>
> There is no reason preventing a release being tested after release by an 
> end-user or a developer and adding to the release documentation something to 
> the effect that "Users have reported that this release has been put into 
> production on XYZ configuration with no modifications."
> This at least gets the release out the door for the 95% of the users that do 
> not have an XYZ rather than waiting for someone with an XYZ to find time to 
> test it.
>
> It may also encourage companies using or selling XYZs to put up some 
> resources (hardware and people) dedicated to testing so that they get into 
> the initial release.
>
> Ron
>
>> We need to up our game.
>>
>> 'We' he says, after two years MIA!
>>
>>> On 30 Jun 2017, at 18:41, Ron Wheeler  
>>> wrote:
>>>
>>> How much time is there between a feature freeze and the RC being cut.?
>>> Do people know far enough in advance that their feature is in or out and if 
>>> in must be ready to go to a RC release by such and such a date?
>>>
>>> Is the use case 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

On 30/06/2017 3:28 PM, Alex Hitchins wrote:

We can't validate all scenarios no, hence suggesting several common setups as a 
reasonable baseline. I like the idea of users posting their hardware and 
versions as a community endeavour.

I strongly feel there should be an established, physical setup that the release 
team have access to in order to validate a release.


This is perhaps something that should be requested from the user community.
I would expect that anyone running Cloudstack in production on a major 
site would have a test setup and might be very happy to have the dev 
team test on their setup.
This would save them a lot of resources at the expense of a bit of time 
on their test environment.



If this was some random cat meme generator on GitHub, I'd accept the risk in 
running an untested version. For something I'd be running my business on 
however I'd expect there being some weight behind the release.

Perhaps I have unrealistic expectations!


Not at all.
Your expectations might be the key to making a pitch to the user 
community for some help from people and organizations that are not 
interested in writing code but have a major interest in testing.
In addition to access to test equipment, this might actually get new 
people on the team with the right skills required to extend the test 
scripts and test procedure documentation.


Does anyone have a list of the configuration specifications that are 
required to test a new release?


Would it help to approach major users of Cloudstack with a direct 
request for use of their test equipment and QA staff in return for early 
access to new releases and testing on their hardware?


Ron



Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
Sent: 30 June 2017 20:13
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof

On 30/06/2017 2:19 PM, Alex Hitchins wrote:

Releasing against a defined reference rig would be a very good idea, especially 
if we could replicate several.

It concerns me slightly that we are building a platform we want to promote 
people to deploy in enterprise environments with the caveat 'run at your own 
risk'.

There is no choice as near as I can tell.
It seems that there are too many combinations of hardware, network 
configurations and OSs to guarantee that a release will work on all of them and 
still get a release delivered.
As Will pointed out, the Release Team does not have access to every combination 
where previous releases are in production use, to test the new release 
candidate.

Currently it may be  not very explicit about what are the fully tested 
configurations and from what Will said, I gather that there is no policy saying 
what the minimum test set is to declare a release ready to go.

There is no reason preventing a release being tested after release by an end-user or a 
developer and adding to the release documentation something to the effect that 
"Users have reported that this release has been put into production on XYZ 
configuration with no modifications."
This at least gets the release out the door for the 95% of the users that do 
not have an XYZ rather than waiting for someone with an XYZ to find time to 
test it.

It may also encourage companies using or selling XYZs to put up some resources 
(hardware and people) dedicated to testing so that they get into the initial 
release.

Ron


We need to up our game.

'We' he says, after two years MIA!


On 30 Jun 2017, at 18:41, Ron Wheeler  wrote:

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and if in 
must be ready to go to a RC release by such and such a date?

Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on these 
configurations (A, B ,C) but the following configurations/use cases are not yet fully 
tested and other configuration may be used at your own risk after your own internal tests 
have been run successfully."
Is there any concept that "Cloudstack is verified to run on the following 
configurations and should also run on these configurations but has not been tested fully. 
It may run on these configurations but is not tested during the release cycle."

Ron


On 30/06/2017 1:14 PM, Will Stevens wrote:
Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule
is the lack of a CI setup which covers the entire software. Or at
least a 'supported' set of features. This means that the release is
always bound to a bunch of volunteers getting around to testing
their use case. Solidfire and Nuage are pretty good about getting some CI run 
on some pieces.
Trillian 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

We can't validate all scenarios no, hence suggesting several common setups as a 
reasonable baseline. I like the idea of users posting their hardware and 
versions as a community endeavour.

I strongly feel there should be an established, physical setup that the release 
team have access to in order to validate a release.

If this was some random cat meme generator on GitHub, I'd accept the risk in 
running an untested version. For something I'd be running my business on 
however I'd expect there being some weight behind the release.

Perhaps I have unrealistic expectations!


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Sent: 30 June 2017 20:13
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof

On 30/06/2017 2:19 PM, Alex Hitchins wrote:
> Releasing against a defined reference rig would be a very good idea, 
> especially if we could replicate several.
>
> It concerns me slightly that we are building a platform we want to promote 
> people to deploy in enterprise environments with the caveat 'run at your own 
> risk'.
There is no choice as near as I can tell.
It seems that there are too many combinations of hardware, network 
configurations and OSs to guarantee that a release will work on all of them and 
still get a release delivered.
As Will pointed out, the Release Team does not have access to every combination 
where previous releases are in production use, to test the new release 
candidate.

Currently it may be  not very explicit about what are the fully tested 
configurations and from what Will said, I gather that there is no policy saying 
what the minimum test set is to declare a release ready to go.

There is no reason preventing a release being tested after release by an 
end-user or a developer and adding to the release documentation something to 
the effect that "Users have reported that this release has been put into 
production on XYZ configuration with no modifications." 
This at least gets the release out the door for the 95% of the users that do 
not have an XYZ rather than waiting for someone with an XYZ to find time to 
test it.

It may also encourage companies using or selling XYZs to put up some resources 
(hardware and people) dedicated to testing so that they get into the initial 
release.

Ron

>
> We need to up our game.
>
> 'We' he says, after two years MIA!
>
>> On 30 Jun 2017, at 18:41, Ron Wheeler  wrote:
>>
>> How much time is there between a feature freeze and the RC being cut.?
>> Do people know far enough in advance that their feature is in or out and if 
>> in must be ready to go to a RC release by such and such a date?
>>
>> Is the use case testing well defined - hardware, configurations, etc.
>> Can you put out a release that says: "This release has been tested on these 
>> configurations (A, B ,C) but the following configurations/use cases are not 
>> yet fully tested and other configuration may be used at your own risk after 
>> your own internal tests have been run successfully."
>> Is there any concept that "Cloudstack is verified to run on the following 
>> configurations and should also run on these configurations but has not been 
>> tested fully. It may run on these configurations but is not tested during 
>> the release cycle."
>>
>> Ron
>>
>>> On 30/06/2017 1:14 PM, Will Stevens wrote:
>>> Have not looked at Release Tsar, but worth checking out.
>>>
>>> In general, the biggest problem we have with releasing on a schedule 
>>> is the lack of a CI setup which covers the entire software. Or at 
>>> least a 'supported' set of features. This means that the release is 
>>> always bound to a bunch of volunteers getting around to testing 
>>> their use case. Solidfire and Nuage are pretty good about getting some CI 
>>> run on some pieces.
>>> Trillian is great for covering a portion of the tests, but it 
>>> currently does not cover the whole software use case. We also need 
>>> more trillian deployments in the wild to support the CI initiative.
>>>
>>> We do need to be stricter about nothing going in after an RC is cut 
>>> but blockers. The limited CI coverage and the dependence on a few 
>>> people for testing exasperates this problem.
>>>
>>> So there is multiple layers to this. I think someone dedicates to 
>>> the RM role would help this a lot because they would have a single 
>>> community focus mandate, so it is in their best interest to 
>>> implement a flow which does not inhibit their ability to deliver on their 
>>> mandate.
>>>
>>> On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
>>> 
>>> wrote:
>>>
 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 

Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

Rewritten to have sentences that parse into some understandable English.


If the plan is to do several releases each year, something has to change 
in the process.


Any idea about what tasks took up most of the time?

Were there any specific issues that ate up more time than you expected.

Would breaking Cloudstack into separately modules that are separately 
released by different teams make things more manageable?
At some point, one would expect that the APIs would get stabilized so 
that modules could be upgraded without affecting the whole system.


Obviously some changes would require mods to more than one module but 
depending on how one defines the releasable packages, many changes 
should not.


This may get into the case where the current releases only supports part 
of the functionality that the end user needs and they may have to wait a 
week or 2 to find a set of packages that fully supports their particular 
case.
However in the meantime, new functionality can be released to the rest 
of the user community that does not need this case.


This would allow bug fix releases to get out the door quicker if they 
only affected one module.
It would also reduce the testing of each release by a lot and might make 
tests to be more complete on key areas.


It might help users get new functionality into production if they are 
only upgrade part of the system at one time. I would expect a lot less 
testing to be required if only the admin user interface is changing.


It might also expand the dev community as people with interests limited 
to one area (UI, networking hardware) might feel sufficiently 
knowledgeable to contribute.



Ron


On 30/06/2017 1:48 PM, Will Stevens wrote:

I am not doing much right now because our company has many other things on
the go.

For about the first 6 months of 2016 CloudOps donated my time full time to
act as the release manager of 4.9. That is not something we or I can
sustain. Which is part of the problem.

On Jun 30, 2017 1:28 PM, "Ron Wheeler" 
wrote:


How many companies are funding staff now to work on Cloudstack? How much
time?
How many FTEs does that come to if one adds it all up?

It is harder to get people who are working on their own time to do
administrative tasks on a tight schedule.

If someone is working for a company that is expecting the person to be
doing "cloudstack stuff", it may be possible to convince the company to
dedicate part of that person's time to release management.

A RM doing it all may be harder to fund/organize than a Release Team. Not
all of the tasks have to be done in sequence or by one person.

Ron

On 30/06/2017 1:13 PM, Wido den Hollander wrote:


Op 30 juni 2017 om 18:09 schreef Paul Angus :


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.

True. But still, somebody who dedicated 5 days a week on releases and

keeping track of the project is still very welcome I think.

I'm not sure we have a problem in our 'loosely-agreed' process, it's just

that repeatedly people have ignored it.

I wouldn't say ignore it, but maybe forgotten about the process with all

the best intentions.

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.

Somebody who reverts a PR or commit to get to a proper release is

probably a good thing. RM is a busy task and done in spare time. That's not
always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week
with just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few
companies donating 10k per year should probably allow you to hire a person.

Wido

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 

RE: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Marty Godsey]

"" Would breaking Cloudstack into separately modules that are separately 
released by different teams make things more manageable?""


Please don’t do this. This is basically OpenStack at that point. I would write 
more on this but ZI am on a phone call.. :)  I just wanted say I don’t think 
that is a good idea since the fact that Cloudtsack IS one project is one of its 
strengths..

Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Sent: Friday, June 30, 2017 2:54 PM
To: dev@cloudstack.apache.org
Subject: Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & 
Funding Thereof

If the plan is to do several releases each year, something has to change in the 
process.

Any idea about what tasks took up most of the time?

Were there any specific issues that ate up more time than you expected.

Would breaking Cloudstack into separately modules that are separately released 
by different teams make things more manageable?
At some point, one would expect that the APIs would get stabilized so that 
modules could be upgraded without affecting the whole system.
Obviously some changes would require mods to more than one module but depending 
on how one defines the releasable packages, many changes should not.
This may get into the case where part of the current releases on support part 
of the functionality that the end user needs and they may have to wait a week 
or 2 to find a set of packages that fully supports their particular case but in 
the meantime, new functionality can be released to the rest of the user 
community that does not need this case.
This would allow bug fix releases to get out the door quicker if they only 
affected one module.
It would also reduce the testing of each release by a lot and might tests to be 
more complete on key areas.

Ron


On 30/06/2017 1:48 PM, Will Stevens wrote:
> I am not doing much right now because our company has many other 
> things on the go.
>
> For about the first 6 months of 2016 CloudOps donated my time full 
> time to act as the release manager of 4.9. That is not something we or 
> I can sustain. Which is part of the problem.
>
> On Jun 30, 2017 1:28 PM, "Ron Wheeler" 
> 
> wrote:
>
>> How many companies are funding staff now to work on Cloudstack? How 
>> much time?
>> How many FTEs does that come to if one adds it all up?
>>
>> It is harder to get people who are working on their own time to do 
>> administrative tasks on a tight schedule.
>>
>> If someone is working for a company that is expecting the person to 
>> be doing "cloudstack stuff", it may be possible to convince the 
>> company to dedicate part of that person's time to release management.
>>
>> A RM doing it all may be harder to fund/organize than a Release Team. 
>> Not all of the tasks have to be done in sequence or by one person.
>>
>> Ron
>>
>> On 30/06/2017 1:13 PM, Wido den Hollander wrote:
>>
>>> Op 30 juni 2017 om 18:09 schreef Paul Angus :

 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.

 True. But still, somebody who dedicated 5 days a week on releases 
 and
>>> keeping track of the project is still very welcome I think.
>>>
>>> I'm not sure we have a problem in our 'loosely-agreed' process, it's 
>>> just
 that repeatedly people have ignored it.

 I wouldn't say ignore it, but maybe forgotten about the process 
 with all
>>> the best intentions.
>>>
>>> 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.

 Somebody who reverts a PR or commit to get to a proper release is
>>> probably a good thing. RM is a busy task and done in spare time. 
>>> That's not always easy.
>>>
>>> Other projects like Ceph have a dedicated RM who is busy the whole 
>>> week with just the new release.
>>>
>>> We could use such a person, but we would need the funding.
>>>
>>> How much would that cost? Well, you need to keep the overhead down. 
>>> A few companies donating 10k per year 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

On 30/06/2017 2:19 PM, Alex Hitchins wrote:

Releasing against a defined reference rig would be a very good idea, especially 
if we could replicate several.

It concerns me slightly that we are building a platform we want to promote 
people to deploy in enterprise environments with the caveat 'run at your own 
risk'.

There is no choice as near as I can tell.
It seems that there are too many combinations of hardware, network 
configurations and OSs to guarantee that a release will work on all of 
them and still get a release delivered.
As Will pointed out, the Release Team does not have access to every 
combination where previous releases are in production use, to test the 
new release candidate.


Currently it may be  not very explicit about what are the fully tested 
configurations and from what Will said, I gather that there is no policy 
saying what the minimum test set is to declare a release ready to go.


There is no reason preventing a release being tested after release by an 
end-user or a developer and adding to the release documentation 
something to the effect that "Users have reported that this release has 
been put into production on XYZ configuration with no modifications." 
This at least gets the release out the door for the 95% of the users 
that do not have an XYZ rather than waiting for someone with an XYZ to 
find time to test it.


It may also encourage companies using or selling XYZs to put up some 
resources (hardware and people) dedicated to testing so that they get 
into the initial release.


Ron



We need to up our game.

'We' he says, after two years MIA!


On 30 Jun 2017, at 18:41, Ron Wheeler  wrote:

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and if in 
must be ready to go to a RC release by such and such a date?

Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on these 
configurations (A, B ,C) but the following configurations/use cases are not yet fully 
tested and other configuration may be used at your own risk after your own internal tests 
have been run successfully."
Is there any concept that "Cloudstack is verified to run on the following 
configurations and should also run on these configurations but has not been tested fully. 
It may run on these configurations but is not tested during the release cycle."

Ron


On 30/06/2017 1:14 PM, Will Stevens wrote:
Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule is the
lack of a CI setup which covers the entire software. Or at least a
'supported' set of features. This means that the release is always bound to
a bunch of volunteers getting around to testing their use case. Solidfire
and Nuage are pretty good about getting some CI run on some pieces.
Trillian is great for covering a portion of the tests, but it currently
does not cover the whole software use case. We also need more trillian
deployments in the wild to support the CI initiative.

We do need to be stricter about nothing going in after an RC is cut but
blockers. The limited CI coverage and the dependence on a few people for
testing exasperates this problem.

So there is multiple layers to this. I think someone dedicates to the RM
role would help this a lot because they would have a single community focus
mandate, so it is in their best interest to implement a flow which does not
inhibit their ability to deliver on their mandate.

On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
wrote:


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:

Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

If the plan is to do several releases each year, something has to change 
in the process.


Any idea about what tasks took up most of the time?

Were there any specific issues that ate up more time than you expected.

Would breaking Cloudstack into separately modules that are separately 
released by different teams make things more manageable?
At some point, one would expect that the APIs would get stabilized so 
that modules could be upgraded without affecting the whole system.
Obviously some changes would require mods to more than one module but 
depending on how one defines the releasable packages, many changes 
should not.
This may get into the case where part of the current releases on support 
part of the functionality that the end user needs and they may have to 
wait a week or 2 to find a set of packages that fully supports their 
particular case but in the meantime, new functionality can be released 
to the rest of the user community that does not need this case.
This would allow bug fix releases to get out the door quicker if they 
only affected one module.
It would also reduce the testing of each release by a lot and might 
tests to be more complete on key areas.


Ron


On 30/06/2017 1:48 PM, Will Stevens wrote:

I am not doing much right now because our company has many other things on
the go.

For about the first 6 months of 2016 CloudOps donated my time full time to
act as the release manager of 4.9. That is not something we or I can
sustain. Which is part of the problem.

On Jun 30, 2017 1:28 PM, "Ron Wheeler" 
wrote:


How many companies are funding staff now to work on Cloudstack? How much
time?
How many FTEs does that come to if one adds it all up?

It is harder to get people who are working on their own time to do
administrative tasks on a tight schedule.

If someone is working for a company that is expecting the person to be
doing "cloudstack stuff", it may be possible to convince the company to
dedicate part of that person's time to release management.

A RM doing it all may be harder to fund/organize than a Release Team. Not
all of the tasks have to be done in sequence or by one person.

Ron

On 30/06/2017 1:13 PM, Wido den Hollander wrote:


Op 30 juni 2017 om 18:09 schreef Paul Angus :


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.

True. But still, somebody who dedicated 5 days a week on releases and

keeping track of the project is still very welcome I think.

I'm not sure we have a problem in our 'loosely-agreed' process, it's just

that repeatedly people have ignored it.

I wouldn't say ignore it, but maybe forgotten about the process with all

the best intentions.

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.

Somebody who reverts a PR or commit to get to a proper release is

probably a good thing. RM is a busy task and done in spare time. That's not
always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week
with just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few
companies donating 10k per year should probably allow you to hire a person.

Wido

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] - 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Tutkowski, Mike]

Hi Rajani,

Just checking: Was it your intention to create a new RC on Monday?

Thanks!
Mike

On 6/28/17, 3:28 AM, "Rajani Karuturi"  wrote:

Thanks for confirming. I will keep this RC open for two more days
for others to test before next RC.

Agree on merging PRs part. That is our release principle in
general.

~ Rajani

http://cloudplatform.accelerite.com/

On June 28, 2017 at 2:51 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi Rajani,

Yes we qualified that fix. Can anyone else pls also confirm.

To be very clear - this is a generic issue (with native VR based
ACS), not
tight to Nuage at all.

We should not take in new PR's when we move from RC to RC to my
view - this
way always new issues will pop up.

Best,

Kris

On 28 June 2017 at 06:49, Rajani Karuturi 
wrote:

Hi Kris,

Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.

Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would help uncover issues before they
are merged.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 8:14 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162

Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike
 wrote:

+1 (binding)

I am not concerned about the code changes that went into this RC
since the
previous RC, so I am still happy with the amount of automated
and manual
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi" 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a
vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/
0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
RC20170626T1011

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

PGP release keys (signed using CBB44821):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure
to
indicate
"(binding)" with their vote?

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

Releasing against a defined reference rig would be a very good idea, especially 
if we could replicate several.

It concerns me slightly that we are building a platform we want to promote 
people to deploy in enterprise environments with the caveat 'run at your own 
risk'.

We need to up our game.

'We' he says, after two years MIA!

> On 30 Jun 2017, at 18:41, Ron Wheeler  wrote:
> 
> How much time is there between a feature freeze and the RC being cut.?
> Do people know far enough in advance that their feature is in or out and if 
> in must be ready to go to a RC release by such and such a date?
> 
> Is the use case testing well defined - hardware, configurations, etc.
> Can you put out a release that says: "This release has been tested on these 
> configurations (A, B ,C) but the following configurations/use cases are not 
> yet fully tested and other configuration may be used at your own risk after 
> your own internal tests have been run successfully."
> Is there any concept that "Cloudstack is verified to run on the following 
> configurations and should also run on these configurations but has not been 
> tested fully. It may run on these configurations but is not tested during the 
> release cycle."
> 
> Ron
> 
>> On 30/06/2017 1:14 PM, Will Stevens wrote:
>> Have not looked at Release Tsar, but worth checking out.
>> 
>> In general, the biggest problem we have with releasing on a schedule is the
>> lack of a CI setup which covers the entire software. Or at least a
>> 'supported' set of features. This means that the release is always bound to
>> a bunch of volunteers getting around to testing their use case. Solidfire
>> and Nuage are pretty good about getting some CI run on some pieces.
>> Trillian is great for covering a portion of the tests, but it currently
>> does not cover the whole software use case. We also need more trillian
>> deployments in the wild to support the CI initiative.
>> 
>> We do need to be stricter about nothing going in after an RC is cut but
>> blockers. The limited CI coverage and the dependence on a few people for
>> testing exasperates this problem.
>> 
>> So there is multiple layers to this. I think someone dedicates to the RM
>> role would help this a lot because they would have a single community focus
>> mandate, so it is in their best interest to implement a flow which does not
>> inhibit their ability to deliver on their mandate.
>> 
>> On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
>> wrote:
>> 
>>> 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

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

How much time is there between a feature freeze and the RC being cut.?
Do people know far enough in advance that their feature is in or out and 
if in must be ready to go to a RC release by such and such a date?


Is the use case testing well defined - hardware, configurations, etc.
Can you put out a release that says: "This release has been tested on 
these configurations (A, B ,C) but the following configurations/use 
cases are not yet fully tested and other configuration may be used at 
your own risk after your own internal tests have been run successfully."
Is there any concept that "Cloudstack is verified to run on the 
following configurations and should also run on these configurations but 
has not been tested fully. It may run on these configurations but is not 
tested during the release cycle."


Ron

On 30/06/2017 1:14 PM, Will Stevens wrote:

Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule is the
lack of a CI setup which covers the entire software. Or at least a
'supported' set of features. This means that the release is always bound to
a bunch of volunteers getting around to testing their use case. Solidfire
and Nuage are pretty good about getting some CI run on some pieces.
Trillian is great for covering a portion of the tests, but it currently
does not cover the whole software use case. We also need more trillian
deployments in the wild to support the CI initiative.

We do need to be stricter about nothing going in after an RC is cut but
blockers. The limited CI coverage and the dependence on a few people for
testing exasperates this problem.

So there is multiple layers to this. I think someone dedicates to the RM
role would help this a lot because they would have a single community focus
mandate, so it is in their best interest to implement a flow which does not
inhibit their ability to deliver on their mandate.

On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
wrote:


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

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

This makes me think of the OpenSSL (I think) that have some 'foundation' where 
there is a paid engineer and donated servers, switches etc to maintain builds 
and tests.

In my opinion, we need the same.

Who out there in a position to comment thinks they would be able to commit some 
budget towards some sort of dedicated role of which everyone benefits. You can 
contact me personally if you want to remain anonymous. Not asking for figures 
at this stage, just general intent.

Alex

> On 30 Jun 2017, at 18:14, Will Stevens  wrote:
> 
> Have not looked at Release Tsar, but worth checking out.
> 
> In general, the biggest problem we have with releasing on a schedule is the
> lack of a CI setup which covers the entire software. Or at least a
> 'supported' set of features. This means that the release is always bound to
> a bunch of volunteers getting around to testing their use case. Solidfire
> and Nuage are pretty good about getting some CI run on some pieces.
> Trillian is great for covering a portion of the tests, but it currently
> does not cover the whole software use case. We also need more trillian
> deployments in the wild to support the CI initiative.
> 
> We do need to be stricter about nothing going in after an RC is cut but
> blockers. The limited CI coverage and the dependence on a few people for
> testing exasperates this problem.
> 
> So there is multiple layers to this. I think someone dedicates to the RM
> role would help this a lot because they would have a single community focus
> mandate, so it is in their best interest to implement a flow which does not
> inhibit their ability to deliver on their mandate.
> 
> On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
> wrote:
> 
>> 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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

I know of four who have at least one full time resource dedicated, some with 
considerably more.

These people are working on features and support as this is where the income 
is. 

I feel if the cost of a full time RM was split across n sponsors, it would be a 
massive ROI.

> On 30 Jun 2017, at 18:27, Ron Wheeler  wrote:
> 
> How many companies are funding staff now to work on Cloudstack? How much time?
> How many FTEs does that come to if one adds it all up?
> 
> It is harder to get people who are working on their own time to do 
> administrative tasks on a tight schedule.
> 
> If someone is working for a company that is expecting the person to be doing 
> "cloudstack stuff", it may be possible to convince the company to dedicate 
> part of that person's time to release management.
> 
> A RM doing it all may be harder to fund/organize than a Release Team. Not all 
> of the tasks have to be done in sequence or by one person.
> 
> Ron
> 
> On 30/06/2017 1:13 PM, Wido den Hollander wrote:
>>> Op 30 juni 2017 om 18:09 schreef Paul Angus :
>>> 
>>> 
>>> 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.
>>> 
>> True. But still, somebody who dedicated 5 days a week on releases and 
>> keeping track of the project is still very welcome I think.
>> 
>>> I'm not sure we have a problem in our 'loosely-agreed' process, it's just 
>>> that repeatedly people have ignored it.
>>> 
>> I wouldn't say ignore it, but maybe forgotten about the process with all the 
>> best intentions.
>> 
>>> 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.
>>> 
>> Somebody who reverts a PR or commit to get to a proper release is probably a 
>> good thing. RM is a busy task and done in spare time. That's not always easy.
>> 
>> Other projects like Ceph have a dedicated RM who is busy the whole week with 
>> just the new release.
>> 
>> We could use such a person, but we would need the funding.
>> 
>> How much would that cost? Well, you need to keep the overhead down. A few 
>> companies donating 10k per year should probably allow you to hire a person.
>> 
>> Wido
>> 
>>> 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"  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. 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Will Stevens]

I am not doing much right now because our company has many other things on
the go.

For about the first 6 months of 2016 CloudOps donated my time full time to
act as the release manager of 4.9. That is not something we or I can
sustain. Which is part of the problem.

On Jun 30, 2017 1:28 PM, "Ron Wheeler" 
wrote:

> How many companies are funding staff now to work on Cloudstack? How much
> time?
> How many FTEs does that come to if one adds it all up?
>
> It is harder to get people who are working on their own time to do
> administrative tasks on a tight schedule.
>
> If someone is working for a company that is expecting the person to be
> doing "cloudstack stuff", it may be possible to convince the company to
> dedicate part of that person's time to release management.
>
> A RM doing it all may be harder to fund/organize than a Release Team. Not
> all of the tasks have to be done in sequence or by one person.
>
> Ron
>
> On 30/06/2017 1:13 PM, Wido den Hollander wrote:
>
>> Op 30 juni 2017 om 18:09 schreef Paul Angus :
>>>
>>>
>>> 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.
>>>
>>> True. But still, somebody who dedicated 5 days a week on releases and
>> keeping track of the project is still very welcome I think.
>>
>> I'm not sure we have a problem in our 'loosely-agreed' process, it's just
>>> that repeatedly people have ignored it.
>>>
>>> I wouldn't say ignore it, but maybe forgotten about the process with all
>> the best intentions.
>>
>> 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.
>>>
>>> Somebody who reverts a PR or commit to get to a proper release is
>> probably a good thing. RM is a busy task and done in spare time. That's not
>> always easy.
>>
>> Other projects like Ceph have a dedicated RM who is busy the whole week
>> with just the new release.
>>
>> We could use such a person, but we would need the funding.
>>
>> How much would that cost? Well, you need to keep the overhead down. A few
>> companies donating 10k per year should probably allow you to hire a person.
>>
>> Wido
>>
>> 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"  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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

Thanks Wido.

Sounds like a warm reception from yourself. I will do more work on costs etc. 
Be a fun exercise even if likely proves academic. 



> On 30 Jun 2017, at 18:13, Wido den Hollander  wrote:
> 
> 
>> Op 30 juni 2017 om 18:09 schreef Paul Angus :
>> 
>> 
>> 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.
>> 
> 
> True. But still, somebody who dedicated 5 days a week on releases and keeping 
> track of the project is still very welcome I think.
> 
>> I'm not sure we have a problem in our 'loosely-agreed' process, it's just 
>> that repeatedly people have ignored it.
>> 
> 
> I wouldn't say ignore it, but maybe forgotten about the process with all the 
> best intentions.
> 
>> 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.
>> 
> 
> Somebody who reverts a PR or commit to get to a proper release is probably a 
> good thing. RM is a busy task and done in spare time. That's not always easy.
> 
> Other projects like Ceph have a dedicated RM who is busy the whole week with 
> just the new release.
> 
> We could use such a person, but we would need the funding.
> 
> How much would that cost? Well, you need to keep the overhead down. A few 
> companies donating 10k per year should probably allow you to hire a person.
> 
> Wido
> 
>> 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"  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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

How many companies are funding staff now to work on Cloudstack? How much 
time?

How many FTEs does that come to if one adds it all up?

It is harder to get people who are working on their own time to do 
administrative tasks on a tight schedule.


If someone is working for a company that is expecting the person to be 
doing "cloudstack stuff", it may be possible to convince the company to 
dedicate part of that person's time to release management.


A RM doing it all may be harder to fund/organize than a Release Team. 
Not all of the tasks have to be done in sequence or by one person.


Ron

On 30/06/2017 1:13 PM, Wido den Hollander wrote:

Op 30 juni 2017 om 18:09 schreef Paul Angus :


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.


True. But still, somebody who dedicated 5 days a week on releases and keeping 
track of the project is still very welcome I think.


I'm not sure we have a problem in our 'loosely-agreed' process, it's just that 
repeatedly people have ignored it.


I wouldn't say ignore it, but maybe forgotten about the process with all the 
best intentions.


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.


Somebody who reverts a PR or commit to get to a proper release is probably a 
good thing. RM is a busy task and done in spare time. That's not always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week with 
just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few 
companies donating 10k per year should probably allow you to hire a person.

Wido


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"  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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Will Stevens]

Have not looked at Release Tsar, but worth checking out.

In general, the biggest problem we have with releasing on a schedule is the
lack of a CI setup which covers the entire software. Or at least a
'supported' set of features. This means that the release is always bound to
a bunch of volunteers getting around to testing their use case. Solidfire
and Nuage are pretty good about getting some CI run on some pieces.
Trillian is great for covering a portion of the tests, but it currently
does not cover the whole software use case. We also need more trillian
deployments in the wild to support the CI initiative.

We do need to be stricter about nothing going in after an RC is cut but
blockers. The limited CI coverage and the dependence on a few people for
testing exasperates this problem.

So there is multiple layers to this. I think someone dedicates to the RM
role would help this a lot because they would have a single community focus
mandate, so it is in their best interest to implement a flow which does not
inhibit their ability to deliver on their mandate.

On Jun 30, 2017 12:53 PM, "Ron Wheeler" 
wrote:

> 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 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Wido den Hollander]

> Op 30 juni 2017 om 18:09 schreef Paul Angus :
> 
> 
> 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.
> 

True. But still, somebody who dedicated 5 days a week on releases and keeping 
track of the project is still very welcome I think.

> I'm not sure we have a problem in our 'loosely-agreed' process, it's just 
> that repeatedly people have ignored it.
> 

I wouldn't say ignore it, but maybe forgotten about the process with all the 
best intentions.

> 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.
> 

Somebody who reverts a PR or commit to get to a proper release is probably a 
good thing. RM is a busy task and done in spare time. That's not always easy.

Other projects like Ceph have a dedicated RM who is busy the whole week with 
just the new release.

We could use such a person, but we would need the funding.

How much would that cost? Well, you need to keep the overhead down. A few 
companies donating 10k per year should probably allow you to hire a person.

Wido

> 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"  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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

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"  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 

RE: JIRA - PLEASE READ

[Giles Sirett]

From reading back through the thread, I think pauls initial point was around 
the fact that currently (and I don’t know whether this is hardcoded in our 
guidelines,etc) there is an assumption that the workflow for an issue will be 
Jira issue>fix>PR>> - and that is followed erratically

The Jira issue usually contains the original problem statement, whether 
reported by somebody here or a regular user. It then allows people to trace 
that problem statement through the release note path to see when it was fixed

And when I say people here - I am not talking about the people on this list - I 
am talking about the people out there using ACS in the wild. 

Will - I fully get your statement "I personally have never searched jira for an 
issue."  And understand why you wouldn't have - but that is maybe the root of 
the point here. People outside of our core dev community do  - a lot (I can 
verify that from first hand experience)

If we want ACS adoption to grow, maintaining *some* form of reliable trackable 
issues list is essential IMO

Jira is currently  THE  data point that most of our users (who don’t have the 
luxury of participating in these lists or being able to understand code 
commits) currently will use to identify the symptoms theyre experiencing &  see 
what version of ACS fixed the problem  (again, from first hand experience)

The other factor is the fact that jira is very "visible" in searches (Just 
google "cloudstack unable" foo ) - it will be the first place that many people 
stumble into when tracking down their problems. Use it or not - that should be 
consistent IMO

I have ZERO affinity to Jira (I'll show my hand and say I've never liked it) 
and do not like the potential split brain of having no mapped relationship 
between issues and PR's. So, if github issues  do a better job  - then great - 
lets do it.





Kind regards
Giles

giles.sir...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com] 
Sent: 30 June 2017 16:34
To: dev@cloudstack.apache.org
Subject: RE: JIRA - PLEASE READ

Whether we use 'GitHub Issues' or 'Jira Issues' doesn't change the basic point, 
which is bug fixes and indeed features need to be tracked.

If someone wants to know what versions a feature is in, or what version a bug 
was fixed, or if anyone has experienced/reported/fix a bug that they are 
experiencing, then they need somewhere to go to find that.  When doing a 
release we need to be able to easily see what bugs are outstanding for that 
release and which are blocker/critical etc.

Burying information in PRs just leads to chaos.  And if someone has to write a 
tool to extract what has gone into a release, then it's obviously too 
complicated.



Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
  
 


-Original Message-
From: Will Stevens [mailto:williamstev...@gmail.com]
Sent: 30 June 2017 16:07
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

Yes, we would be adopting github issues for that then. If you want to handle 
those in jira we could, but i personally dont see any value in a jira ticket 
for an actual PR.

On Jun 30, 2017 10:26 AM, "Ron Wheeler" 
wrote:

> 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 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Paul Angus]

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"  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" 
wrote:

>
> 

RE: JIRA - PLEASE READ

[Paul Angus]

Whether we use 'GitHub Issues' or 'Jira Issues' doesn't change the basic point, 
which is bug fixes and indeed features need to be tracked.

If someone wants to know what versions a feature is in, or what version a bug 
was fixed, or if anyone has experienced/reported/fix a bug that they are 
experiencing, then they need somewhere to go to find that.  When doing a 
release we need to be able to easily see what bugs are outstanding for that 
release and which are blocker/critical etc.

Burying information in PRs just leads to chaos.  And if someone has to write a 
tool to extract what has gone into a release, then it's obviously too 
complicated.



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Will Stevens [mailto:williamstev...@gmail.com] 
Sent: 30 June 2017 16:07
To: dev@cloudstack.apache.org
Subject: Re: JIRA - PLEASE READ

Yes, we would be adopting github issues for that then. If you want to handle 
those in jira we could, but i personally dont see any value in a jira ticket 
for an actual PR.

On Jun 30, 2017 10:26 AM, "Ron Wheeler" 
wrote:

> 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"  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 meI think we need 
>> something else.
>>
>> On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey 
>> 

Re: JIRA - PLEASE READ

[Will Stevens]

Yes, we would be adopting github issues for that then. If you want to
handle those in jira we could, but i personally dont see any value in a
jira ticket for an actual PR.

On Jun 30, 2017 10:26 AM, "Ron Wheeler" 
wrote:

> 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"  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 meI think we need something
>> else.
>>
>> On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey 
>> 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
>>> 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

1) Are there any good models in the Apache community of projects that 
maintain a quality release process without full-time staff?


2) Are there things that cause most of the grief around releases? 
Anything on the Release Manager's list of aggravations that could be 
eliminated?

Is there a good history of moving from Release Candidates to Releases?
Are there tasks that the RM has to do that should be shifted to the 
community?



Ron

Just provide the rest of the joke.
Q: How many psychiatrists does it take to change a lightbulb ?
A: Only one, but the lightbulb must want to change.
A: None; the bulb will change itself when it is ready.
A: How long have you been having this fantasy ?
A: How many do *you* think it takes?

On 30/06/2017 9:53 AM, Will Stevens wrote:

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"  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" 
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 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

Re: JIRA - PLEASE READ

[Ron Wheeler]

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"  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 meI think we need something
else.

On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey  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  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 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

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"  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" 
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  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 

Current Developer Setup Guide

[Alex Hitchins]

All,

 

Is the following link the best guide to assist me in getting CloudStack
ready for development on my machine? 

 

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+a+CloudSta
ck+dev+environment+on+Windows

 

 

I note the last modified date is Jan 2015.

 

And yes - I *am* intending to develop under Windows.

 

 

Alexander Hitchins



E: a...@alexhitchins.com

W: alexhitchins.com

M: 07788 423 969

T: 01892 523 587

 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Will Stevens]

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"  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" 
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  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 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Will Stevens]

I personally think it is important to have a person working consistently on
the ACS releases. It is a ton of work and with the job rotating right now,
it makes it harder for everyone. That said, no organization can afford to
hire a dedicated RM for year(s) at a time.  I have considered it, but even
if I did, I would depend on other organizations to contribute towards that
person's salary to be able to actually make it work.

On Jun 30, 2017 9:33 AM, "Alex Hitchins"  wrote:

> I'll read those links, thank you for providing them.
>
> Do you think this is a move in the wrong direction or just an unnecessary
> move to begin with?
>
> Alexander Hitchins
> 
> E: a...@alexhitchins.com
> W: alexhitchins.com
> M: 07788 423 969
> T: 01892 523 587
>
> -Original Message-
> From: Ron Wheeler [mailto:rwhee...@artifact-software.com]
> Sent: 30 June 2017 14:06
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof
>
>
> https://www.apache.org/foundation/contributing.html says:
> "If you have a specific target or project that you wish to directly
> support, pleasecontact us  foundation/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 
> 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 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

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" 
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  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
>>
>> 

RE: [DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

I'll read those links, thank you for providing them.

Do you think this is a move in the wrong direction or just an unnecessary move 
to begin with?

Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

-Original Message-
From: Ron Wheeler [mailto:rwhee...@artifact-software.com] 
Sent: 30 June 2017 14:06
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] - Releases, Project Management & Funding Thereof


https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly support, 
pleasecontact us 
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  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

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Will Stevens]

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" 
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  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 

Re: [DISCUSS] - Releases, Project Management & Funding Thereof

[Ron Wheeler]

https://www.apache.org/foundation/contributing.html says:
"If you have a specific target or project that you wish to directly 
support, pleasecontact us 
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  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 

RE: JIRA - PLEASE READ

[Will Stevens]

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"  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 meI think we need something
else.

On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey  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  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 

RE: JIRA - PLEASE READ

[Alex Hitchins]

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 meI think we need something else.

On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey  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  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 
> > > 
> > 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 

[DISCUSS] - Releases, Project Management & Funding Thereof

[Alex Hitchins]

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  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 

RE: JIRA - PLEASE READ

[Giles Sirett]

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  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