cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: 4.6
Date Mon, 22 Jun 2015 13:55:38 GMT

On Jun 22, 2015, at 2:55 PM, Rafael Fonseca <> 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.


> On Mon, Jun 22, 2015 at 2:28 PM, sebgoa <> wrote:
>> On Jun 22, 2015, at 2:21 PM, Rafael Fonseca <> 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 <> 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 <>
>>>>>> On Jun 11, 2015, at 6:43 PM, John Burwell <
>>>> wrote:
>>>>>> All,
>>>>>> Why are we averse to cutting a release stabilization branch?  In
>>>> 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
>>>> 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 <>
>>>>>> Sent: Wednesday, June 10, 2015 6:33 AM
>>>>>> To:
>>>>>> Subject: Re: 4.6
>>>>>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <> 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
>>>> 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
>>>> master, everyone who wants something in 4.6 should submit a PR.
>>>>>>> Regards, Remi
>>>>>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <>
>>>> 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<
>>>>>> CSForge – rapid IaaS deployment framework<
>>>>>> CloudStack Consulting<>
>>>>>> CloudStack Software Engineering<
>>>>>> CloudStack Infrastructure Support<
>>>>>> CloudStack Bootcamp Training Courses<
>>>>>> 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

View raw message