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

2017-06-30 Thread 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

2017-06-30 Thread 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" 
> <rwhee...@artifact-software.com>
> 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 <paul.an...@shapeblue.com>:
>>>>
>>>> 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. 

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

2017-06-30 Thread 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] -