On Jun 22, 2015, at 2:21 PM, Rafael Fonseca <rsafons...@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 <f...@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 <run...@gmail.com> wrote: >>> >>> >>>> On Jun 11, 2015, at 6:43 PM, John Burwell <john.burw...@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 <run...@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 <r...@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 <run...@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 >> >>
