Re: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof
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 line, more and more people will follow the Cosmic/Schuberg P
RE: ***UNCHECKED*** Re: [DISCUSS] - Releases, Project Management & Funding Thereof
"" 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 >>>>
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 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