You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2014/08/11 15:24:47 UTC
4.5 RM
Hi folks;
So we haven't had anyone step up to be release manager for 4.5 yet. So
you consider this either a threat or me volunteering depending on your
perspective. :)
If no one else steps up by midweek I'm happy to be the RM for 4.5. My
plan would be to likely hit feature freeze nearly immediately, and
pick up the schedule from there; but I don't want to distract from
Daan's 4.4.1 work.
If I do end up taking this on, I'd like to take it as an opportunity
to figure out/put into practice a good, workable git workflow, so I'll
probably be asking Rajani, Rohit, and Leo for some
guidance/suggestions as we move forward.
--David
Re: 4.5 RM
Posted by Mike Tutkowski <mi...@solidfire.com>.
Thanks for being willing to take on this role, David!
On Mon, Aug 11, 2014 at 7:24 AM, David Nalley <da...@gnsa.us> wrote:
> Hi folks;
>
> So we haven't had anyone step up to be release manager for 4.5 yet. So
> you consider this either a threat or me volunteering depending on your
> perspective. :)
>
> If no one else steps up by midweek I'm happy to be the RM for 4.5. My
> plan would be to likely hit feature freeze nearly immediately, and
> pick up the schedule from there; but I don't want to distract from
> Daan's 4.4.1 work.
>
> If I do end up taking this on, I'd like to take it as an opportunity
> to figure out/put into practice a good, workable git workflow, so I'll
> probably be asking Rajani, Rohit, and Leo for some
> guidance/suggestions as we move forward.
>
> --David
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
Re: 4.5 RM
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 11, 2014, at 1:34 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi Sebastien,
>
> On 11-Aug-2014, at 5:35 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>>
>> On Aug 11, 2014, at 9:24 AM, David Nalley <da...@gnsa.us> wrote:
>>
>>> Hi folks;
>>>
>>> So we haven't had anyone step up to be release manager for 4.5 yet. So
>>> you consider this either a threat or me volunteering depending on your
>>> perspective. :)
>>>
>>> If no one else steps up by midweek I'm happy to be the RM for 4.5. My
>>> plan would be to likely hit feature freeze nearly immediately, and
>>> pick up the schedule from there; but I don't want to distract from
>>> Daan's 4.4.1 work.
>>>
>>> If I do end up taking this on, I'd like to take it as an opportunity
>>> to figure out/put into practice a good, workable git workflow, so I'll
>>> probably be asking Rajani, Rohit, and Leo for some
>>> guidance/suggestions as we move forward.
>>
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues
>> -guarantees that 4.5 will be on time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>
> We should explore that, Sebastien why don’t we start a thread or should we have IRC/Skype/GTM meetings?
>
> I don’t know but why did we stop having IRC meeting and what can we do to start doing them periodically again? I think some issues are rather solved synchronously using IRC, Skype etc. rather than just going back and forth on it on ML.
>
because attendance was low
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: 4.5 RM
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Sebastien,
On 11-Aug-2014, at 5:35 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Aug 11, 2014, at 9:24 AM, David Nalley <da...@gnsa.us> wrote:
>
>> Hi folks;
>>
>> So we haven't had anyone step up to be release manager for 4.5 yet. So
>> you consider this either a threat or me volunteering depending on your
>> perspective. :)
>>
>> If no one else steps up by midweek I'm happy to be the RM for 4.5. My
>> plan would be to likely hit feature freeze nearly immediately, and
>> pick up the schedule from there; but I don't want to distract from
>> Daan's 4.4.1 work.
>>
>> If I do end up taking this on, I'd like to take it as an opportunity
>> to figure out/put into practice a good, workable git workflow, so I'll
>> probably be asking Rajani, Rohit, and Leo for some
>> guidance/suggestions as we move forward.
>
> IMHO we should not even release 4.5 until we have a agreed upon:
>
> -what our issues are and why we released 4.4 and 4.3 late.
> -taken action to resolve those issues
> -guarantees that 4.5 will be on time
>
> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
We should explore that, Sebastien why don’t we start a thread or should we have IRC/Skype/GTM meetings?
I don’t know but why did we stop having IRC meeting and what can we do to start doing them periodically again? I think some issues are rather solved synchronously using IRC, Skype etc. rather than just going back and forth on it on ML.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: 4.5 RM
Posted by Erik Weber <te...@gmail.com>.
On Tue, Aug 19, 2014 at 7:15 PM, David Nalley <da...@gnsa.us> wrote:
> >
> > IMHO we should not even release 4.5 until we have a agreed upon:
> >
> > -what our issues are and why we released 4.4 and 4.3 late.
> > -taken action to resolve those issues
> > -guarantees that 4.5 will be on time
> >
> > If we don't do that, I don't even know why we are putting ourselves
> through the pain of a release schedule.
> >
>
> So I've been trying to give this some thought. Here's my current line
> of thinking.
>
> The issues with late releases are not a function of our release
> process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points
> that interact with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for
> new features, but the range of options is so large that testing
> everything is a bit difficult. When someone makes a merge request; I
> suspect few people do much looking. Understandable, it's a boring
> task; and really looking doesn't tell us much except for style and
> egregious errors. We've rarely done mandatory testing of feature
> branches before they are merged in. If you want to ship on time, you
> must ensure that we are vociferously guarding the quality of the
> master and release branches; that we can verify programmatically that
> a commit or merge doesn't break things. We must insist on automated
> testing being added.
>
> So I've said all of that to say that I think that ship has sailed for
> 4.5. We are well past feature freeze; and we didn't really have any
> gating functionality. We frankly have very little idea of quality of
> whats in master right now. It's certainly worse than 4.4. So now we'll
> enter code freeze, we'll try and play catch up and fix all of the
> things we discover that are broken. And invariably, we'll be late
> again.
>
> If you want to solve this problem; my personal belief is that its
> really is tied to CI. Efforts around Travis are interesting and
> perhaps are a piece of that puzzle. Discussions around running CI are
> important as well, but I truly believe that we need a gating function
> that prohibits commits that increase our level of untested code or
> code that fails to pass testing. I've seen some other projects using
> pull requests in github, and then using the github pull request
> builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
>
A lot of valid points.
One of my personal beliefs is that we need a better CI solution/system,
rather than depending on the simulator.
There seems to be some sort of consensus/habit of trusting the simulator
output, but both 4.3 and 4.4 has/had some _serious_ issues that the
simulator didn't/doesn't catch.
Sometimes the problem lies in the systemvm, sometimes it could be a quirk
on the hypervisor, it doesn't really matter when you don't actually deploy
the essential parts of an acs installation to test them.
Unfortunately I have no good solution, for that I am far too new to the
whole acs ecosystem
--
Erik
RE: 4.5 RM
Posted by Edison Su <Ed...@citrix.com>.
There is another apache project using github model, I said in another mail thread: https://wiki.apache.org/cordova/GitWorkflow.
Please, let's take action, and move forward, to solve the long time issue around Apache CloudStack: no code review, no CI.
Should we start another around of discussion about code review and CI?
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Tuesday, August 19, 2014 10:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.5 RM
>
> >
> > IMHO we should not even release 4.5 until we have a agreed upon:
> >
> > -what our issues are and why we released 4.4 and 4.3 late.
> > -taken action to resolve those issues
> > -guarantees that 4.5 will be on time
> >
> > If we don't do that, I don't even know why we are putting ourselves
> through the pain of a release schedule.
> >
>
> So I've been trying to give this some thought. Here's my current line of
> thinking.
>
> The issues with late releases are not a function of our release process per se;
> but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points that interact
> with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for new
> features, but the range of options is so large that testing everything is a bit
> difficult. When someone makes a merge request; I suspect few people do
> much looking. Understandable, it's a boring task; and really looking doesn't
> tell us much except for style and egregious errors. We've rarely done
> mandatory testing of feature branches before they are merged in. If you
> want to ship on time, you must ensure that we are vociferously guarding the
> quality of the master and release branches; that we can verify
> programmatically that a commit or merge doesn't break things. We must
> insist on automated testing being added.
>
> So I've said all of that to say that I think that ship has sailed for 4.5. We are
> well past feature freeze; and we didn't really have any gating functionality.
> We frankly have very little idea of quality of whats in master right now. It's
> certainly worse than 4.4. So now we'll enter code freeze, we'll try and play
> catch up and fix all of the things we discover that are broken. And invariably,
> we'll be late again.
>
> If you want to solve this problem; my personal belief is that its really is tied to
> CI. Efforts around Travis are interesting and perhaps are a piece of that
> puzzle. Discussions around running CI are important as well, but I truly
> believe that we need a gating function that prohibits commits that increase
> our level of untested code or code that fails to pass testing. I've seen some
> other projects using pull requests in github, and then using the github pull
> request builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1]
> https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: github pull requests (was: Re: 4.5 RM)
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 22, 2014, at 6:04 AM, Leo Simons <LS...@schubergphilis.com> wrote:
> On Aug 19, 2014, at 11:06 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>> On Aug 19, 2014, at 4:38 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>
>>> Hi Sebastien,
>>>
>>> On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>> The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
>>>
>>> I would love to know your experience of using Github pull requests for the ACS doc repos, and if it will be a good idea to use it for the main repo as well?
>>
>> Using github pr for the docs repo has been a breeze. Of course it's a totally different "code" than cloudstack.
>>
>> The way this work is that people is that people fork on github and submit pr, we turned on github pr notifications (you have seen some of the emails). We don't merge via github though, we pull the patch by hand and apply it "git am" then push.
>
> Cool.
>
> Just want to point out that this gives the committer a _bit_ more responsibility to verify that there is an actual Contribution (as per the apache license and/or CLA) being done. When someone sends a patch via e-mail or to an apache.org system that’s pretty clearly implied, but for github, you do have to pay a little bit of attention [1].
>
as much attention as when taking a patch from RB or an attached patch in JIRA. I read the issue and I did not see anything alarming about pr.
imho, when we say "we accept pull requests" we are really saying that we are ok using github as we do RB.
> Also note you can do pull requests without github, see `git request-pull --help`. Of course the UI isn’t as pretty, but I’d suggest allowing it just to deal with “zomg github is down”, and to be ready to receive any future patches from Linus [2] :-)
yes, let's investigate that. Can you try submitting it that way ?
I skimmed [2], and to have the same issue as Linus we would need to define standards for our commits, which we don't have.
So right now our standard is extremely low. I am all in favor of upping our standard but remember that Linus is a benevolent dictatorship which unfortunately we are not :)
>
>
> cheers,
>
>
> Leo
>
> [1] https://issues.apache.org/jira/browse/LEGAL-156
> [2] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
>
Re: github pull requests (was: Re: 4.5 RM)
Posted by David Nalley <da...@gnsa.us>.
On Fri, Aug 22, 2014 at 6:04 AM, Leo Simons <LS...@schubergphilis.com> wrote:
> On Aug 19, 2014, at 11:06 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
>> On Aug 19, 2014, at 4:38 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>
>>> Hi Sebastien,
>>>
>>> On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>> The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
>>>
>>> I would love to know your experience of using Github pull requests for the ACS doc repos, and if it will be a good idea to use it for the main repo as well?
>>
>> Using github pr for the docs repo has been a breeze. Of course it's a totally different "code" than cloudstack.
>>
>> The way this work is that people is that people fork on github and submit pr, we turned on github pr notifications (you have seen some of the emails). We don't merge via github though, we pull the patch by hand and apply it "git am" then push.
>
> Cool.
>
> Just want to point out that this gives the committer a _bit_ more responsibility to verify that there is an actual Contribution (as per the apache license and/or CLA) being done. When someone sends a patch via e-mail or to an apache.org system that’s pretty clearly implied, but for github, you do have to pay a little bit of attention [1].
>
I don't believe that there is an increase or decrease in the
committer's responsibility. The important part is verifying that the
person has the right to contribute the work, and that they are making
a contribution; and that doesn't really change based on medium.
The act of submitting a Pull Request to a repo in the Foundation's
Github organization is as clear of a contribution as an email to a
foundation mailing list. Thats how both the ticket reads, and how it
works in practice for the ~30 projects making use of the github pull
request workflow at the Foundation.
> Also note you can do pull requests without github, see `git request-pull --help`. Of course the UI isn’t as pretty, but I’d suggest allowing it just to deal with “zomg github is down”, and to be ready to receive any future patches from Linus [2] :-)
>
>
> cheers,
>
>
> Leo
>
> [1] https://issues.apache.org/jira/browse/LEGAL-156
> [2] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
>
github pull requests (was: Re: 4.5 RM)
Posted by Leo Simons <LS...@schubergphilis.com>.
On Aug 19, 2014, at 11:06 PM, Sebastien Goasguen <ru...@gmail.com> wrote:
> On Aug 19, 2014, at 4:38 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>
>> Hi Sebastien,
>>
>> On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>>> The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
>>
>> I would love to know your experience of using Github pull requests for the ACS doc repos, and if it will be a good idea to use it for the main repo as well?
>
> Using github pr for the docs repo has been a breeze. Of course it's a totally different "code" than cloudstack.
>
> The way this work is that people is that people fork on github and submit pr, we turned on github pr notifications (you have seen some of the emails). We don't merge via github though, we pull the patch by hand and apply it "git am" then push.
Cool.
Just want to point out that this gives the committer a _bit_ more responsibility to verify that there is an actual Contribution (as per the apache license and/or CLA) being done. When someone sends a patch via e-mail or to an apache.org system that’s pretty clearly implied, but for github, you do have to pay a little bit of attention [1].
Also note you can do pull requests without github, see `git request-pull --help`. Of course the UI isn’t as pretty, but I’d suggest allowing it just to deal with “zomg github is down”, and to be ready to receive any future patches from Linus [2] :-)
cheers,
Leo
[1] https://issues.apache.org/jira/browse/LEGAL-156
[2] https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Re: 4.5 RM
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 19, 2014, at 4:38 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi Sebastien,
>
> On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>> The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
>
> I would love to know your experience of using Github pull requests for the ACS doc repos, and if it will be a good idea to use it for the main repo as well?
>
Using github pr for the docs repo has been a breeze. Of course it's a totally different "code" than cloudstack.
The way this work is that people is that people fork on github and submit pr, we turned on github pr notifications (you have seen some of the emails). We don't merge via github though, we pull the patch by hand and apply it "git am" then push.
ASF infra reduced the mirroring drastically, so the github mirror is now almost alway in sync with the main repo.
It has been great, because we used github hooks to publish the docs on RTD. So there is continuous deployment of the docs.
We could easily use github pr instead of review board (some projects I know have lots of tooling around RB and hence don't use github pr).
Libcloud (another much smaller project than cloudstack), also accepts pr. It also uses Travis to run all unitests. All pr are run on Travis which makes it nice to test sanity of the pr. It has a nice advantage over cloudstack, it's (almost) a rolling release in the sense that there are very few long term release branches and that most releases are tags on master.
Turning on pr notification for cloudstack is a 2 minute deal…
{off to bed, more tomorrow..)
> I personally think that everyone has used Github and it would take everyone less time to start using it, it will take us less time to implement for configuring the infra, it has good integrations with 3rd party solutions such as TravisCI that we may re-use and sometimes I find it faster than the asf git servers to push/pull.
>
> But, at times I’ve found the github mirror lagging behind asf repo, so we’ve to be cautious about this latencies.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: 4.5 RM
Posted by Ian Duffy <ia...@ianduffy.ie>.
> I personally think that everyone has used Github and it would take
everyone less time to start using it
Plus one to using github. I found using review board for uploading .patch
files to be a horrible experience.
The fork and pull request nature of github in my view compliments git and a
neat work flow. Not to mention they supply a lovely UI around doing it.
Another key point is that once a travis yaml file is present github will
automatically run the CI and display the status clearly on the pull request.
> it has good integrations with 3rd party solutions such as TravisCI
Its important to note 4.5 will not run on TravisCI unless some change is
made on cloudstacks dependency of the machine having a mac address.
On 19 August 2014 21:38, Rohit Yadav <ro...@shapeblue.com> wrote:
> Hi Sebastien,
>
> On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
> > The fact that we basically have none, pushes me to argue for a change in
> git workflow (see several other threads). because it will be way faster to
> start "gating" commits using a new agreed upon workflow (even though it
> would be a very artificial gate) than waiting for CI.
>
> I would love to know your experience of using Github pull requests for the
> ACS doc repos, and if it will be a good idea to use it for the main repo as
> well?
>
> I personally think that everyone has used Github and it would take
> everyone less time to start using it, it will take us less time to
> implement for configuring the infra, it has good integrations with 3rd
> party solutions such as TravisCI that we may re-use and sometimes I find it
> faster than the asf git servers to push/pull.
>
> But, at times I’ve found the github mirror lagging behind asf repo, so
> we’ve to be cautious about this latencies.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
Re: 4.5 RM
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Sebastien,
On 19-Aug-2014, at 10:17 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
> The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
I would love to know your experience of using Github pull requests for the ACS doc repos, and if it will be a good idea to use it for the main repo as well?
I personally think that everyone has used Github and it would take everyone less time to start using it, it will take us less time to implement for configuring the infra, it has good integrations with 3rd party solutions such as TravisCI that we may re-use and sometimes I find it faster than the asf git servers to push/pull.
But, at times I’ve found the github mirror lagging behind asf repo, so we’ve to be cautious about this latencies.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: 4.5 RM
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 19, 2014, at 2:32 PM, Prachi Damle <Pr...@citrix.com> wrote:
> +1 Agree that we need to have some form of CI to control basic quality
>
I don't think anyone would vote -1 on better CI
The fact that we basically have none, pushes me to argue for a change in git workflow (see several other threads). because it will be way faster to start "gating" commits using a new agreed upon workflow (even though it would be a very artificial gate) than waiting for CI.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Tuesday, August 19, 2014 10:16 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.5 RM
>
>>
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues
>> -guarantees that 4.5 will be on time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>>
>
> So I've been trying to give this some thought. Here's my current line of thinking.
>
> The issues with late releases are not a function of our release process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points that interact with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for new features, but the range of options is so large that testing everything is a bit difficult. When someone makes a merge request; I suspect few people do much looking. Understandable, it's a boring task; and really looking doesn't tell us much except for style and egregious errors. We've rarely done mandatory testing of feature branches before they are merged in. If you want to ship on time, you must ensure that we are vociferously guarding the quality of the master and release branches; that we can verify programmatically that a commit or merge doesn't break things. We must insist on automated testing being added.
>
> So I've said all of that to say that I think that ship has sailed for 4.5. We are well past feature freeze; and we didn't really have any gating functionality. We frankly have very little idea of quality of whats in master right now. It's certainly worse than 4.4. So now we'll enter code freeze, we'll try and play catch up and fix all of the things we discover that are broken. And invariably, we'll be late again.
>
> If you want to solve this problem; my personal belief is that its really is tied to CI. Efforts around Travis are interesting and perhaps are a piece of that puzzle. Discussions around running CI are important as well, but I truly believe that we need a gating function that prohibits commits that increase our level of untested code or code that fails to pass testing. I've seen some other projects using pull requests in github, and then using the github pull request builder[1] for jenkins to verify that every PR works. I know we've talked about gerrit previously, and perhaps that will work as well.
>
> [1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
RE: 4.5 RM
Posted by Prachi Damle <Pr...@citrix.com>.
+1 Agree that we need to have some form of CI to control basic quality
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Tuesday, August 19, 2014 10:16 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.5 RM
>
> IMHO we should not even release 4.5 until we have a agreed upon:
>
> -what our issues are and why we released 4.4 and 4.3 late.
> -taken action to resolve those issues
> -guarantees that 4.5 will be on time
>
> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>
So I've been trying to give this some thought. Here's my current line of thinking.
The issues with late releases are not a function of our release process per se; but are instead a function of our development process.
CloudStack is a relatively large codebase. It has a lots of points that interact with each other, and it's moderately complex.
Development moves forward and at least happy-path testing is done for new features, but the range of options is so large that testing everything is a bit difficult. When someone makes a merge request; I suspect few people do much looking. Understandable, it's a boring task; and really looking doesn't tell us much except for style and egregious errors. We've rarely done mandatory testing of feature branches before they are merged in. If you want to ship on time, you must ensure that we are vociferously guarding the quality of the master and release branches; that we can verify programmatically that a commit or merge doesn't break things. We must insist on automated testing being added.
So I've said all of that to say that I think that ship has sailed for 4.5. We are well past feature freeze; and we didn't really have any gating functionality. We frankly have very little idea of quality of whats in master right now. It's certainly worse than 4.4. So now we'll enter code freeze, we'll try and play catch up and fix all of the things we discover that are broken. And invariably, we'll be late again.
If you want to solve this problem; my personal belief is that its really is tied to CI. Efforts around Travis are interesting and perhaps are a piece of that puzzle. Discussions around running CI are important as well, but I truly believe that we need a gating function that prohibits commits that increase our level of untested code or code that fails to pass testing. I've seen some other projects using pull requests in github, and then using the github pull request builder[1] for jenkins to verify that every PR works. I know we've talked about gerrit previously, and perhaps that will work as well.
[1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: 4.5 RM
Posted by Min Chen <mi...@citrix.com>.
+1 on what David said. Shared the same feelings as him, we really need to
focus on the high priority issue facing CloudStack. Gerrit/Github pull
request will definitely help in this regards.
Thanks
-min
On 8/19/14 10:15 AM, "David Nalley" <da...@gnsa.us> wrote:
>>
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues
>> -guarantees that 4.5 will be on time
>>
>> If we don't do that, I don't even know why we are putting ourselves
>>through the pain of a release schedule.
>>
>
>So I've been trying to give this some thought. Here's my current line
>of thinking.
>
>The issues with late releases are not a function of our release
>process per se; but are instead a function of our development process.
>CloudStack is a relatively large codebase. It has a lots of points
>that interact with each other, and it's moderately complex.
>Development moves forward and at least happy-path testing is done for
>new features, but the range of options is so large that testing
>everything is a bit difficult. When someone makes a merge request; I
>suspect few people do much looking. Understandable, it's a boring
>task; and really looking doesn't tell us much except for style and
>egregious errors. We've rarely done mandatory testing of feature
>branches before they are merged in. If you want to ship on time, you
>must ensure that we are vociferously guarding the quality of the
>master and release branches; that we can verify programmatically that
>a commit or merge doesn't break things. We must insist on automated
>testing being added.
>
>So I've said all of that to say that I think that ship has sailed for
>4.5. We are well past feature freeze; and we didn't really have any
>gating functionality. We frankly have very little idea of quality of
>whats in master right now. It's certainly worse than 4.4. So now we'll
>enter code freeze, we'll try and play catch up and fix all of the
>things we discover that are broken. And invariably, we'll be late
>again.
>
>If you want to solve this problem; my personal belief is that its
>really is tied to CI. Efforts around Travis are interesting and
>perhaps are a piece of that puzzle. Discussions around running CI are
>important as well, but I truly believe that we need a gating function
>that prohibits commits that increase our level of untested code or
>code that fails to pass testing. I've seen some other projects using
>pull requests in github, and then using the github pull request
>builder[1] for jenkins to verify that every PR works. I know we've
>talked about gerrit previously, and perhaps that will work as well.
>
>[1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: 4.5 RM
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hey David!
Before you or anyone reads this, I want to say that I support what you’re trying to do here.
I’ve few ideas and concerns so if anyone is skimming please go to the bottom and read the list.
On 19-Aug-2014, at 7:15 pm, David Nalley <da...@gnsa.us> wrote:
>>
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues
>> -guarantees that 4.5 will be on time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>>
>
> So I've been trying to give this some thought. Here's my current line
> of thinking.
>
> The issues with late releases are not a function of our release
> process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points
> that interact with each other, and it's moderately complex.
There is one issue I want to raise -- we’ve about 2 months overlapping between releases and people don’t focus a lot on release branches. The length of a release cycle is perhaps inversely propositional to the interest and efforts around its release.
One solution would be to cut down on a 6 month cycle and work on our upgrade process (the db stuff) to have some kind of rolling release way. I’ve some ideas on how to do that and it involves the use of classical shortest path algorithms in the DB upgrader class and remove upgrading mechanism from mgmt server to a tool. (more on this idea soon).
Another issue is that companies that are more interested in commercial distributions of ACS may tend not to invest more resources on the upstream, low manpower/resources would mean less attention on ACS releases. Also, sponsored developers/committers are put in conflict of interests by these companies on where to do their work upstream or downstream. Due to overlap between releases, conflicting by their company’s own roadmap for their commercial distro’s release, I think people end up not working on release branches.
I don’t want to tell people how do their work — but the right way to work IMO would be to work on the upstream (i.e. ACS) first, and then help with all efforts during releases and take that release for their commercial distribution/fork thereby doing lesser work in the end. I think it’s a solvable leadership issue at those companies.
> Development moves forward and at least happy-path testing is done for
> new features, but the range of options is so large that testing
> everything is a bit difficult. When someone makes a merge request; I
> suspect few people do much looking. Understandable, it's a boring
A possible solution is to have maintainers whose job will be to review contributions in considerate time around these components, like we’ve maintainers in the Linux community. Another challenge on this is having more than one maintainer or component leader. It’s also the culture thing, we’re committer but how many of us are practicing being a committer on day to day basis, reading emails, helping people on JIRA, user ML, reviewing their contributions on reviewboard. Another issue is that most of the sponsored developers who work on the “core” stuff (and not the vendors plugins etc.) are from one company even if we go around manipulating numbers. So, I think we also have a culture issue to solve.
> task; and really looking doesn't tell us much except for style and
> egregious errors. We've rarely done mandatory testing of feature
> branches before they are merged in. If you want to ship on time, you
> must ensure that we are vociferously guarding the quality of the
> master and release branches; that we can verify programmatically that
> a commit or merge doesn't break things. We must insist on automated
> testing being added.
>
> So I've said all of that to say that I think that ship has sailed for
> 4.5. We are well past feature freeze; and we didn't really have any
> gating functionality. We frankly have very little idea of quality of
> whats in master right now. It's certainly worse than 4.4. So now we'll
> enter code freeze, we'll try and play catch up and fix all of the
> things we discover that are broken. And invariably, we'll be late
> again.
Does it make sense to wait till the 4.4.1 release and either declare code freeze after that or work on these process issues first or in parallel we should do both?
> If you want to solve this problem; my personal belief is that its
> really is tied to CI. Efforts around Travis are interesting and
> perhaps are a piece of that puzzle. Discussions around running CI are
> important as well, but I truly believe that we need a gating function
> that prohibits commits that increase our level of untested code or
> code that fails to pass testing. I've seen some other projects using
> pull requests in github, and then using the github pull request
> builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
We have few projects using code review on Github using pull requests, we can do those or have gerrit. I was successfully able to implement a pull request based code review workflow in my last startup that worked and got adopted only with time so I’ve few things to contribute on this.
Let’s discuss issues around it and try to come up with a solution around it. I’ve few question and challenges to share:
- Should we have github pull request or gerrit code reviews or something else? IMO using Github pull-requests will be most fun, implementing/using that would require least effort and just consensus from the community, PMC and infra folks
- Timeline or window for accepting a review request?
- Having dedicated component specific gurus and maintainers who are there to handling reviews around some ACS piece
- Having people submit smaller patches per branch and what to do if someone’s doing major refactoring or framework stuff that would consume both a lot of time and cannot be submitted as small patches?
- Some reviewers will be more liberal than others, how do we handle the “ego” issues during reviews?
- What if there is no reviewer around a pull request, or people dont’ understand the technology around it and it does not get attention?
- CI is one way to validate a change/review/pull-request, do we have enough infra capacity?
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: 4.5 RM
Posted by Sudha Ponnaganti <su...@citrix.com>.
+1
Also each check in (defect or new feature) should be accompanied by CI based tests as unit tests ( JUNIT tests) seem to be not so popular with CS community. Discussions seem to be moving towards this. But some sort of enforcement is needed at this point. Community has tried all else for past couple of years with slow progress in this area i.e adding automated or unit tests with check ins.
Thanks
/sudha
-----Original Message-----
From: Koushik Das [mailto:koushik.das@citrix.com]
Sent: Wednesday, August 20, 2014 2:05 AM
To: dev@cloudstack.apache.org
Subject: RE: 4.5 RM
I see a lot of discussion on enabling CI. Agree that it is important but CI in itself is not going to solve the quality issue. The other important aspect is the effectiveness of tests that get executed as part of CI. Unless there is a proper set of automated tests (which is kept up-to-date) for each component, no system can ensure quality. This will also ease the review process, every review request should have the test results along with the patch/merge request.
Irrespective of what framework we decide to chose, the quality issue can only be solved by ensuring that automated tests are effective and properly maintained.
-Koushik
-----Original Message-----
From: ilya musayev [mailto:ilya.mailing.lists@gmail.com]
Sent: Wednesday, 20 August 2014 5:22 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.5 RM
David
Since CI has been mentioned several times, do you know where we stand with donated hardware?
Thanks
ilya
On 8/19/14, 10:15 AM, David Nalley wrote:
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues -guarantees that 4.5 will be on
>> time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>>
> So I've been trying to give this some thought. Here's my current line
> of thinking.
>
> The issues with late releases are not a function of our release
> process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points
> that interact with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for
> new features, but the range of options is so large that testing
> everything is a bit difficult. When someone makes a merge request; I
> suspect few people do much looking. Understandable, it's a boring
> task; and really looking doesn't tell us much except for style and
> egregious errors. We've rarely done mandatory testing of feature
> branches before they are merged in. If you want to ship on time, you
> must ensure that we are vociferously guarding the quality of the
> master and release branches; that we can verify programmatically that
> a commit or merge doesn't break things. We must insist on automated
> testing being added.
>
> So I've said all of that to say that I think that ship has sailed for
> 4.5. We are well past feature freeze; and we didn't really have any
> gating functionality. We frankly have very little idea of quality of
> whats in master right now. It's certainly worse than 4.4. So now we'll
> enter code freeze, we'll try and play catch up and fix all of the
> things we discover that are broken. And invariably, we'll be late
> again.
>
> If you want to solve this problem; my personal belief is that its
> really is tied to CI. Efforts around Travis are interesting and
> perhaps are a piece of that puzzle. Discussions around running CI are
> important as well, but I truly believe that we need a gating function
> that prohibits commits that increase our level of untested code or
> code that fails to pass testing. I've seen some other projects using
> pull requests in github, and then using the github pull request
> builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1]
> https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
RE: 4.5 RM
Posted by Koushik Das <ko...@citrix.com>.
I see a lot of discussion on enabling CI. Agree that it is important but CI in itself is not going to solve the quality issue. The other important aspect is the effectiveness of tests that get executed as part of CI. Unless there is a proper set of automated tests (which is kept up-to-date) for each component, no system can ensure quality. This will also ease the review process, every review request should have the test results along with the patch/merge request.
Irrespective of what framework we decide to chose, the quality issue can only be solved by ensuring that automated tests are effective and properly maintained.
-Koushik
-----Original Message-----
From: ilya musayev [mailto:ilya.mailing.lists@gmail.com]
Sent: Wednesday, 20 August 2014 5:22 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.5 RM
David
Since CI has been mentioned several times, do you know where we stand with donated hardware?
Thanks
ilya
On 8/19/14, 10:15 AM, David Nalley wrote:
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues -guarantees that 4.5 will be on
>> time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>>
> So I've been trying to give this some thought. Here's my current line
> of thinking.
>
> The issues with late releases are not a function of our release
> process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points
> that interact with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for
> new features, but the range of options is so large that testing
> everything is a bit difficult. When someone makes a merge request; I
> suspect few people do much looking. Understandable, it's a boring
> task; and really looking doesn't tell us much except for style and
> egregious errors. We've rarely done mandatory testing of feature
> branches before they are merged in. If you want to ship on time, you
> must ensure that we are vociferously guarding the quality of the
> master and release branches; that we can verify programmatically that
> a commit or merge doesn't break things. We must insist on automated
> testing being added.
>
> So I've said all of that to say that I think that ship has sailed for
> 4.5. We are well past feature freeze; and we didn't really have any
> gating functionality. We frankly have very little idea of quality of
> whats in master right now. It's certainly worse than 4.4. So now we'll
> enter code freeze, we'll try and play catch up and fix all of the
> things we discover that are broken. And invariably, we'll be late
> again.
>
> If you want to solve this problem; my personal belief is that its
> really is tied to CI. Efforts around Travis are interesting and
> perhaps are a piece of that puzzle. Discussions around running CI are
> important as well, but I truly believe that we need a gating function
> that prohibits commits that increase our level of untested code or
> code that fails to pass testing. I've seen some other projects using
> pull requests in github, and then using the github pull request
> builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1]
> https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: 4.5 RM
Posted by ilya musayev <il...@gmail.com>.
David
Since CI has been mentioned several times, do you know where we stand
with donated hardware?
Thanks
ilya
On 8/19/14, 10:15 AM, David Nalley wrote:
>> IMHO we should not even release 4.5 until we have a agreed upon:
>>
>> -what our issues are and why we released 4.4 and 4.3 late.
>> -taken action to resolve those issues
>> -guarantees that 4.5 will be on time
>>
>> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>>
> So I've been trying to give this some thought. Here's my current line
> of thinking.
>
> The issues with late releases are not a function of our release
> process per se; but are instead a function of our development process.
> CloudStack is a relatively large codebase. It has a lots of points
> that interact with each other, and it's moderately complex.
> Development moves forward and at least happy-path testing is done for
> new features, but the range of options is so large that testing
> everything is a bit difficult. When someone makes a merge request; I
> suspect few people do much looking. Understandable, it's a boring
> task; and really looking doesn't tell us much except for style and
> egregious errors. We've rarely done mandatory testing of feature
> branches before they are merged in. If you want to ship on time, you
> must ensure that we are vociferously guarding the quality of the
> master and release branches; that we can verify programmatically that
> a commit or merge doesn't break things. We must insist on automated
> testing being added.
>
> So I've said all of that to say that I think that ship has sailed for
> 4.5. We are well past feature freeze; and we didn't really have any
> gating functionality. We frankly have very little idea of quality of
> whats in master right now. It's certainly worse than 4.4. So now we'll
> enter code freeze, we'll try and play catch up and fix all of the
> things we discover that are broken. And invariably, we'll be late
> again.
>
> If you want to solve this problem; my personal belief is that its
> really is tied to CI. Efforts around Travis are interesting and
> perhaps are a piece of that puzzle. Discussions around running CI are
> important as well, but I truly believe that we need a gating function
> that prohibits commits that increase our level of untested code or
> code that fails to pass testing. I've seen some other projects using
> pull requests in github, and then using the github pull request
> builder[1] for jenkins to verify that every PR works. I know we've
> talked about gerrit previously, and perhaps that will work as well.
>
> [1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: 4.5 RM
Posted by David Nalley <da...@gnsa.us>.
>
> IMHO we should not even release 4.5 until we have a agreed upon:
>
> -what our issues are and why we released 4.4 and 4.3 late.
> -taken action to resolve those issues
> -guarantees that 4.5 will be on time
>
> If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>
So I've been trying to give this some thought. Here's my current line
of thinking.
The issues with late releases are not a function of our release
process per se; but are instead a function of our development process.
CloudStack is a relatively large codebase. It has a lots of points
that interact with each other, and it's moderately complex.
Development moves forward and at least happy-path testing is done for
new features, but the range of options is so large that testing
everything is a bit difficult. When someone makes a merge request; I
suspect few people do much looking. Understandable, it's a boring
task; and really looking doesn't tell us much except for style and
egregious errors. We've rarely done mandatory testing of feature
branches before they are merged in. If you want to ship on time, you
must ensure that we are vociferously guarding the quality of the
master and release branches; that we can verify programmatically that
a commit or merge doesn't break things. We must insist on automated
testing being added.
So I've said all of that to say that I think that ship has sailed for
4.5. We are well past feature freeze; and we didn't really have any
gating functionality. We frankly have very little idea of quality of
whats in master right now. It's certainly worse than 4.4. So now we'll
enter code freeze, we'll try and play catch up and fix all of the
things we discover that are broken. And invariably, we'll be late
again.
If you want to solve this problem; my personal belief is that its
really is tied to CI. Efforts around Travis are interesting and
perhaps are a piece of that puzzle. Discussions around running CI are
important as well, but I truly believe that we need a gating function
that prohibits commits that increase our level of untested code or
code that fails to pass testing. I've seen some other projects using
pull requests in github, and then using the github pull request
builder[1] for jenkins to verify that every PR works. I know we've
talked about gerrit previously, and perhaps that will work as well.
[1] https://wiki.cloudbees.com/bin/view/DEV/Github+Pull+Request+Validation
Re: 4.5 RM
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Aug 11, 2014, at 9:24 AM, David Nalley <da...@gnsa.us> wrote:
> Hi folks;
>
> So we haven't had anyone step up to be release manager for 4.5 yet. So
> you consider this either a threat or me volunteering depending on your
> perspective. :)
>
> If no one else steps up by midweek I'm happy to be the RM for 4.5. My
> plan would be to likely hit feature freeze nearly immediately, and
> pick up the schedule from there; but I don't want to distract from
> Daan's 4.4.1 work.
>
> If I do end up taking this on, I'd like to take it as an opportunity
> to figure out/put into practice a good, workable git workflow, so I'll
> probably be asking Rajani, Rohit, and Leo for some
> guidance/suggestions as we move forward.
IMHO we should not even release 4.5 until we have a agreed upon:
-what our issues are and why we released 4.4 and 4.3 late.
-taken action to resolve those issues
-guarantees that 4.5 will be on time
If we don't do that, I don't even know why we are putting ourselves through the pain of a release schedule.
>
> --David
Re: 4.5 RM
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hey David,
On 11-Aug-2014, at 3:24 pm, David Nalley <da...@gnsa.us> wrote:
> Hi folks;
>
> So we haven't had anyone step up to be release manager for 4.5 yet. So
> you consider this either a threat or me volunteering depending on your
> perspective. :)
Awesome, go for it!
> If no one else steps up by midweek I'm happy to be the RM for 4.5. My
> plan would be to likely hit feature freeze nearly immediately, and
> pick up the schedule from there; but I don't want to distract from
> Daan's 4.4.1 work.
>
> If I do end up taking this on, I'd like to take it as an opportunity
> to figure out/put into practice a good, workable git workflow, so I'll
> probably be asking Rajani, Rohit, and Leo for some
> guidance/suggestions as we move forward.
I would like to have all the CloudStack contributor companies and their sponsored developers give their best to help make Apache CloudStack releases more “stable" by testing and better release-participation so when they fork out commercial distributions from opensource ones they’ll have to give less effort in testing/maintaining their commercial distributions.
I guess the git-flow thing is pretty much not what we want “as it is”, and we want to be able to support both opensource and commercial branches. So I started a thread on the "cherry-pick vs merge --ff and getting release branch more participation” workflow which I think would also try to address my above suggestion and that you commit and test on opensource repo/branch first -- which I think no ones has objected till now. I’ll start a voting thread on it soon.
Cheers,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.