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 <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 > >> > >> > >
