You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Sebastien Goasguen <ru...@gmail.com> on 2015/06/08 21:43:41 UTC
4.6
Folks,
We need to freeze 4.6 asap.
I originally agreed to RM 4.6 and Daan also stepped up.
But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
Anybody wants to jump in.
There is already a ton of things in 4.6 and we need to release.
Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
-sebastien
Re: 4.6
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Sebastien,
> On 08-Jun-2015, at 9:43 pm, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> We need to freeze 4.6 asap.
Good idea. Can you suggest a hard date though, say first week of July? This will buy us some time to merge on-going efforts, review and merge pending PRs and fix critical issues shared on dev MLs.
There are few outstanding issues that I would have wanted in 4.6, but I guess they can be done in 4.7:
- Debian 8 based systemvm template, VR cleanup and improvements
- Replacing openswan with strongswan
- ipv6 support, routed ipv4/ipv6 network support and network refactoring work
> I originally agreed to RM 4.6 and Daan also stepped up.
Can you also share your plan with respect to release schedules once we decide on a freeze date for 4.6? Plans or timelines for 4.7?
If master will be frozen (good idea btw, instead of cutting a separate branch) till 4.6 is released, how should the developer community work on refactoring work and new features?
Also, we will need to fix packaging if we want to support systemd based Debian 8 and Ubuntu 15.04, also improve packaging for CentOS7 and Fedora 21/22.
> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>
> Anybody wants to jump in.
Happy to co-pilot 4.6 release process if needed.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | 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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
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.6
Posted by Rafael Fonseca <rs...@gmail.com>.
You guys can also count on me for whatever help you need to make it happen
smoothly :)
On Mon, Jun 8, 2015 at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
> Hi,
>
> I can jump in and work with Rohit and Daan to make 4.6 happen.
>
> +1 for the QA on master. It would be best if we could then all focus on
> stabilizing 4.6 aka master and wait with refactor stuff and new features
> until 4.6 is out, which is the start of 4.7.
>
> On the other hand, building new features in the mean time isn't a big
> issue, as rebasing to a master that gets more stable every day is much
> easier than it is today I'd say. You just cannot merge new stuff until 4.6
> is out.
>
> Let's write down some guidelines and see if this approach makes sense.
>
> Regards, Remi
>
> > On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
> >
> > Folks,
> >
> > We need to freeze 4.6 asap.
> >
> > I originally agreed to RM 4.6 and Daan also stepped up.
> >
> > But I would like to work on doing a release of ec2stack and gcestack, so
> I will step down from 4.6 RM.
> >
> > Anybody wants to jump in.
> >
> > There is already a ton of things in 4.6 and we need to release.
> >
> > Ideally we also need to QA directly on master, so that we can build 4.7
> on top of a stable release.
> >
> >
> > -sebastien
>
Re: 4.6
Posted by Wido den Hollander <wi...@widodh.nl>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 22-06-15 15:55, sebgoa wrote:
>
> On Jun 22, 2015, at 2:55 PM, Rafael Fonseca <rs...@gmail.com>
> wrote:
>
>> Hi Sebastien, thx for following up so quickly :)
>>
>> It's because it's a big change that i think it should be done in
>> a major release an not a minor,
>
> We all agree on this. Such as change is for a major release.
>
> The question is 4.6 or 4.7 ...
>
To bring this up, if we go for 4.6, then that's OK.
The other discussion is if we move to Java 8 as well.
So Jetty + Java 8 in 4.6?
>
>> nevertheless it will be up to the community to decide if we
>> should ship it in 4.6.0 of wait for a long time to have this in.
>>
>> I've been waiting a long time for that larger discussion, the
>> currently open PR is already the second proposal to improve
>> packaging and the previous one was open for over a month.. so i
>> wonder how long it will take to let everyone take advantage of
>> it, since the code is all ready to ship... if anyone can see a
>> reason or a fix that might not be what they want, i can just
>> amend whatever quickly... but other than the mysql issue, i don't
>> know what would conflict with anyone's interest.. though feel
>> free to show me otherwise :)
>>
>> Like i said on the PR, this is still not all the changes i'd like
>> to make to get a cleaner packaging config, but whatever
>> aesthetical or maintainer helpfulness is still needed to be done,
>> can be done later along the path, while providing the
>> functionality earlier to everyone. Even if we eventually decide
>> to go for a completely different packaging structure like using a
>> proper makefile or something like that, most of the cleanup done
>> in this PR will just make that switch easier ;)
>>
>> For me it will just be a few hours of work to chop it all into
>> pieces and explain what each bit does, so just let me know if i
>> should focus on this straight away or leave it for later and
>> focus on some more needed fixes not related to packaging that
>> everyone should agree to get into releases ASAP.
>>
>
> We need to start testing master (a.k.a) 4.6 , identify blockers
> through testing and see what needs to get fixed. I have not had the
> time to check JIRA, to see if it's already with a 4.6 release and
> if we already have 4.6 blockers.
>
>
>> Looking forward for Pyr's input on this :)
>>
>
> Since he is the one who mentioned this feature, I am hoping he can
> comment soon on it.
>
> -sebastien
>
>>
>> On Mon, Jun 22, 2015 at 2:28 PM, sebgoa <ru...@gmail.com>
>> wrote:
>>
>>>
>>> On Jun 22, 2015, at 2:21 PM, Rafael Fonseca
>>> <rs...@gmail.com> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> I plan on getting started on dissecting the embedded
>>>> Tomcat/Jetty PR this week, it would be nice to get it into
>>>> 4.6.0, since it's quite a change in functional packaging to
>>>> do it in a minor like 4.6.1 (documentation wise
>>> and
>>>> stuff), and i guess 4.7.0 is still far down the road.
>>>
>>> Rafael, let me copy Pierre-Yves who talked about this new
>>> packaging.
>>>
>>> I don't think we should try to put it in 4.6.0, it's too big of
>>> change, and should really be part of a larger discussion on
>>> re-packaging/re-architecture of several things.
>>>
>>> Hopefully Pyr can chime in.
>>>
>>> -sebastien
>>>
>>>> Want to hold off on 4.6.0 until that is chopped to pieces and
>>>> made easy
>>> to
>>>> review? Should be able to do it in a couple of days. I will
>>>> also remove the mysql bit for now so there are no
>>>> conflicting opinions, will revisit that issue further down
>>>> the road.. as someone very well versed in Apache licensing
>>>> explained to me (thanks Leo), we can get that done, just not
>>>> by default and provide a switch to include that functionality
>>>> so that third party rpm/deb distributors (non-Apache) can
>>> use
>>>> that. This will also require some classpath changes based on
>>>> that switch, so will think about it later. Everyone in
>>>> agreement with this? I'm sure quite a few people have been
>>>> waiting on it for sometime, so would be nice to include in
>>>> this release
>>> imo
>>>> :)
>>>>
>>>> Cheers, Rafael
>>>>
>>>> On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen
>>>> <fu...@barred.org> wrote:
>>>>
>>>>> Hi Seb,
>>>>>
>>>>> Great way of wording it, and I completely agree! You should
>>>>> be able to pick up master and roll it out into production
>>>>> and keep running with it!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Funs
>>>>>
>>>>>> On 11 Jun 2015, at 23:43, Sebastien Goasguen
>>>>>> <ru...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Jun 11, 2015, at 6:43 PM, John Burwell
>>>>>>> <john.burwell@shapeblue.com
>>>>
>>>>> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> Why are we averse to cutting a release stabilization
>>>>>>> branch? In the
>>>>> past, we have cut release stabilization branches to ensure
>>>>> that the flow contributions was not interrupted.
>>>>>>
>>>>>> I disagree.
>>>>>>
>>>>>> We have cut branches that way because that’s how Citrix
>>>>>> delivers
>>>>> software. It develops on master, cuts a branch and put a QA
>>>>> team to
>>> work to
>>>>> stabilize and make a release.
>>>>>>
>>>>>> I believe it’s a broken model for an open source
>>>>>> community made of
>>>>> mostly volunteers. We don’t have the luxury to QA a release
>>>>> branch and loose that effort (because it does not go back
>>>>> to master).
>>>>>>
>>>>>> In addition, this process has led to many regression,
>>>>>> because there
>>>>> is/was a disconnect between the Qa team and the guys
>>>>> developing on
>>> master.
>>>>> Plus bad practice when bugs gets fixed. i.e we fix a bug in
>>>>> a release branch but don’t port it in master.
>>>>>>
>>>>>> That’s why we have talked about this at length for almost
>>>>>> a year now,
>>>>> alas without resolution ( I thought we had, but your email
>>>>> indicates otherwise, too bad you did not chime in
>>>>> earlier).
>>>>>>
>>>>>> I am advocating for us to stabilize master and gate
>>>>>> master. So that
>>>>> whenever we release we can do it starting from a stabilized
>>>>> branch.
>>> Instead
>>>>> of having to reinvest time in lengthy QA.
>>>>>>
>>>>>> I want us to be able to release at anytime, when we feel
>>>>>> like it and as
>>>>> soon as someone says I want this fix/feature that was just
>>>>> merged in master. Right no we cannot do that.
>>>>>>
>>>>>> So yes call me crazy, I want the developers to take it
>>>>>> onto themselves
>>>>> to keep their forks in sync with master, develop on their
>>>>> fork. And I
>>> want
>>>>> master to be the release branch. We will be able to build
>>>>> up a release through PR from devs with limited merge
>>>>> conflicts. So that we reach a
>>> point
>>>>> where master is QA at all time and we don’t loose any
>>>>> investment made
>>> in QA.
>>>>>>
>>>>>>
>>>>>>> For committers, it is not a big deal since they can
>>>>>>> manage their
>>>>> branches in the cloudstack repo. However, for
>>>>> non-committers, this
>>> freeze
>>>>> could cause unnecessary frustration and discourage further
>>> contributions.
>>>>>>
>>>>>> A freeze means only the RMs will commit on master. any PR
>>>>>> from anyone
>>>>> welcome and let the discussions happen on whether to merge
>>>>> or not…no frustration.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks, -John
>>>>>>>
>>>>>>> ________________________________________ From: sebgoa
>>>>>>> <ru...@gmail.com> Sent: Wednesday, June 10, 2015 6:33
>>>>>>> AM To: dev@cloudstack.apache.org Subject: Re: 4.6
>>>>>>>
>>>>>>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma
>>>>>>> <re...@remi.nl> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I can jump in and work with Rohit and Daan to make
>>>>>>>> 4.6 happen.
>>>>>>>>
>>>>>>>> +1 for the QA on master. It would be best if we could
>>>>>>>> then all focus
>>>>> on stabilizing 4.6 aka master and wait with refactor stuff
>>>>> and new
>>> features
>>>>> until 4.6 is out, which is the start of 4.7.
>>>>>>>>
>>>>>>>> On the other hand, building new features in the mean
>>>>>>>> time isn't a big
>>>>> issue, as rebasing to a master that gets more stable every
>>>>> day is much easier than it is today I'd say. You just
>>>>> cannot merge new stuff until
>>> 4.6
>>>>> is out.
>>>>>>>>
>>>>>>>> Let's write down some guidelines and see if this
>>>>>>>> approach makes
>>> sense.
>>>>>>>>
>>>>>>>
>>>>>>> Maybe that's something that you can do at the meetup
>>>>>>> today and bring
>>> it
>>>>> back to the list as a proposal ?
>>>>>>>
>>>>>>> When I talk about freeze I am thinking just letting the
>>>>>>> RMs commit on
>>>>> master, everyone who wants something in 4.6 should submit a
>>>>> PR.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Regards, Remi
>>>>>>>>
>>>>>>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen
>>>>>>>>> <ru...@gmail.com>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Folks,
>>>>>>>>>
>>>>>>>>> We need to freeze 4.6 asap.
>>>>>>>>>
>>>>>>>>> I originally agreed to RM 4.6 and Daan also stepped
>>>>>>>>> up.
>>>>>>>>>
>>>>>>>>> But I would like to work on doing a release of
>>>>>>>>> ec2stack and
>>> gcestack,
>>>>> so I will step down from 4.6 RM.
>>>>>>>>>
>>>>>>>>> Anybody wants to jump in.
>>>>>>>>>
>>>>>>>>> There is already a ton of things in 4.6 and we need
>>>>>>>>> to release.
>>>>>>>>>
>>>>>>>>> Ideally we also need to QA directly on master, so
>>>>>>>>> that we can build
>>>>> 4.7 on top of a stable release.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -sebastien
>>>>>>> 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 Software Engineering<
>>>>> http://shapeblue.com/cloudstack-software-engineering/>
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> — =Funs
>>>>>
>>>>>
>>>
>>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVp7HMAAoJEAGbWC3bPspCvMMP/RICpwu6osUykIlAe7FE9Q1r
OYUXhuMV0zr5BDOr9EFE+I7WJFDcA5E2TmybNJYUfe3r9v8LEvViXdKjV86IxZFO
J/r4Glr9Il07ujiOV6VgS++E1Xp2KCTMr1urpaNrgTpYvfIq8IewGsS2+Q69rvX1
TPs7O7hju4Ws63Z4bhMa16B2jAbi04McSrtMZnsVTYuD8FknHfveEupN1qWy4in2
hAIi5ijb7XBtEW1yLm6K4up+Xpw2OG/D3fZA42QQLNx5QyV2ZjVF0OWAvw9pEiI5
UFbFOrtlY5C4706bohVadN8tZCYJhNxWmhmWW2vI9E/c1P1RECu5nr0TmUDLTdXR
SOzDkL1ooL2oo0AN0EXC4YKaPM5MHCrK2OUQXXrjsyHCWQ4dJ/Vpb5fsxfYLaEbf
C3oHBoVkjINFl4buN/qa8O3/AuSSCzejchM0iCOtlaW9kCil+Yv4lEBquO4AKX2d
W5eOXkWbEDGGl7auoy/+9BcbSiKt10DEDequ+sLm+2L1wWXXB4dUgCRWYKxKNoNB
PF+tSxbkmgIAhr9jsEL1vVs4H5mQqWvhlyvzikYW9xCRiQqWZFHbB5vyjnfFwxb/
bdt6f1VMsH7mDsm3nI4YzNMH/Vr8CFhJGtOcfF9HEUc9xvM7LKGY5hWev5/2Iigx
rD6C1FwtTfogEIzkrb7I
=QoBz
-----END PGP SIGNATURE-----
Re: 4.6
Posted by sebgoa <ru...@gmail.com>.
On Jun 22, 2015, at 2:55 PM, Rafael Fonseca <rs...@gmail.com> wrote:
> Hi Sebastien, thx for following up so quickly :)
>
> It's because it's a big change that i think it should be done in a major
> release an not a minor,
We all agree on this. Such as change is for a major release.
The question is 4.6 or 4.7 ...
> nevertheless it will be up to the community to
> decide if we should ship it in 4.6.0 of wait for a long time to have this
> in.
>
> I've been waiting a long time for that larger discussion, the currently
> open PR is already the second proposal to improve packaging and the
> previous one was open for over a month.. so i wonder how long it will take
> to let everyone take advantage of it, since the code is all ready to
> ship... if anyone can see a reason or a fix that might not be what they
> want, i can just amend whatever quickly... but other than the mysql issue,
> i don't know what would conflict with anyone's interest.. though feel free
> to show me otherwise :)
>
> Like i said on the PR, this is still not all the changes i'd like to make
> to get a cleaner packaging config, but whatever aesthetical or maintainer
> helpfulness is still needed to be done, can be done later along the path,
> while providing the functionality earlier to everyone. Even if we
> eventually decide to go for a completely different packaging structure like
> using a proper makefile or something like that, most of the cleanup done in
> this PR will just make that switch easier ;)
>
> For me it will just be a few hours of work to chop it all into pieces and
> explain what each bit does, so just let me know if i should focus on this
> straight away or leave it for later and focus on some more needed fixes not
> related to packaging that everyone should agree to get into releases ASAP.
>
We need to start testing master (a.k.a) 4.6 , identify blockers through testing and see what needs to get fixed.
I have not had the time to check JIRA, to see if it's already with a 4.6 release and if we already have 4.6 blockers.
> Looking forward for Pyr's input on this :)
>
Since he is the one who mentioned this feature, I am hoping he can comment soon on it.
-sebastien
>
> On Mon, Jun 22, 2015 at 2:28 PM, sebgoa <ru...@gmail.com> wrote:
>
>>
>> On Jun 22, 2015, at 2:21 PM, Rafael Fonseca <rs...@gmail.com> wrote:
>>
>>> Hi guys,
>>>
>>> I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
>>> week, it would be nice to get it into 4.6.0, since it's quite a change in
>>> functional packaging to do it in a minor like 4.6.1 (documentation wise
>> and
>>> stuff), and i guess 4.7.0 is still far down the road.
>>
>> Rafael, let me copy Pierre-Yves who talked about this new packaging.
>>
>> I don't think we should try to put it in 4.6.0, it's too big of change,
>> and should really be part of a larger discussion on
>> re-packaging/re-architecture of several things.
>>
>> Hopefully Pyr can chime in.
>>
>> -sebastien
>>
>>> Want to hold off on 4.6.0 until that is chopped to pieces and made easy
>> to
>>> review? Should be able to do it in a couple of days.
>>> I will also remove the mysql bit for now so there are no conflicting
>>> opinions, will revisit that issue further down the road.. as someone very
>>> well versed in Apache licensing explained to me (thanks Leo), we can get
>>> that done, just not by default and provide a switch to include that
>>> functionality so that third party rpm/deb distributors (non-Apache) can
>> use
>>> that. This will also require some classpath changes based on that switch,
>>> so will think about it later.
>>> Everyone in agreement with this? I'm sure quite a few people have been
>>> waiting on it for sometime, so would be nice to include in this release
>> imo
>>> :)
>>>
>>> Cheers,
>>> Rafael
>>>
>>> On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen <fu...@barred.org> wrote:
>>>
>>>> Hi Seb,
>>>>
>>>> Great way of wording it, and I completely agree! You should be able to
>>>> pick up master and roll it out into production and keep running with it!
>>>>
>>>> Cheers,
>>>>
>>>> Funs
>>>>
>>>>> On 11 Jun 2015, at 23:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>> On Jun 11, 2015, at 6:43 PM, John Burwell <john.burwell@shapeblue.com
>>>
>>>> wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> Why are we averse to cutting a release stabilization branch? In the
>>>> past, we have cut release stabilization branches to ensure that the flow
>>>> contributions was not interrupted.
>>>>>
>>>>> I disagree.
>>>>>
>>>>> We have cut branches that way because that’s how Citrix delivers
>>>> software. It develops on master, cuts a branch and put a QA team to
>> work to
>>>> stabilize and make a release.
>>>>>
>>>>> I believe it’s a broken model for an open source community made of
>>>> mostly volunteers. We don’t have the luxury to QA a release branch and
>>>> loose that effort (because it does not go back to master).
>>>>>
>>>>> In addition, this process has led to many regression, because there
>>>> is/was a disconnect between the Qa team and the guys developing on
>> master.
>>>> Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
>>>> branch but don’t port it in master.
>>>>>
>>>>> That’s why we have talked about this at length for almost a year now,
>>>> alas without resolution ( I thought we had, but your email indicates
>>>> otherwise, too bad you did not chime in earlier).
>>>>>
>>>>> I am advocating for us to stabilize master and gate master. So that
>>>> whenever we release we can do it starting from a stabilized branch.
>> Instead
>>>> of having to reinvest time in lengthy QA.
>>>>>
>>>>> I want us to be able to release at anytime, when we feel like it and as
>>>> soon as someone says I want this fix/feature that was just merged in
>>>> master. Right no we cannot do that.
>>>>>
>>>>> So yes call me crazy, I want the developers to take it onto themselves
>>>> to keep their forks in sync with master, develop on their fork. And I
>> want
>>>> master to be the release branch. We will be able to build up a release
>>>> through PR from devs with limited merge conflicts. So that we reach a
>> point
>>>> where master is QA at all time and we don’t loose any investment made
>> in QA.
>>>>>
>>>>>
>>>>>> For committers, it is not a big deal since they can manage their
>>>> branches in the cloudstack repo. However, for non-committers, this
>> freeze
>>>> could cause unnecessary frustration and discourage further
>> contributions.
>>>>>
>>>>> A freeze means only the RMs will commit on master. any PR from anyone
>>>> welcome and let the discussions happen on whether to merge or not…no
>>>> frustration.
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> -John
>>>>>>
>>>>>> ________________________________________
>>>>>> From: sebgoa <ru...@gmail.com>
>>>>>> Sent: Wednesday, June 10, 2015 6:33 AM
>>>>>> To: dev@cloudstack.apache.org
>>>>>> Subject: Re: 4.6
>>>>>>
>>>>>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I can jump in and work with Rohit and Daan to make 4.6 happen.
>>>>>>>
>>>>>>> +1 for the QA on master. It would be best if we could then all focus
>>>> on stabilizing 4.6 aka master and wait with refactor stuff and new
>> features
>>>> until 4.6 is out, which is the start of 4.7.
>>>>>>>
>>>>>>> On the other hand, building new features in the mean time isn't a big
>>>> issue, as rebasing to a master that gets more stable every day is much
>>>> easier than it is today I'd say. You just cannot merge new stuff until
>> 4.6
>>>> is out.
>>>>>>>
>>>>>>> Let's write down some guidelines and see if this approach makes
>> sense.
>>>>>>>
>>>>>>
>>>>>> Maybe that's something that you can do at the meetup today and bring
>> it
>>>> back to the list as a proposal ?
>>>>>>
>>>>>> When I talk about freeze I am thinking just letting the RMs commit on
>>>> master, everyone who wants something in 4.6 should submit a PR.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Regards, Remi
>>>>>>>
>>>>>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>>>
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> We need to freeze 4.6 asap.
>>>>>>>>
>>>>>>>> I originally agreed to RM 4.6 and Daan also stepped up.
>>>>>>>>
>>>>>>>> But I would like to work on doing a release of ec2stack and
>> gcestack,
>>>> so I will step down from 4.6 RM.
>>>>>>>>
>>>>>>>> Anybody wants to jump in.
>>>>>>>>
>>>>>>>> There is already a ton of things in 4.6 and we need to release.
>>>>>>>>
>>>>>>>> Ideally we also need to QA directly on master, so that we can build
>>>> 4.7 on top of a stable release.
>>>>>>>>
>>>>>>>>
>>>>>>>> -sebastien
>>>>>> 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 Software Engineering<
>>>> http://shapeblue.com/cloudstack-software-engineering/>
>>>>>> 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.
>>>>>
>>>>
>>>> —
>>>> =Funs
>>>>
>>>>
>>
>>
Re: 4.6
Posted by Rafael Fonseca <rs...@gmail.com>.
Hi Sebastien, thx for following up so quickly :)
It's because it's a big change that i think it should be done in a major
release an not a minor, nevertheless it will be up to the community to
decide if we should ship it in 4.6.0 of wait for a long time to have this
in.
I've been waiting a long time for that larger discussion, the currently
open PR is already the second proposal to improve packaging and the
previous one was open for over a month.. so i wonder how long it will take
to let everyone take advantage of it, since the code is all ready to
ship... if anyone can see a reason or a fix that might not be what they
want, i can just amend whatever quickly... but other than the mysql issue,
i don't know what would conflict with anyone's interest.. though feel free
to show me otherwise :)
Like i said on the PR, this is still not all the changes i'd like to make
to get a cleaner packaging config, but whatever aesthetical or maintainer
helpfulness is still needed to be done, can be done later along the path,
while providing the functionality earlier to everyone. Even if we
eventually decide to go for a completely different packaging structure like
using a proper makefile or something like that, most of the cleanup done in
this PR will just make that switch easier ;)
For me it will just be a few hours of work to chop it all into pieces and
explain what each bit does, so just let me know if i should focus on this
straight away or leave it for later and focus on some more needed fixes not
related to packaging that everyone should agree to get into releases ASAP.
Looking forward for Pyr's input on this :)
On Mon, Jun 22, 2015 at 2:28 PM, sebgoa <ru...@gmail.com> wrote:
>
> On Jun 22, 2015, at 2:21 PM, Rafael Fonseca <rs...@gmail.com> wrote:
>
> > Hi guys,
> >
> > I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
> > week, it would be nice to get it into 4.6.0, since it's quite a change in
> > functional packaging to do it in a minor like 4.6.1 (documentation wise
> and
> > stuff), and i guess 4.7.0 is still far down the road.
>
> Rafael, let me copy Pierre-Yves who talked about this new packaging.
>
> I don't think we should try to put it in 4.6.0, it's too big of change,
> and should really be part of a larger discussion on
> re-packaging/re-architecture of several things.
>
> Hopefully Pyr can chime in.
>
> -sebastien
>
> > Want to hold off on 4.6.0 until that is chopped to pieces and made easy
> to
> > review? Should be able to do it in a couple of days.
> > I will also remove the mysql bit for now so there are no conflicting
> > opinions, will revisit that issue further down the road.. as someone very
> > well versed in Apache licensing explained to me (thanks Leo), we can get
> > that done, just not by default and provide a switch to include that
> > functionality so that third party rpm/deb distributors (non-Apache) can
> use
> > that. This will also require some classpath changes based on that switch,
> > so will think about it later.
> > Everyone in agreement with this? I'm sure quite a few people have been
> > waiting on it for sometime, so would be nice to include in this release
> imo
> > :)
> >
> > Cheers,
> > Rafael
> >
> > On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen <fu...@barred.org> wrote:
> >
> >> Hi Seb,
> >>
> >> Great way of wording it, and I completely agree! You should be able to
> >> pick up master and roll it out into production and keep running with it!
> >>
> >> Cheers,
> >>
> >> Funs
> >>
> >>> On 11 Jun 2015, at 23:43, Sebastien Goasguen <ru...@gmail.com> wrote:
> >>>
> >>>
> >>>> On Jun 11, 2015, at 6:43 PM, John Burwell <john.burwell@shapeblue.com
> >
> >> wrote:
> >>>>
> >>>> All,
> >>>>
> >>>> Why are we averse to cutting a release stabilization branch? In the
> >> past, we have cut release stabilization branches to ensure that the flow
> >> contributions was not interrupted.
> >>>
> >>> I disagree.
> >>>
> >>> We have cut branches that way because that’s how Citrix delivers
> >> software. It develops on master, cuts a branch and put a QA team to
> work to
> >> stabilize and make a release.
> >>>
> >>> I believe it’s a broken model for an open source community made of
> >> mostly volunteers. We don’t have the luxury to QA a release branch and
> >> loose that effort (because it does not go back to master).
> >>>
> >>> In addition, this process has led to many regression, because there
> >> is/was a disconnect between the Qa team and the guys developing on
> master.
> >> Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
> >> branch but don’t port it in master.
> >>>
> >>> That’s why we have talked about this at length for almost a year now,
> >> alas without resolution ( I thought we had, but your email indicates
> >> otherwise, too bad you did not chime in earlier).
> >>>
> >>> I am advocating for us to stabilize master and gate master. So that
> >> whenever we release we can do it starting from a stabilized branch.
> Instead
> >> of having to reinvest time in lengthy QA.
> >>>
> >>> I want us to be able to release at anytime, when we feel like it and as
> >> soon as someone says I want this fix/feature that was just merged in
> >> master. Right no we cannot do that.
> >>>
> >>> So yes call me crazy, I want the developers to take it onto themselves
> >> to keep their forks in sync with master, develop on their fork. And I
> want
> >> master to be the release branch. We will be able to build up a release
> >> through PR from devs with limited merge conflicts. So that we reach a
> point
> >> where master is QA at all time and we don’t loose any investment made
> in QA.
> >>>
> >>>
> >>>> For committers, it is not a big deal since they can manage their
> >> branches in the cloudstack repo. However, for non-committers, this
> freeze
> >> could cause unnecessary frustration and discourage further
> contributions.
> >>>
> >>> A freeze means only the RMs will commit on master. any PR from anyone
> >> welcome and let the discussions happen on whether to merge or not…no
> >> frustration.
> >>>
> >>>
> >>>>
> >>>> Thanks,
> >>>> -John
> >>>>
> >>>> ________________________________________
> >>>> From: sebgoa <ru...@gmail.com>
> >>>> Sent: Wednesday, June 10, 2015 6:33 AM
> >>>> To: dev@cloudstack.apache.org
> >>>> Subject: Re: 4.6
> >>>>
> >>>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I can jump in and work with Rohit and Daan to make 4.6 happen.
> >>>>>
> >>>>> +1 for the QA on master. It would be best if we could then all focus
> >> on stabilizing 4.6 aka master and wait with refactor stuff and new
> features
> >> until 4.6 is out, which is the start of 4.7.
> >>>>>
> >>>>> On the other hand, building new features in the mean time isn't a big
> >> issue, as rebasing to a master that gets more stable every day is much
> >> easier than it is today I'd say. You just cannot merge new stuff until
> 4.6
> >> is out.
> >>>>>
> >>>>> Let's write down some guidelines and see if this approach makes
> sense.
> >>>>>
> >>>>
> >>>> Maybe that's something that you can do at the meetup today and bring
> it
> >> back to the list as a proposal ?
> >>>>
> >>>> When I talk about freeze I am thinking just letting the RMs commit on
> >> master, everyone who wants something in 4.6 should submit a PR.
> >>>>
> >>>>
> >>>>
> >>>>> Regards, Remi
> >>>>>
> >>>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com>
> >> wrote:
> >>>>>>
> >>>>>> Folks,
> >>>>>>
> >>>>>> We need to freeze 4.6 asap.
> >>>>>>
> >>>>>> I originally agreed to RM 4.6 and Daan also stepped up.
> >>>>>>
> >>>>>> But I would like to work on doing a release of ec2stack and
> gcestack,
> >> so I will step down from 4.6 RM.
> >>>>>>
> >>>>>> Anybody wants to jump in.
> >>>>>>
> >>>>>> There is already a ton of things in 4.6 and we need to release.
> >>>>>>
> >>>>>> Ideally we also need to QA directly on master, so that we can build
> >> 4.7 on top of a stable release.
> >>>>>>
> >>>>>>
> >>>>>> -sebastien
> >>>> 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 Software Engineering<
> >> http://shapeblue.com/cloudstack-software-engineering/>
> >>>> 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.
> >>>
> >>
> >> —
> >> =Funs
> >>
> >>
>
>
Re: 4.6
Posted by sebgoa <ru...@gmail.com>.
On Jun 22, 2015, at 2:21 PM, Rafael Fonseca <rs...@gmail.com> wrote:
> Hi guys,
>
> I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
> week, it would be nice to get it into 4.6.0, since it's quite a change in
> functional packaging to do it in a minor like 4.6.1 (documentation wise and
> stuff), and i guess 4.7.0 is still far down the road.
Rafael, let me copy Pierre-Yves who talked about this new packaging.
I don't think we should try to put it in 4.6.0, it's too big of change, and should really be part of a larger discussion on re-packaging/re-architecture of several things.
Hopefully Pyr can chime in.
-sebastien
> Want to hold off on 4.6.0 until that is chopped to pieces and made easy to
> review? Should be able to do it in a couple of days.
> I will also remove the mysql bit for now so there are no conflicting
> opinions, will revisit that issue further down the road.. as someone very
> well versed in Apache licensing explained to me (thanks Leo), we can get
> that done, just not by default and provide a switch to include that
> functionality so that third party rpm/deb distributors (non-Apache) can use
> that. This will also require some classpath changes based on that switch,
> so will think about it later.
> Everyone in agreement with this? I'm sure quite a few people have been
> waiting on it for sometime, so would be nice to include in this release imo
> :)
>
> Cheers,
> Rafael
>
> On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen <fu...@barred.org> wrote:
>
>> Hi Seb,
>>
>> Great way of wording it, and I completely agree! You should be able to
>> pick up master and roll it out into production and keep running with it!
>>
>> Cheers,
>>
>> Funs
>>
>>> On 11 Jun 2015, at 23:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>
>>>
>>>> On Jun 11, 2015, at 6:43 PM, John Burwell <jo...@shapeblue.com>
>> wrote:
>>>>
>>>> All,
>>>>
>>>> Why are we averse to cutting a release stabilization branch? In the
>> past, we have cut release stabilization branches to ensure that the flow
>> contributions was not interrupted.
>>>
>>> I disagree.
>>>
>>> We have cut branches that way because that’s how Citrix delivers
>> software. It develops on master, cuts a branch and put a QA team to work to
>> stabilize and make a release.
>>>
>>> I believe it’s a broken model for an open source community made of
>> mostly volunteers. We don’t have the luxury to QA a release branch and
>> loose that effort (because it does not go back to master).
>>>
>>> In addition, this process has led to many regression, because there
>> is/was a disconnect between the Qa team and the guys developing on master.
>> Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
>> branch but don’t port it in master.
>>>
>>> That’s why we have talked about this at length for almost a year now,
>> alas without resolution ( I thought we had, but your email indicates
>> otherwise, too bad you did not chime in earlier).
>>>
>>> I am advocating for us to stabilize master and gate master. So that
>> whenever we release we can do it starting from a stabilized branch. Instead
>> of having to reinvest time in lengthy QA.
>>>
>>> I want us to be able to release at anytime, when we feel like it and as
>> soon as someone says I want this fix/feature that was just merged in
>> master. Right no we cannot do that.
>>>
>>> So yes call me crazy, I want the developers to take it onto themselves
>> to keep their forks in sync with master, develop on their fork. And I want
>> master to be the release branch. We will be able to build up a release
>> through PR from devs with limited merge conflicts. So that we reach a point
>> where master is QA at all time and we don’t loose any investment made in QA.
>>>
>>>
>>>> For committers, it is not a big deal since they can manage their
>> branches in the cloudstack repo. However, for non-committers, this freeze
>> could cause unnecessary frustration and discourage further contributions.
>>>
>>> A freeze means only the RMs will commit on master. any PR from anyone
>> welcome and let the discussions happen on whether to merge or not…no
>> frustration.
>>>
>>>
>>>>
>>>> Thanks,
>>>> -John
>>>>
>>>> ________________________________________
>>>> From: sebgoa <ru...@gmail.com>
>>>> Sent: Wednesday, June 10, 2015 6:33 AM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: 4.6
>>>>
>>>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I can jump in and work with Rohit and Daan to make 4.6 happen.
>>>>>
>>>>> +1 for the QA on master. It would be best if we could then all focus
>> on stabilizing 4.6 aka master and wait with refactor stuff and new features
>> until 4.6 is out, which is the start of 4.7.
>>>>>
>>>>> On the other hand, building new features in the mean time isn't a big
>> issue, as rebasing to a master that gets more stable every day is much
>> easier than it is today I'd say. You just cannot merge new stuff until 4.6
>> is out.
>>>>>
>>>>> Let's write down some guidelines and see if this approach makes sense.
>>>>>
>>>>
>>>> Maybe that's something that you can do at the meetup today and bring it
>> back to the list as a proposal ?
>>>>
>>>> When I talk about freeze I am thinking just letting the RMs commit on
>> master, everyone who wants something in 4.6 should submit a PR.
>>>>
>>>>
>>>>
>>>>> Regards, Remi
>>>>>
>>>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> We need to freeze 4.6 asap.
>>>>>>
>>>>>> I originally agreed to RM 4.6 and Daan also stepped up.
>>>>>>
>>>>>> But I would like to work on doing a release of ec2stack and gcestack,
>> so I will step down from 4.6 RM.
>>>>>>
>>>>>> Anybody wants to jump in.
>>>>>>
>>>>>> There is already a ton of things in 4.6 and we need to release.
>>>>>>
>>>>>> Ideally we also need to QA directly on master, so that we can build
>> 4.7 on top of a stable release.
>>>>>>
>>>>>>
>>>>>> -sebastien
>>>> 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 Software Engineering<
>> http://shapeblue.com/cloudstack-software-engineering/>
>>>> 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.
>>>
>>
>> —
>> =Funs
>>
>>
Re: 4.6
Posted by Rafael Fonseca <rs...@gmail.com>.
Hi guys,
I plan on getting started on dissecting the embedded Tomcat/Jetty PR this
week, it would be nice to get it into 4.6.0, since it's quite a change in
functional packaging to do it in a minor like 4.6.1 (documentation wise and
stuff), and i guess 4.7.0 is still far down the road.
Want to hold off on 4.6.0 until that is chopped to pieces and made easy to
review? Should be able to do it in a couple of days.
I will also remove the mysql bit for now so there are no conflicting
opinions, will revisit that issue further down the road.. as someone very
well versed in Apache licensing explained to me (thanks Leo), we can get
that done, just not by default and provide a switch to include that
functionality so that third party rpm/deb distributors (non-Apache) can use
that. This will also require some classpath changes based on that switch,
so will think about it later.
Everyone in agreement with this? I'm sure quite a few people have been
waiting on it for sometime, so would be nice to include in this release imo
:)
Cheers,
Rafael
On Fri, Jun 12, 2015 at 2:10 PM, Funs Kessen <fu...@barred.org> wrote:
> Hi Seb,
>
> Great way of wording it, and I completely agree! You should be able to
> pick up master and roll it out into production and keep running with it!
>
> Cheers,
>
> Funs
>
> > On 11 Jun 2015, at 23:43, Sebastien Goasguen <ru...@gmail.com> wrote:
> >
> >
> >> On Jun 11, 2015, at 6:43 PM, John Burwell <jo...@shapeblue.com>
> wrote:
> >>
> >> All,
> >>
> >> Why are we averse to cutting a release stabilization branch? In the
> past, we have cut release stabilization branches to ensure that the flow
> contributions was not interrupted.
> >
> > I disagree.
> >
> > We have cut branches that way because that’s how Citrix delivers
> software. It develops on master, cuts a branch and put a QA team to work to
> stabilize and make a release.
> >
> > I believe it’s a broken model for an open source community made of
> mostly volunteers. We don’t have the luxury to QA a release branch and
> loose that effort (because it does not go back to master).
> >
> > In addition, this process has led to many regression, because there
> is/was a disconnect between the Qa team and the guys developing on master.
> Plus bad practice when bugs gets fixed. i.e we fix a bug in a release
> branch but don’t port it in master.
> >
> > That’s why we have talked about this at length for almost a year now,
> alas without resolution ( I thought we had, but your email indicates
> otherwise, too bad you did not chime in earlier).
> >
> > I am advocating for us to stabilize master and gate master. So that
> whenever we release we can do it starting from a stabilized branch. Instead
> of having to reinvest time in lengthy QA.
> >
> > I want us to be able to release at anytime, when we feel like it and as
> soon as someone says I want this fix/feature that was just merged in
> master. Right no we cannot do that.
> >
> > So yes call me crazy, I want the developers to take it onto themselves
> to keep their forks in sync with master, develop on their fork. And I want
> master to be the release branch. We will be able to build up a release
> through PR from devs with limited merge conflicts. So that we reach a point
> where master is QA at all time and we don’t loose any investment made in QA.
> >
> >
> >> For committers, it is not a big deal since they can manage their
> branches in the cloudstack repo. However, for non-committers, this freeze
> could cause unnecessary frustration and discourage further contributions.
> >
> > A freeze means only the RMs will commit on master. any PR from anyone
> welcome and let the discussions happen on whether to merge or not…no
> frustration.
> >
> >
> >>
> >> Thanks,
> >> -John
> >>
> >> ________________________________________
> >> From: sebgoa <ru...@gmail.com>
> >> Sent: Wednesday, June 10, 2015 6:33 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: 4.6
> >>
> >> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
> >>
> >>> Hi,
> >>>
> >>> I can jump in and work with Rohit and Daan to make 4.6 happen.
> >>>
> >>> +1 for the QA on master. It would be best if we could then all focus
> on stabilizing 4.6 aka master and wait with refactor stuff and new features
> until 4.6 is out, which is the start of 4.7.
> >>>
> >>> On the other hand, building new features in the mean time isn't a big
> issue, as rebasing to a master that gets more stable every day is much
> easier than it is today I'd say. You just cannot merge new stuff until 4.6
> is out.
> >>>
> >>> Let's write down some guidelines and see if this approach makes sense.
> >>>
> >>
> >> Maybe that's something that you can do at the meetup today and bring it
> back to the list as a proposal ?
> >>
> >> When I talk about freeze I am thinking just letting the RMs commit on
> master, everyone who wants something in 4.6 should submit a PR.
> >>
> >>
> >>
> >>> Regards, Remi
> >>>
> >>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>>>
> >>>> Folks,
> >>>>
> >>>> We need to freeze 4.6 asap.
> >>>>
> >>>> I originally agreed to RM 4.6 and Daan also stepped up.
> >>>>
> >>>> But I would like to work on doing a release of ec2stack and gcestack,
> so I will step down from 4.6 RM.
> >>>>
> >>>> Anybody wants to jump in.
> >>>>
> >>>> There is already a ton of things in 4.6 and we need to release.
> >>>>
> >>>> Ideally we also need to QA directly on master, so that we can build
> 4.7 on top of a stable release.
> >>>>
> >>>>
> >>>> -sebastien
> >> 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 Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> >> 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.
> >
>
> —
> =Funs
>
>
Re: 4.6
Posted by Funs Kessen <fu...@barred.org>.
Hi Seb,
Great way of wording it, and I completely agree! You should be able to pick up master and roll it out into production and keep running with it!
Cheers,
Funs
> On 11 Jun 2015, at 23:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>
>> On Jun 11, 2015, at 6:43 PM, John Burwell <jo...@shapeblue.com> wrote:
>>
>> All,
>>
>> Why are we averse to cutting a release stabilization branch? In the past, we have cut release stabilization branches to ensure that the flow contributions was not interrupted.
>
> I disagree.
>
> We have cut branches that way because that’s how Citrix delivers software. It develops on master, cuts a branch and put a QA team to work to stabilize and make a release.
>
> I believe it’s a broken model for an open source community made of mostly volunteers. We don’t have the luxury to QA a release branch and loose that effort (because it does not go back to master).
>
> In addition, this process has led to many regression, because there is/was a disconnect between the Qa team and the guys developing on master. Plus bad practice when bugs gets fixed. i.e we fix a bug in a release branch but don’t port it in master.
>
> That’s why we have talked about this at length for almost a year now, alas without resolution ( I thought we had, but your email indicates otherwise, too bad you did not chime in earlier).
>
> I am advocating for us to stabilize master and gate master. So that whenever we release we can do it starting from a stabilized branch. Instead of having to reinvest time in lengthy QA.
>
> I want us to be able to release at anytime, when we feel like it and as soon as someone says I want this fix/feature that was just merged in master. Right no we cannot do that.
>
> So yes call me crazy, I want the developers to take it onto themselves to keep their forks in sync with master, develop on their fork. And I want master to be the release branch. We will be able to build up a release through PR from devs with limited merge conflicts. So that we reach a point where master is QA at all time and we don’t loose any investment made in QA.
>
>
>> For committers, it is not a big deal since they can manage their branches in the cloudstack repo. However, for non-committers, this freeze could cause unnecessary frustration and discourage further contributions.
>
> A freeze means only the RMs will commit on master. any PR from anyone welcome and let the discussions happen on whether to merge or not…no frustration.
>
>
>>
>> Thanks,
>> -John
>>
>> ________________________________________
>> From: sebgoa <ru...@gmail.com>
>> Sent: Wednesday, June 10, 2015 6:33 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.6
>>
>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
>>
>>> Hi,
>>>
>>> I can jump in and work with Rohit and Daan to make 4.6 happen.
>>>
>>> +1 for the QA on master. It would be best if we could then all focus on stabilizing 4.6 aka master and wait with refactor stuff and new features until 4.6 is out, which is the start of 4.7.
>>>
>>> On the other hand, building new features in the mean time isn't a big issue, as rebasing to a master that gets more stable every day is much easier than it is today I'd say. You just cannot merge new stuff until 4.6 is out.
>>>
>>> Let's write down some guidelines and see if this approach makes sense.
>>>
>>
>> Maybe that's something that you can do at the meetup today and bring it back to the list as a proposal ?
>>
>> When I talk about freeze I am thinking just letting the RMs commit on master, everyone who wants something in 4.6 should submit a PR.
>>
>>
>>
>>> Regards, Remi
>>>
>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>> We need to freeze 4.6 asap.
>>>>
>>>> I originally agreed to RM 4.6 and Daan also stepped up.
>>>>
>>>> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>>>>
>>>> Anybody wants to jump in.
>>>>
>>>> There is already a ton of things in 4.6 and we need to release.
>>>>
>>>> Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
>>>>
>>>>
>>>> -sebastien
>> 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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
>> 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.
>
—
=Funs
Re: 4.6
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On Jun 11, 2015, at 6:43 PM, John Burwell <jo...@shapeblue.com> wrote:
>
> All,
>
> Why are we averse to cutting a release stabilization branch? In the past, we have cut release stabilization branches to ensure that the flow contributions was not interrupted.
I disagree.
We have cut branches that way because that’s how Citrix delivers software. It develops on master, cuts a branch and put a QA team to work to stabilize and make a release.
I believe it’s a broken model for an open source community made of mostly volunteers. We don’t have the luxury to QA a release branch and loose that effort (because it does not go back to master).
In addition, this process has led to many regression, because there is/was a disconnect between the Qa team and the guys developing on master. Plus bad practice when bugs gets fixed. i.e we fix a bug in a release branch but don’t port it in master.
That’s why we have talked about this at length for almost a year now, alas without resolution ( I thought we had, but your email indicates otherwise, too bad you did not chime in earlier).
I am advocating for us to stabilize master and gate master. So that whenever we release we can do it starting from a stabilized branch. Instead of having to reinvest time in lengthy QA.
I want us to be able to release at anytime, when we feel like it and as soon as someone says I want this fix/feature that was just merged in master. Right no we cannot do that.
So yes call me crazy, I want the developers to take it onto themselves to keep their forks in sync with master, develop on their fork. And I want master to be the release branch. We will be able to build up a release through PR from devs with limited merge conflicts. So that we reach a point where master is QA at all time and we don’t loose any investment made in QA.
> For committers, it is not a big deal since they can manage their branches in the cloudstack repo. However, for non-committers, this freeze could cause unnecessary frustration and discourage further contributions.
A freeze means only the RMs will commit on master. any PR from anyone welcome and let the discussions happen on whether to merge or not…no frustration.
>
> Thanks,
> -John
>
> ________________________________________
> From: sebgoa <ru...@gmail.com>
> Sent: Wednesday, June 10, 2015 6:33 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.6
>
> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
>
>> Hi,
>>
>> I can jump in and work with Rohit and Daan to make 4.6 happen.
>>
>> +1 for the QA on master. It would be best if we could then all focus on stabilizing 4.6 aka master and wait with refactor stuff and new features until 4.6 is out, which is the start of 4.7.
>>
>> On the other hand, building new features in the mean time isn't a big issue, as rebasing to a master that gets more stable every day is much easier than it is today I'd say. You just cannot merge new stuff until 4.6 is out.
>>
>> Let's write down some guidelines and see if this approach makes sense.
>>
>
> Maybe that's something that you can do at the meetup today and bring it back to the list as a proposal ?
>
> When I talk about freeze I am thinking just letting the RMs commit on master, everyone who wants something in 4.6 should submit a PR.
>
>
>
>> Regards, Remi
>>
>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>>
>>> Folks,
>>>
>>> We need to freeze 4.6 asap.
>>>
>>> I originally agreed to RM 4.6 and Daan also stepped up.
>>>
>>> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>>>
>>> Anybody wants to jump in.
>>>
>>> There is already a ton of things in 4.6 and we need to release.
>>>
>>> Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
>>>
>>>
>>> -sebastien
> 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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
> 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.6
Posted by John Burwell <jo...@shapeblue.com>.
All,
Why are we averse to cutting a release stabilization branch? In the past, we have cut release stabilization branches to ensure that the flow contributions was not interrupted. For committers, it is not a big deal since they can manage their branches in the cloudstack repo. However, for non-committers, this freeze could cause unnecessary frustration and discourage further contributions.
Thanks,
-John
________________________________________
From: sebgoa <ru...@gmail.com>
Sent: Wednesday, June 10, 2015 6:33 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.6
On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
> Hi,
>
> I can jump in and work with Rohit and Daan to make 4.6 happen.
>
> +1 for the QA on master. It would be best if we could then all focus on stabilizing 4.6 aka master and wait with refactor stuff and new features until 4.6 is out, which is the start of 4.7.
>
> On the other hand, building new features in the mean time isn't a big issue, as rebasing to a master that gets more stable every day is much easier than it is today I'd say. You just cannot merge new stuff until 4.6 is out.
>
> Let's write down some guidelines and see if this approach makes sense.
>
Maybe that's something that you can do at the meetup today and bring it back to the list as a proposal ?
When I talk about freeze I am thinking just letting the RMs commit on master, everyone who wants something in 4.6 should submit a PR.
> Regards, Remi
>
>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>> Folks,
>>
>> We need to freeze 4.6 asap.
>>
>> I originally agreed to RM 4.6 and Daan also stepped up.
>>
>> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>>
>> Anybody wants to jump in.
>>
>> There is already a ton of things in 4.6 and we need to release.
>>
>> Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
>>
>>
>> -sebastien
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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/>
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.6
Posted by sebgoa <ru...@gmail.com>.
On Jun 8, 2015, at 11:45 PM, Remi Bergsma <re...@remi.nl> wrote:
> Hi,
>
> I can jump in and work with Rohit and Daan to make 4.6 happen.
>
> +1 for the QA on master. It would be best if we could then all focus on stabilizing 4.6 aka master and wait with refactor stuff and new features until 4.6 is out, which is the start of 4.7.
>
> On the other hand, building new features in the mean time isn't a big issue, as rebasing to a master that gets more stable every day is much easier than it is today I'd say. You just cannot merge new stuff until 4.6 is out.
>
> Let's write down some guidelines and see if this approach makes sense.
>
Maybe that's something that you can do at the meetup today and bring it back to the list as a proposal ?
When I talk about freeze I am thinking just letting the RMs commit on master, everyone who wants something in 4.6 should submit a PR.
> Regards, Remi
>
>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>> Folks,
>>
>> We need to freeze 4.6 asap.
>>
>> I originally agreed to RM 4.6 and Daan also stepped up.
>>
>> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>>
>> Anybody wants to jump in.
>>
>> There is already a ton of things in 4.6 and we need to release.
>>
>> Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
>>
>>
>> -sebastien
Re: 4.6
Posted by Remi Bergsma <re...@remi.nl>.
Hi,
I can jump in and work with Rohit and Daan to make 4.6 happen.
+1 for the QA on master. It would be best if we could then all focus on stabilizing 4.6 aka master and wait with refactor stuff and new features until 4.6 is out, which is the start of 4.7.
On the other hand, building new features in the mean time isn't a big issue, as rebasing to a master that gets more stable every day is much easier than it is today I'd say. You just cannot merge new stuff until 4.6 is out.
Let's write down some guidelines and see if this approach makes sense.
Regards, Remi
> On 08 Jun 2015, at 21:43, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> Folks,
>
> We need to freeze 4.6 asap.
>
> I originally agreed to RM 4.6 and Daan also stepped up.
>
> But I would like to work on doing a release of ec2stack and gcestack, so I will step down from 4.6 RM.
>
> Anybody wants to jump in.
>
> There is already a ton of things in 4.6 and we need to release.
>
> Ideally we also need to QA directly on master, so that we can build 4.7 on top of a stable release.
>
>
> -sebastien
Re: 4.6
Posted by Rene Moser <ma...@renemoser.net>.
Hi Seb
On 08.06.2015 21:43, Sebastien Goasguen wrote:
> We need to freeze 4.6 asap.
Oh boy, you are way too fast :)
How many days will I have to finish
https://github.com/apache/cloudstack/pull/264 ?
And a more serious issue: The changes made in
https://issues.apache.org/jira/browse/CLOUDSTACK-7994 are IMHO still in
the master branch, this would be a blocker for us. Also see
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201506.mbox/%3C2D22E663-AFC2-4292-B16A-F6C2FCA0C217%40shapeblue.com%3E
I created a ticket https://issues.apache.org/jira/browse/CLOUDSTACK-8545
Yours
René