-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22-06-15 15:55, sebgoa wrote: > > On Jun 22, 2015, at 2:55 PM, Rafael Fonseca <rsafons...@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 <run...@gmail.com> >> wrote: >> >>> >>> 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 >>>>> >>>>> >>> >>> > -----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-----
