You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Pierre-Luc Dion <pd...@cloudops.com> on 2015/04/17 00:49:20 UTC
[DISCUSS] 4.6 release management
Today during the CloudStackdays we did a round table about Release
management targeting the next 4.6 releases.
Quick bullet point discussions:
ideas to change release planning
- Plugin contribution is complicated because often a new plugin involve
change on the core:
- ex: storage plugin involve changes on Hypervisor code
- There is an idea of going on a 2 weeks release model which could
introduce issue the database schema.
- Database schema version should be different then the application
version.
- There is a will to enforce git workflow in 4.6 and trigger simulator
job on PullRequest.
- Some people (I'm part of them) are concerned on our current way of
supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
4.5.x). But the current level of confidence against latest release is low,
so that need to be improved.
So, the main messages is that w'd like to improve the release velocity, and
release branch stability. so we would like to propose few change in the
way we would add code to the 4.6 branch as follow:
- All new contribution to 4.6 would be thru Pull Request or merge request,
which would trigger a simulator job, ideally only if that pass the PR would
be accepted and automatically merged. At this time, I think we pretty much
have everything in place to do that. At a first step we would use
simulator+marvin jobs then improve tests coverage from there.
Please comments :-)
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
On Apr 22, 2015, at 12:24 PM, Raja Pullela <ra...@citrix.com> wrote:
> Sebastien, I am taking about the tests we have under "test/integration/smoke" folder.
> Not sure how the tests run through Travis, will try to understand.
> These are tests were run on a local cloudstack env.
>
Just catching up and making sure I reply to Raja here.
Travis (https://travis-ci.org) runs those tests, by building cloudstack and running the simulator.
All the travis setup is defined in the travis.yml file in the root of the repo.
This setup can probably be improved.
Do note that if you fork on your own github, pushes to your own branch will run through Travis as well.
> best,
> Raja
> -----Original Message-----
> From: Sebastien Goasguen [mailto:runseb@gmail.com]
> Sent: Friday, April 17, 2015 1:14 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
>
>
>> On Apr 17, 2015, at 6:26 AM, Raja Pullela <ra...@citrix.com> wrote:
>>
>> +1 for the "Some people (I'm part of them) are concerned on our current way of supporting and back porting fixes to multiple release"
>> This should be a top priority along with keeping master stable - make sure BVTs are passing at 100% all the time.
>
> Raja, which BVT are you talking about ? AFAIK, all current tests run on all commits through Travis.
>
>> Also if we can plan/target increasing test/BVT coverage, that will be super!
>>
>> Thanks,
>> Raja
>> -----Original Message-----
>> From: Marcus [mailto:shadowsor@gmail.com]
>> Sent: Friday, April 17, 2015 4:35 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] 4.6 release management
>>
>> "storage plugin involve changes on Hypervisor code"
>>
>> I know this is just an example, but at least on KVM side this is no longer true. Previously you had to implement a KVM-specific 'StorageAdaptor' that would run on the hypervisor, and register that with the agent code, but Mike and I added some reflection/annotation that allows for auto-detection of the adaptor upon Agent start up, so storage plugins can be completely self-contained now. They don't even have to be a part of our code base.
>>
>> There may be other parts of the code where we can do similar things to decouple if we can identify those points. Ideally, if someone has to modify core code to add their plugin it should only be because they are adding some new functionality *that core cloudstack needs to be aware of*, and that functionality should be added in a way that other plugins can also provide/implement it. Otherwise, they can always add new APIs specific to their appliance or product and leveraging data from cloudstack's db, all via plugin. They can add new global/zone/cluster configs and UI tools via plugin as well.
>>
>> On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>> Today during the CloudStackdays we did a round table about Release
>>> management targeting the next 4.6 releases.
>>>
>>>
>>> Quick bullet point discussions:
>>>
>>> ideas to change release planning
>>>
>>> - Plugin contribution is complicated because often a new plugin involve
>>> change on the core:
>>> - ex: storage plugin involve changes on Hypervisor code
>>> - There is an idea of going on a 2 weeks release model which could
>>> introduce issue the database schema.
>>> - Database schema version should be different then the application
>>> version.
>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>> job on PullRequest.
>>> - Some people (I'm part of them) are concerned on our current way of
>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>> 4.5.x). But the current level of confidence against latest release is low,
>>> so that need to be improved.
>>>
>>>
>>> So, the main messages is that w'd like to improve the release
>>> velocity, and release branch stability. so we would like to propose
>>> few change in the way we would add code to the 4.6 branch as follow:
>>>
>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request, which would trigger a simulator job, ideally only if that
>>> pass the PR would be accepted and automatically merged. At this
>>> time, I think we pretty much have everything in place to do that. At
>>> a first step we would use
>>> simulator+marvin jobs then improve tests coverage from there.
>>>
>>> Please comments :-)
>
RE: [DISCUSS] 4.6 release management
Posted by Raja Pullela <ra...@citrix.com>.
Sebastien, I am taking about the tests we have under "test/integration/smoke" folder.
Not sure how the tests run through Travis, will try to understand.
These are tests were run on a local cloudstack env.
best,
Raja
-----Original Message-----
From: Sebastien Goasguen [mailto:runseb@gmail.com]
Sent: Friday, April 17, 2015 1:14 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
> On Apr 17, 2015, at 6:26 AM, Raja Pullela <ra...@citrix.com> wrote:
>
> +1 for the "Some people (I'm part of them) are concerned on our current way of supporting and back porting fixes to multiple release"
> This should be a top priority along with keeping master stable - make sure BVTs are passing at 100% all the time.
Raja, which BVT are you talking about ? AFAIK, all current tests run on all commits through Travis.
> Also if we can plan/target increasing test/BVT coverage, that will be super!
>
> Thanks,
> Raja
> -----Original Message-----
> From: Marcus [mailto:shadowsor@gmail.com]
> Sent: Friday, April 17, 2015 4:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
>
> "storage plugin involve changes on Hypervisor code"
>
> I know this is just an example, but at least on KVM side this is no longer true. Previously you had to implement a KVM-specific 'StorageAdaptor' that would run on the hypervisor, and register that with the agent code, but Mike and I added some reflection/annotation that allows for auto-detection of the adaptor upon Agent start up, so storage plugins can be completely self-contained now. They don't even have to be a part of our code base.
>
> There may be other parts of the code where we can do similar things to decouple if we can identify those points. Ideally, if someone has to modify core code to add their plugin it should only be because they are adding some new functionality *that core cloudstack needs to be aware of*, and that functionality should be added in a way that other plugins can also provide/implement it. Otherwise, they can always add new APIs specific to their appliance or product and leveraging data from cloudstack's db, all via plugin. They can add new global/zone/cluster configs and UI tools via plugin as well.
>
> On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>> - Plugin contribution is complicated because often a new plugin involve
>> change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>> - There is an idea of going on a 2 weeks release model which could
>> introduce issue the database schema.
>> - Database schema version should be different then the application
>> version.
>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>> job on PullRequest.
>> - Some people (I'm part of them) are concerned on our current way of
>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>> 4.5.x). But the current level of confidence against latest release is low,
>> so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release
>> velocity, and release branch stability. so we would like to propose
>> few change in the way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge
>> request, which would trigger a simulator job, ideally only if that
>> pass the PR would be accepted and automatically merged. At this
>> time, I think we pretty much have everything in place to do that. At
>> a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>>
>> Please comments :-)
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On Apr 17, 2015, at 6:26 AM, Raja Pullela <ra...@citrix.com> wrote:
>
> +1 for the "Some people (I'm part of them) are concerned on our current way of supporting and back porting fixes to multiple release"
> This should be a top priority along with keeping master stable - make sure BVTs are passing at 100% all the time.
Raja, which BVT are you talking about ? AFAIK, all current tests run on all commits through Travis.
> Also if we can plan/target increasing test/BVT coverage, that will be super!
>
> Thanks,
> Raja
> -----Original Message-----
> From: Marcus [mailto:shadowsor@gmail.com]
> Sent: Friday, April 17, 2015 4:35 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] 4.6 release management
>
> "storage plugin involve changes on Hypervisor code"
>
> I know this is just an example, but at least on KVM side this is no longer true. Previously you had to implement a KVM-specific 'StorageAdaptor' that would run on the hypervisor, and register that with the agent code, but Mike and I added some reflection/annotation that allows for auto-detection of the adaptor upon Agent start up, so storage plugins can be completely self-contained now. They don't even have to be a part of our code base.
>
> There may be other parts of the code where we can do similar things to decouple if we can identify those points. Ideally, if someone has to modify core code to add their plugin it should only be because they are adding some new functionality *that core cloudstack needs to be aware of*, and that functionality should be added in a way that other plugins can also provide/implement it. Otherwise, they can always add new APIs specific to their appliance or product and leveraging data from cloudstack's db, all via plugin. They can add new global/zone/cluster configs and UI tools via plugin as well.
>
> On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>> - Plugin contribution is complicated because often a new plugin involve
>> change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>> - There is an idea of going on a 2 weeks release model which could
>> introduce issue the database schema.
>> - Database schema version should be different then the application
>> version.
>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>> job on PullRequest.
>> - Some people (I'm part of them) are concerned on our current way of
>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>> 4.5.x). But the current level of confidence against latest release is low,
>> so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release
>> velocity, and release branch stability. so we would like to propose
>> few change in the way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge
>> request, which would trigger a simulator job, ideally only if that
>> pass the PR would be accepted and automatically merged. At this time,
>> I think we pretty much have everything in place to do that. At a first
>> step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>>
>> Please comments :-)
RE: [DISCUSS] 4.6 release management
Posted by Raja Pullela <ra...@citrix.com>.
+1 for the "Some people (I'm part of them) are concerned on our current way of supporting and back porting fixes to multiple release"
This should be a top priority along with keeping master stable - make sure BVTs are passing at 100% all the time.
Also if we can plan/target increasing test/BVT coverage, that will be super!
Thanks,
Raja
-----Original Message-----
From: Marcus [mailto:shadowsor@gmail.com]
Sent: Friday, April 17, 2015 4:35 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] 4.6 release management
"storage plugin involve changes on Hypervisor code"
I know this is just an example, but at least on KVM side this is no longer true. Previously you had to implement a KVM-specific 'StorageAdaptor' that would run on the hypervisor, and register that with the agent code, but Mike and I added some reflection/annotation that allows for auto-detection of the adaptor upon Agent start up, so storage plugins can be completely self-contained now. They don't even have to be a part of our code base.
There may be other parts of the code where we can do similar things to decouple if we can identify those points. Ideally, if someone has to modify core code to add their plugin it should only be because they are adding some new functionality *that core cloudstack needs to be aware of*, and that functionality should be added in a way that other plugins can also provide/implement it. Otherwise, they can always add new APIs specific to their appliance or product and leveraging data from cloudstack's db, all via plugin. They can add new global/zone/cluster configs and UI tools via plugin as well.
On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated because often a new plugin involve
> change on the core:
> - ex: storage plugin involve changes on Hypervisor code
> - There is an idea of going on a 2 weeks release model which could
> introduce issue the database schema.
> - Database schema version should be different then the application
> version.
> - There is a will to enforce git workflow in 4.6 and trigger simulator
> job on PullRequest.
> - Some people (I'm part of them) are concerned on our current way of
> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
> 4.5.x). But the current level of confidence against latest release is low,
> so that need to be improved.
>
>
> So, the main messages is that w'd like to improve the release
> velocity, and release branch stability. so we would like to propose
> few change in the way we would add code to the 4.6 branch as follow:
>
> - All new contribution to 4.6 would be thru Pull Request or merge
> request, which would trigger a simulator job, ideally only if that
> pass the PR would be accepted and automatically merged. At this time,
> I think we pretty much have everything in place to do that. At a first
> step we would use
> simulator+marvin jobs then improve tests coverage from there.
>
> Please comments :-)
Re: [DISCUSS] 4.6 release management
Posted by Marcus <sh...@gmail.com>.
"storage plugin involve changes on Hypervisor code"
I know this is just an example, but at least on KVM side this is no
longer true. Previously you had to implement a KVM-specific
'StorageAdaptor' that would run on the hypervisor, and register that
with the agent code, but Mike and I added some reflection/annotation
that allows for auto-detection of the adaptor upon Agent start up, so
storage plugins can be completely self-contained now. They don't even
have to be a part of our code base.
There may be other parts of the code where we can do similar things to
decouple if we can identify those points. Ideally, if someone has to
modify core code to add their plugin it should only be because they
are adding some new functionality *that core cloudstack needs to be
aware of*, and that functionality should be added in a way that other
plugins can also provide/implement it. Otherwise, they can always add
new APIs specific to their appliance or product and leveraging data
from cloudstack's db, all via plugin. They can add new
global/zone/cluster configs and UI tools via plugin as well.
On Thu, Apr 16, 2015 at 3:49 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated because often a new plugin involve
> change on the core:
> - ex: storage plugin involve changes on Hypervisor code
> - There is an idea of going on a 2 weeks release model which could
> introduce issue the database schema.
> - Database schema version should be different then the application
> version.
> - There is a will to enforce git workflow in 4.6 and trigger simulator
> job on PullRequest.
> - Some people (I'm part of them) are concerned on our current way of
> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
> 4.5.x). But the current level of confidence against latest release is low,
> so that need to be improved.
>
>
> So, the main messages is that w'd like to improve the release velocity, and
> release branch stability. so we would like to propose few change in the
> way we would add code to the 4.6 branch as follow:
>
> - All new contribution to 4.6 would be thru Pull Request or merge request,
> which would trigger a simulator job, ideally only if that pass the PR would
> be accepted and automatically merged. At this time, I think we pretty much
> have everything in place to do that. At a first step we would use
> simulator+marvin jobs then improve tests coverage from there.
>
> Please comments :-)
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
On Fri, Apr 24, 2015 at 4:53 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> Daan,
>
>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>
>> Rohit, the issues you mention are not as painful if we release in a
>> two week schedule as the period of creating a fix to seeing it in a
>> release will be shorter. Some releases will be broken for some people,
>> I don't think we can prevent this. The target we are aiming for is to
>> big to cover it completely.
>
> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>
> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
Fred Neubauer, a Schuberg Philis colleague has just finished creating
a bubble for testing and development purposes. It looks really good.
We are underway to create a new style jenkins slave in which multiple
hypervisors, management servers and db servers can be created. Sounds
like you are at the same point then.
All that we are discussing here is of varying distance in the future.
Let's not forget this in the discussion. In the end ideal would be
continuous delivery for all cloudstack installs;)
>
>> Your points are valid, though.
>> .1 a three person release team makes sense. I have been really happy
>> with the help I got from Pierre-Luc and I think David can do with help
>> the coming time as well.
>> .2 Hopefully people won't need to test every release so extensively
>> anymore as the changes become smaller. (and my initial remark the
>> above applies as well)
>
> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
Database upgrades need fixing. When we think on this all relevant
scenarios need to be considdered; slow following users, bleeding edge
users and developers. LTS in combination with forward merging of fixes
seems to be the way to me. (as often said, not just by me;)
--
Daan
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
yes, you do :)
Op vr 1 mei 2015 om 05:00 schreef Abhinandan Prateek <
abhinandan.prateek@shapeblue.com>:
> Guys,
>
> Do I see a QACloud in works, something in line with devcloud but with a
> bigger collection of Hypervisors + marvin ?
> If we can bundle these Hypervisors and QA automation then effectively we
> can have many more people join our QA effort.
>
> > On 29-Apr-2015, at 9:24 pm, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> >
> > Hi Remi,
> >
> > Thanks. Sure we can work together on this, I guess you would be running
> KVM/XenServer on KVM. Ping me if you need help on running ESX 5.x on KVM as
> it requires a patched qemu system binary (prebuilt debs here
> http://people.apache.org/~bhaisaab/qemu). If these nested hosts are
> managed by CloudStack itself instead of virsh or virt-viewer, then use ACS
> 4.5 or master.
> >
> >> On 29-Apr-2015, at 5:21 pm, Remi Bergsma <RB...@schubergphilis.com>
> wrote:
> >>
> >> Hi Rohit,
> >>
> >> Nice work!
> >>
> >> I agree we need an environment that does run on something else than the
> local machine, as we need more horse power. We worked on something similar,
> where we have a cluster of KVM controlled by CloudStack in our Employee
> Cloud and spin large VMs running CentOS 7.1 (we use 32 or 64GB ram). In
> this big VM we run KVM again and spin up all infrastructure, ranging from
> hypervisors, SDN controllers, database hosts, storage appliances, etc. The
> big benefit is that networking is easy, as it is all in one box. Also,
> everybody uses the same prefixes. Using a L2 VPN we connect the
> workstations to the dev/test environment. All VMs can be controlled using
> virt-manager (like you also showed) and it is actually CloudStack running
> inside CloudStack. Deploying this VM has been automated and we’re now
> working on automating different scenario’s. They can also be used as
> Jenkins build slaves, for example. It is work in progress.
> >>
> >> Long story short: Let's work together on this :-)
> >>
> >> Regards,
> >> Remi
> >>
> >>
> >>> On 28 Apr 2015, at 21:07, Rohit Yadav <ro...@shapeblue.com>
> wrote:
> >>>
> >>> Hi Ilya,
> >>>
> >>> In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV
> etc) on KVM you need to;
> >>>
> >>> - use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64,
> I’m waiting for Fedora 22 to test it on F22 as well), you may install the
> pre-built debs or build/install qemu from source using the patch from here:
> people.apache.org/~bhaisaab/qemu
> >>> - use ACS using latest 4.5 branch and deploy a basic zone (without SG)
> to provision hypervisor hosts as user vms
> >>> - in agent.properties (on your kvm host), enable
> guest.cpu.features=vmx and guest.cpu.mode=host-passthrough
> >>> - when deploying ESX 5.x on vm (or installing using an ISO) deploy
> virtualmachine with details nicAdapter=vmxnet3, for other hypervisors
> (including ESX 6.0) E1000, the default nic adapter, works
> >>>
> >>> IMO this is a better approach as it does not depend on ESX or VMWare
> fusion that requires special hardware (vCenter/Windows etc or OSX/Apple
> machine) and are difficult to automate. Working with KVM host, since is a
> Linux machine, would be more familiar to sysadmins and certainly a pleasure
> to scale and work with because one can avoid management tools (such as
> XenCenter or vCenter).
> >>>
> >>> (I’m still working on the "CloudStack Developer Kit” {CDK} so it’s not
> in a state to be released yet, will avoid publishing a faulty tool now.
> Instead of the DevCloud approach which promotes everything on one machine,
> the CDK I’m trying to build focuses on developer productivity,
> reproducibility and scalability of a QA lab, it recommends at least one
> companion hardware with a developer’s workstation/laptop which can be a
> small-form-factor server like a mini PC or NUC with at least 16GB RAM and 4
> cores i7 with Intel VT. Hope to share it soon.)
> >>>
> >>>> On 28-Apr-2015, at 7:17 pm, ilya <il...@gmail.com>
> wrote:
> >>>>
> >>>> Rohit
> >>>>
> >>>> Any headway on ESX 5.5? I've done this many times before using
> cloudstack and esx, but i was using esx as parent hypervisor.
> >>>>
> >>>> The challenge for me was being able to automatically deploy and
> configure the vSphere + ESXi env. I managed to get the whole flow working
> with bash script, puppet, VMA and while it works its not pretty. The
> challenge was the networking bit.
> >>>>
> >>>> Last but not least, consider using cloudstack to test cloudstack.
> i.e. master env, would use cloudstack projects and spinup smaller envs with
> KVM, Xen and VmWare bound to each project.
> >>>>
> >>>> Regards
> >>>> ilya
> >>>>
> >>>> On 4/24/15 7:53 AM, Rohit Yadav wrote:
> >>>>> Daan,
> >>>>>
> >>>>>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Rohit, the issues you mention are not as painful if we release in a
> >>>>>> two week schedule as the period of creating a fix to seeing it in a
> >>>>>> release will be shorter. Some releases will be broken for some
> people,
> >>>>>> I don't think we can prevent this. The target we are aiming for is
> to
> >>>>>> big to cover it completely.
> >>>>> I agree with you, but I think there are pros and cons to both
> approaches and for this to work it needs to be able to walk first before it
> can run.
> >>>>>
> >>>>> For this to work we need an automated QA system, to solve this Abhi
> is working on it for past few weeks and will be adding more non-hardware
> tests (simulator ones) to travis. In my free time, I’m trying to setup a
> nested virtualized environment where we can test ACS against Xen, KVM and
> VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on
> top of KVM with vmx (intel-vt) enabled, and making some progress with
> running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x
> which is something I’m exploring). I hope we'll have something working soon
> that is fairly fast and easy to reproduce.
> >>>>>
> >>>>>> Your points are valid, though.
> >>>>>> .1 a three person release team makes sense. I have been really happy
> >>>>>> with the help I got from Pierre-Luc and I think David can do with
> help
> >>>>>> the coming time as well.
> >>>>>> .2 Hopefully people won't need to test every release so extensively
> >>>>>> anymore as the changes become smaller. (and my initial remark the
> >>>>>> above applies as well)
> >>>>> By having too many releases we’ll have to deal with too many upgrade
> path issues and users will spread across different versions which will
> create an issue for maintainers who are supporting users -- one solution
> for this problem can be that we introduce a concept of LTS release that is
> either maintained by the community (which can be difficult) or some
> interested stakeholders, for users that would prefer upgrading everytime
> there is a new CloudStack release.
> >>>>>
> >>>>>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <
> rohit.yadav@shapeblue.com> wrote:
> >>>>>>> I think we need to have a faster release management to speed up
> process in general, and for that I propose that we have at least two
> co-pilots for the release manager who would support them with things like
> reviewing/merging patches, creating RC candidates etc whenever necessary.
> Having only one person as a release manager can become a bottleneck for a
> speedy release.
> >>>>>>>
> >>>>>>> The other issue is getting people to test a (release) branch, fix
> bugs and expect a review/result in 72 hours. This has usually failed if
> people are busy and not getting enough time for this. As an example, I
> think 4.5 is delayed because it lacked people actively testing it or fixing
> issues, or when issues were found only around the RC testing period which
> delayed RC voting by 1-2 weeks every time that happened. (I’ll post details
> about where I think we are wrt 4.5 in another thread).
> >>>>>>>
> >>>>>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
> >>>>>>>>
> >>>>>>>> Today during the CloudStackdays we did a round table about
> Release
> >>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Quick bullet point discussions:
> >>>>>>>>
> >>>>>>>> ideas to change release planning
> >>>>>>>>
> >>>>>>>> - Plugin contribution is complicated because often a new plugin
> involve
> >>>>>>>> change on the core:
> >>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>> - There is an idea of going on a 2 weeks release model which could
> >>>>>>>> introduce issue the database schema.
> >>>>>>>> - Database schema version should be different then the application
> >>>>>>>> version.
> >>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
> simulator
> >>>>>>>> job on PullRequest.
> >>>>>>>> - Some people (I'm part of them) are concerned on our current way
> of
> >>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
> 4.4.x,
> >>>>>>>> 4.5.x). But the current level of confidence against latest
> release is low,
> >>>>>>>> so that need to be improved.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So, the main messages is that w'd like to improve the release
> velocity, and
> >>>>>>>> release branch stability. so we would like to propose few change
> in the
> >>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>
> >>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
> request,
> >>>>>>>> which would trigger a simulator job, ideally only if that pass
> the PR would
> >>>>>>>> be accepted and automatically merged. At this time, I think we
> pretty much
> >>>>>>>> have everything in place to do that. At a first step we would use
> >>>>>>>> simulator+marvin jobs then improve tests coverage from there.
> >>>>>>>>
> >>>>>>>> Please comments :-)
> >>>>>>> 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.
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daan
> >>>>> 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.
> >>>>
> >>>>
> >>>
> >>> 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.
> >>
> >
> > 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.
>
> 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: [DISCUSS] 4.6 release management
Posted by Abhinandan Prateek <ab...@shapeblue.com>.
Guys,
Do I see a QACloud in works, something in line with devcloud but with a bigger collection of Hypervisors + marvin ?
If we can bundle these Hypervisors and QA automation then effectively we can have many more people join our QA effort.
> On 29-Apr-2015, at 9:24 pm, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> Hi Remi,
>
> Thanks. Sure we can work together on this, I guess you would be running KVM/XenServer on KVM. Ping me if you need help on running ESX 5.x on KVM as it requires a patched qemu system binary (prebuilt debs here http://people.apache.org/~bhaisaab/qemu). If these nested hosts are managed by CloudStack itself instead of virsh or virt-viewer, then use ACS 4.5 or master.
>
>> On 29-Apr-2015, at 5:21 pm, Remi Bergsma <RB...@schubergphilis.com> wrote:
>>
>> Hi Rohit,
>>
>> Nice work!
>>
>> I agree we need an environment that does run on something else than the local machine, as we need more horse power. We worked on something similar, where we have a cluster of KVM controlled by CloudStack in our Employee Cloud and spin large VMs running CentOS 7.1 (we use 32 or 64GB ram). In this big VM we run KVM again and spin up all infrastructure, ranging from hypervisors, SDN controllers, database hosts, storage appliances, etc. The big benefit is that networking is easy, as it is all in one box. Also, everybody uses the same prefixes. Using a L2 VPN we connect the workstations to the dev/test environment. All VMs can be controlled using virt-manager (like you also showed) and it is actually CloudStack running inside CloudStack. Deploying this VM has been automated and we’re now working on automating different scenario’s. They can also be used as Jenkins build slaves, for example. It is work in progress.
>>
>> Long story short: Let's work together on this :-)
>>
>> Regards,
>> Remi
>>
>>
>>> On 28 Apr 2015, at 21:07, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>
>>> Hi Ilya,
>>>
>>> In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM you need to;
>>>
>>> - use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m waiting for Fedora 22 to test it on F22 as well), you may install the pre-built debs or build/install qemu from source using the patch from here: people.apache.org/~bhaisaab/qemu
>>> - use ACS using latest 4.5 branch and deploy a basic zone (without SG) to provision hypervisor hosts as user vms
>>> - in agent.properties (on your kvm host), enable guest.cpu.features=vmx and guest.cpu.mode=host-passthrough
>>> - when deploying ESX 5.x on vm (or installing using an ISO) deploy virtualmachine with details nicAdapter=vmxnet3, for other hypervisors (including ESX 6.0) E1000, the default nic adapter, works
>>>
>>> IMO this is a better approach as it does not depend on ESX or VMWare fusion that requires special hardware (vCenter/Windows etc or OSX/Apple machine) and are difficult to automate. Working with KVM host, since is a Linux machine, would be more familiar to sysadmins and certainly a pleasure to scale and work with because one can avoid management tools (such as XenCenter or vCenter).
>>>
>>> (I’m still working on the "CloudStack Developer Kit” {CDK} so it’s not in a state to be released yet, will avoid publishing a faulty tool now. Instead of the DevCloud approach which promotes everything on one machine, the CDK I’m trying to build focuses on developer productivity, reproducibility and scalability of a QA lab, it recommends at least one companion hardware with a developer’s workstation/laptop which can be a small-form-factor server like a mini PC or NUC with at least 16GB RAM and 4 cores i7 with Intel VT. Hope to share it soon.)
>>>
>>>> On 28-Apr-2015, at 7:17 pm, ilya <il...@gmail.com> wrote:
>>>>
>>>> Rohit
>>>>
>>>> Any headway on ESX 5.5? I've done this many times before using cloudstack and esx, but i was using esx as parent hypervisor.
>>>>
>>>> The challenge for me was being able to automatically deploy and configure the vSphere + ESXi env. I managed to get the whole flow working with bash script, puppet, VMA and while it works its not pretty. The challenge was the networking bit.
>>>>
>>>> Last but not least, consider using cloudstack to test cloudstack. i.e. master env, would use cloudstack projects and spinup smaller envs with KVM, Xen and VmWare bound to each project.
>>>>
>>>> Regards
>>>> ilya
>>>>
>>>> On 4/24/15 7:53 AM, Rohit Yadav wrote:
>>>>> Daan,
>>>>>
>>>>>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>>>>>
>>>>>> Rohit, the issues you mention are not as painful if we release in a
>>>>>> two week schedule as the period of creating a fix to seeing it in a
>>>>>> release will be shorter. Some releases will be broken for some people,
>>>>>> I don't think we can prevent this. The target we are aiming for is to
>>>>>> big to cover it completely.
>>>>> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>>>>>
>>>>> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
>>>>>
>>>>>> Your points are valid, though.
>>>>>> .1 a three person release team makes sense. I have been really happy
>>>>>> with the help I got from Pierre-Luc and I think David can do with help
>>>>>> the coming time as well.
>>>>>> .2 Hopefully people won't need to test every release so extensively
>>>>>> anymore as the changes become smaller. (and my initial remark the
>>>>>> above applies as well)
>>>>> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>>>>>
>>>>>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>>>>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>>>>>>
>>>>>>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>>>>>>
>>>>>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>>>>>
>>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>
>>>>>>>>
>>>>>>>> Quick bullet point discussions:
>>>>>>>>
>>>>>>>> ideas to change release planning
>>>>>>>>
>>>>>>>> - Plugin contribution is complicated because often a new plugin involve
>>>>>>>> change on the core:
>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>>> introduce issue the database schema.
>>>>>>>> - Database schema version should be different then the application
>>>>>>>> version.
>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>>>>>>> job on PullRequest.
>>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>>> 4.5.x). But the current level of confidence against latest release is low,
>>>>>>>> so that need to be improved.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the main messages is that w'd like to improve the release velocity, and
>>>>>>>> release branch stability. so we would like to propose few change in the
>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>
>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>>>>>>> which would trigger a simulator job, ideally only if that pass the PR would
>>>>>>>> be accepted and automatically merged. At this time, I think we pretty much
>>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>>
>>>>>>>> Please comments :-)
>>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>> 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.
>>>>
>>>>
>>>
>>> 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.
>>
>
> 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.
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: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Remi,
Thanks. Sure we can work together on this, I guess you would be running KVM/XenServer on KVM. Ping me if you need help on running ESX 5.x on KVM as it requires a patched qemu system binary (prebuilt debs here http://people.apache.org/~bhaisaab/qemu). If these nested hosts are managed by CloudStack itself instead of virsh or virt-viewer, then use ACS 4.5 or master.
> On 29-Apr-2015, at 5:21 pm, Remi Bergsma <RB...@schubergphilis.com> wrote:
>
> Hi Rohit,
>
> Nice work!
>
> I agree we need an environment that does run on something else than the local machine, as we need more horse power. We worked on something similar, where we have a cluster of KVM controlled by CloudStack in our Employee Cloud and spin large VMs running CentOS 7.1 (we use 32 or 64GB ram). In this big VM we run KVM again and spin up all infrastructure, ranging from hypervisors, SDN controllers, database hosts, storage appliances, etc. The big benefit is that networking is easy, as it is all in one box. Also, everybody uses the same prefixes. Using a L2 VPN we connect the workstations to the dev/test environment. All VMs can be controlled using virt-manager (like you also showed) and it is actually CloudStack running inside CloudStack. Deploying this VM has been automated and we’re now working on automating different scenario’s. They can also be used as Jenkins build slaves, for example. It is work in progress.
>
> Long story short: Let's work together on this :-)
>
> Regards,
> Remi
>
>
>> On 28 Apr 2015, at 21:07, Rohit Yadav <ro...@shapeblue.com> wrote:
>>
>> Hi Ilya,
>>
>> In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM you need to;
>>
>> - use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m waiting for Fedora 22 to test it on F22 as well), you may install the pre-built debs or build/install qemu from source using the patch from here: people.apache.org/~bhaisaab/qemu
>> - use ACS using latest 4.5 branch and deploy a basic zone (without SG) to provision hypervisor hosts as user vms
>> - in agent.properties (on your kvm host), enable guest.cpu.features=vmx and guest.cpu.mode=host-passthrough
>> - when deploying ESX 5.x on vm (or installing using an ISO) deploy virtualmachine with details nicAdapter=vmxnet3, for other hypervisors (including ESX 6.0) E1000, the default nic adapter, works
>>
>> IMO this is a better approach as it does not depend on ESX or VMWare fusion that requires special hardware (vCenter/Windows etc or OSX/Apple machine) and are difficult to automate. Working with KVM host, since is a Linux machine, would be more familiar to sysadmins and certainly a pleasure to scale and work with because one can avoid management tools (such as XenCenter or vCenter).
>>
>> (I’m still working on the "CloudStack Developer Kit” {CDK} so it’s not in a state to be released yet, will avoid publishing a faulty tool now. Instead of the DevCloud approach which promotes everything on one machine, the CDK I’m trying to build focuses on developer productivity, reproducibility and scalability of a QA lab, it recommends at least one companion hardware with a developer’s workstation/laptop which can be a small-form-factor server like a mini PC or NUC with at least 16GB RAM and 4 cores i7 with Intel VT. Hope to share it soon.)
>>
>>> On 28-Apr-2015, at 7:17 pm, ilya <il...@gmail.com> wrote:
>>>
>>> Rohit
>>>
>>> Any headway on ESX 5.5? I've done this many times before using cloudstack and esx, but i was using esx as parent hypervisor.
>>>
>>> The challenge for me was being able to automatically deploy and configure the vSphere + ESXi env. I managed to get the whole flow working with bash script, puppet, VMA and while it works its not pretty. The challenge was the networking bit.
>>>
>>> Last but not least, consider using cloudstack to test cloudstack. i.e. master env, would use cloudstack projects and spinup smaller envs with KVM, Xen and VmWare bound to each project.
>>>
>>> Regards
>>> ilya
>>>
>>> On 4/24/15 7:53 AM, Rohit Yadav wrote:
>>>> Daan,
>>>>
>>>>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>>>>
>>>>> Rohit, the issues you mention are not as painful if we release in a
>>>>> two week schedule as the period of creating a fix to seeing it in a
>>>>> release will be shorter. Some releases will be broken for some people,
>>>>> I don't think we can prevent this. The target we are aiming for is to
>>>>> big to cover it completely.
>>>> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>>>>
>>>> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
>>>>
>>>>> Your points are valid, though.
>>>>> .1 a three person release team makes sense. I have been really happy
>>>>> with the help I got from Pierre-Luc and I think David can do with help
>>>>> the coming time as well.
>>>>> .2 Hopefully people won't need to test every release so extensively
>>>>> anymore as the changes become smaller. (and my initial remark the
>>>>> above applies as well)
>>>> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>>>>
>>>>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>>>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>>>>>
>>>>>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>>>>>
>>>>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>>>>
>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>> management targeting the next 4.6 releases.
>>>>>>>
>>>>>>>
>>>>>>> Quick bullet point discussions:
>>>>>>>
>>>>>>> ideas to change release planning
>>>>>>>
>>>>>>> - Plugin contribution is complicated because often a new plugin involve
>>>>>>> change on the core:
>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>> introduce issue the database schema.
>>>>>>> - Database schema version should be different then the application
>>>>>>> version.
>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>>>>>> job on PullRequest.
>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>> 4.5.x). But the current level of confidence against latest release is low,
>>>>>>> so that need to be improved.
>>>>>>>
>>>>>>>
>>>>>>> So, the main messages is that w'd like to improve the release velocity, and
>>>>>>> release branch stability. so we would like to propose few change in the
>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>
>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>>>>>> which would trigger a simulator job, ideally only if that pass the PR would
>>>>>>> be accepted and automatically merged. At this time, I think we pretty much
>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>
>>>>>>> Please comments :-)
>>>>>> 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.
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>> 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.
>>>
>>>
>>
>> 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.
>
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: [DISCUSS] 4.6 release management
Posted by Remi Bergsma <RB...@schubergphilis.com>.
Hi Rohit,
Nice work!
I agree we need an environment that does run on something else than the local machine, as we need more horse power. We worked on something similar, where we have a cluster of KVM controlled by CloudStack in our Employee Cloud and spin large VMs running CentOS 7.1 (we use 32 or 64GB ram). In this big VM we run KVM again and spin up all infrastructure, ranging from hypervisors, SDN controllers, database hosts, storage appliances, etc. The big benefit is that networking is easy, as it is all in one box. Also, everybody uses the same prefixes. Using a L2 VPN we connect the workstations to the dev/test environment. All VMs can be controlled using virt-manager (like you also showed) and it is actually CloudStack running inside CloudStack. Deploying this VM has been automated and we’re now working on automating different scenario’s. They can also be used as Jenkins build slaves, for example. It is work in progress.
Long story short: Let's work together on this :-)
Regards,
Remi
> On 28 Apr 2015, at 21:07, Rohit Yadav <ro...@shapeblue.com> wrote:
>
> Hi Ilya,
>
> In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM you need to;
>
> - use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m waiting for Fedora 22 to test it on F22 as well), you may install the pre-built debs or build/install qemu from source using the patch from here: people.apache.org/~bhaisaab/qemu
> - use ACS using latest 4.5 branch and deploy a basic zone (without SG) to provision hypervisor hosts as user vms
> - in agent.properties (on your kvm host), enable guest.cpu.features=vmx and guest.cpu.mode=host-passthrough
> - when deploying ESX 5.x on vm (or installing using an ISO) deploy virtualmachine with details nicAdapter=vmxnet3, for other hypervisors (including ESX 6.0) E1000, the default nic adapter, works
>
> IMO this is a better approach as it does not depend on ESX or VMWare fusion that requires special hardware (vCenter/Windows etc or OSX/Apple machine) and are difficult to automate. Working with KVM host, since is a Linux machine, would be more familiar to sysadmins and certainly a pleasure to scale and work with because one can avoid management tools (such as XenCenter or vCenter).
>
> (I’m still working on the "CloudStack Developer Kit” {CDK} so it’s not in a state to be released yet, will avoid publishing a faulty tool now. Instead of the DevCloud approach which promotes everything on one machine, the CDK I’m trying to build focuses on developer productivity, reproducibility and scalability of a QA lab, it recommends at least one companion hardware with a developer’s workstation/laptop which can be a small-form-factor server like a mini PC or NUC with at least 16GB RAM and 4 cores i7 with Intel VT. Hope to share it soon.)
>
>> On 28-Apr-2015, at 7:17 pm, ilya <il...@gmail.com> wrote:
>>
>> Rohit
>>
>> Any headway on ESX 5.5? I've done this many times before using cloudstack and esx, but i was using esx as parent hypervisor.
>>
>> The challenge for me was being able to automatically deploy and configure the vSphere + ESXi env. I managed to get the whole flow working with bash script, puppet, VMA and while it works its not pretty. The challenge was the networking bit.
>>
>> Last but not least, consider using cloudstack to test cloudstack. i.e. master env, would use cloudstack projects and spinup smaller envs with KVM, Xen and VmWare bound to each project.
>>
>> Regards
>> ilya
>>
>> On 4/24/15 7:53 AM, Rohit Yadav wrote:
>>> Daan,
>>>
>>>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>>>
>>>> Rohit, the issues you mention are not as painful if we release in a
>>>> two week schedule as the period of creating a fix to seeing it in a
>>>> release will be shorter. Some releases will be broken for some people,
>>>> I don't think we can prevent this. The target we are aiming for is to
>>>> big to cover it completely.
>>> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>>>
>>> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
>>>
>>>> Your points are valid, though.
>>>> .1 a three person release team makes sense. I have been really happy
>>>> with the help I got from Pierre-Luc and I think David can do with help
>>>> the coming time as well.
>>>> .2 Hopefully people won't need to test every release so extensively
>>>> anymore as the changes become smaller. (and my initial remark the
>>>> above applies as well)
>>> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>>>
>>>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>>>>
>>>>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>>>>
>>>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>>>
>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>> management targeting the next 4.6 releases.
>>>>>>
>>>>>>
>>>>>> Quick bullet point discussions:
>>>>>>
>>>>>> ideas to change release planning
>>>>>>
>>>>>> - Plugin contribution is complicated because often a new plugin involve
>>>>>> change on the core:
>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>> introduce issue the database schema.
>>>>>> - Database schema version should be different then the application
>>>>>> version.
>>>>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>>>>> job on PullRequest.
>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>> 4.5.x). But the current level of confidence against latest release is low,
>>>>>> so that need to be improved.
>>>>>>
>>>>>>
>>>>>> So, the main messages is that w'd like to improve the release velocity, and
>>>>>> release branch stability. so we would like to propose few change in the
>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>
>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>>>>> which would trigger a simulator job, ideally only if that pass the PR would
>>>>>> be accepted and automatically merged. At this time, I think we pretty much
>>>>>> have everything in place to do that. At a first step we would use
>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>
>>>>>> Please comments :-)
>>>>> 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.
>>>>
>>>>
>>>> --
>>>> Daan
>>> 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.
>>
>>
>
> 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: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <ro...@shapeblue.com>.
Hi Ilya,
In short - to run ESX and other hypervisors (Xen, KVM, OVM3, HyperV etc) on KVM you need to;
- use patched qemu (tested to work on both Ubuntu 14.04 and 15.04 x64, I’m waiting for Fedora 22 to test it on F22 as well), you may install the pre-built debs or build/install qemu from source using the patch from here: people.apache.org/~bhaisaab/qemu
- use ACS using latest 4.5 branch and deploy a basic zone (without SG) to provision hypervisor hosts as user vms
- in agent.properties (on your kvm host), enable guest.cpu.features=vmx and guest.cpu.mode=host-passthrough
- when deploying ESX 5.x on vm (or installing using an ISO) deploy virtualmachine with details nicAdapter=vmxnet3, for other hypervisors (including ESX 6.0) E1000, the default nic adapter, works
IMO this is a better approach as it does not depend on ESX or VMWare fusion that requires special hardware (vCenter/Windows etc or OSX/Apple machine) and are difficult to automate. Working with KVM host, since is a Linux machine, would be more familiar to sysadmins and certainly a pleasure to scale and work with because one can avoid management tools (such as XenCenter or vCenter).
(I’m still working on the "CloudStack Developer Kit” {CDK} so it’s not in a state to be released yet, will avoid publishing a faulty tool now. Instead of the DevCloud approach which promotes everything on one machine, the CDK I’m trying to build focuses on developer productivity, reproducibility and scalability of a QA lab, it recommends at least one companion hardware with a developer’s workstation/laptop which can be a small-form-factor server like a mini PC or NUC with at least 16GB RAM and 4 cores i7 with Intel VT. Hope to share it soon.)
> On 28-Apr-2015, at 7:17 pm, ilya <il...@gmail.com> wrote:
>
> Rohit
>
> Any headway on ESX 5.5? I've done this many times before using cloudstack and esx, but i was using esx as parent hypervisor.
>
> The challenge for me was being able to automatically deploy and configure the vSphere + ESXi env. I managed to get the whole flow working with bash script, puppet, VMA and while it works its not pretty. The challenge was the networking bit.
>
> Last but not least, consider using cloudstack to test cloudstack. i.e. master env, would use cloudstack projects and spinup smaller envs with KVM, Xen and VmWare bound to each project.
>
> Regards
> ilya
>
> On 4/24/15 7:53 AM, Rohit Yadav wrote:
>> Daan,
>>
>>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>>
>>> Rohit, the issues you mention are not as painful if we release in a
>>> two week schedule as the period of creating a fix to seeing it in a
>>> release will be shorter. Some releases will be broken for some people,
>>> I don't think we can prevent this. The target we are aiming for is to
>>> big to cover it completely.
>> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>>
>> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
>>
>>> Your points are valid, though.
>>> .1 a three person release team makes sense. I have been really happy
>>> with the help I got from Pierre-Luc and I think David can do with help
>>> the coming time as well.
>>> .2 Hopefully people won't need to test every release so extensively
>>> anymore as the changes become smaller. (and my initial remark the
>>> above applies as well)
>> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>>
>>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>>>
>>>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>>>
>>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>>
>>>>> Today during the CloudStackdays we did a round table about Release
>>>>> management targeting the next 4.6 releases.
>>>>>
>>>>>
>>>>> Quick bullet point discussions:
>>>>>
>>>>> ideas to change release planning
>>>>>
>>>>> - Plugin contribution is complicated because often a new plugin involve
>>>>> change on the core:
>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>> introduce issue the database schema.
>>>>> - Database schema version should be different then the application
>>>>> version.
>>>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>>>> job on PullRequest.
>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>> 4.5.x). But the current level of confidence against latest release is low,
>>>>> so that need to be improved.
>>>>>
>>>>>
>>>>> So, the main messages is that w'd like to improve the release velocity, and
>>>>> release branch stability. so we would like to propose few change in the
>>>>> way we would add code to the 4.6 branch as follow:
>>>>>
>>>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>>>> which would trigger a simulator job, ideally only if that pass the PR would
>>>>> be accepted and automatically merged. At this time, I think we pretty much
>>>>> have everything in place to do that. At a first step we would use
>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>
>>>>> Please comments :-)
>>>> 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.
>>>
>>>
>>> --
>>> Daan
>> 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.
>
>
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: [DISCUSS] 4.6 release management
Posted by ilya <il...@gmail.com>.
Rohit
Any headway on ESX 5.5? I've done this many times before using
cloudstack and esx, but i was using esx as parent hypervisor.
The challenge for me was being able to automatically deploy and
configure the vSphere + ESXi env. I managed to get the whole flow
working with bash script, puppet, VMA and while it works its not pretty.
The challenge was the networking bit.
Last but not least, consider using cloudstack to test cloudstack. i.e.
master env, would use cloudstack projects and spinup smaller envs with
KVM, Xen and VmWare bound to each project.
Regards
ilya
On 4/24/15 7:53 AM, Rohit Yadav wrote:
> Daan,
>
>> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>>
>> Rohit, the issues you mention are not as painful if we release in a
>> two week schedule as the period of creating a fix to seeing it in a
>> release will be shorter. Some releases will be broken for some people,
>> I don't think we can prevent this. The target we are aiming for is to
>> big to cover it completely.
> I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
>
> For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
>
>> Your points are valid, though.
>> .1 a three person release team makes sense. I have been really happy
>> with the help I got from Pierre-Luc and I think David can do with help
>> the coming time as well.
>> .2 Hopefully people won't need to test every release so extensively
>> anymore as the changes become smaller. (and my initial remark the
>> above applies as well)
> By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>
>> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>>
>>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>>
>>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>>
>>>> Today during the CloudStackdays we did a round table about Release
>>>> management targeting the next 4.6 releases.
>>>>
>>>>
>>>> Quick bullet point discussions:
>>>>
>>>> ideas to change release planning
>>>>
>>>> - Plugin contribution is complicated because often a new plugin involve
>>>> change on the core:
>>>> - ex: storage plugin involve changes on Hypervisor code
>>>> - There is an idea of going on a 2 weeks release model which could
>>>> introduce issue the database schema.
>>>> - Database schema version should be different then the application
>>>> version.
>>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>>> job on PullRequest.
>>>> - Some people (I'm part of them) are concerned on our current way of
>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>> 4.5.x). But the current level of confidence against latest release is low,
>>>> so that need to be improved.
>>>>
>>>>
>>>> So, the main messages is that w'd like to improve the release velocity, and
>>>> release branch stability. so we would like to propose few change in the
>>>> way we would add code to the 4.6 branch as follow:
>>>>
>>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>>> which would trigger a simulator job, ideally only if that pass the PR would
>>>> be accepted and automatically merged. At this time, I think we pretty much
>>>> have everything in place to do that. At a first step we would use
>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>
>>>> Please comments :-)
>>> 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.
>>
>>
>> --
>> Daan
> 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: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <ro...@shapeblue.com>.
Daan,
> On 24-Apr-2015, at 3:53 pm, Daan Hoogland <da...@gmail.com> wrote:
>
> Rohit, the issues you mention are not as painful if we release in a
> two week schedule as the period of creating a fix to seeing it in a
> release will be shorter. Some releases will be broken for some people,
> I don't think we can prevent this. The target we are aiming for is to
> big to cover it completely.
I agree with you, but I think there are pros and cons to both approaches and for this to work it needs to be able to walk first before it can run.
For this to work we need an automated QA system, to solve this Abhi is working on it for past few weeks and will be adding more non-hardware tests (simulator ones) to travis. In my free time, I’m trying to setup a nested virtualized environment where we can test ACS against Xen, KVM and VMware on top on KVM. So far, I’m able to run XenServer 6.2+6.5 and KVM on top of KVM with vmx (intel-vt) enabled, and making some progress with running ESX on KVM (I’m able to run ESX 6.0 on KVM now, but not ESX 5.x which is something I’m exploring). I hope we'll have something working soon that is fairly fast and easy to reproduce.
> Your points are valid, though.
> .1 a three person release team makes sense. I have been really happy
> with the help I got from Pierre-Luc and I think David can do with help
> the coming time as well.
> .2 Hopefully people won't need to test every release so extensively
> anymore as the changes become smaller. (and my initial remark the
> above applies as well)
By having too many releases we’ll have to deal with too many upgrade path issues and users will spread across different versions which will create an issue for maintainers who are supporting users -- one solution for this problem can be that we introduce a concept of LTS release that is either maintained by the community (which can be difficult) or some interested stakeholders, for users that would prefer upgrading everytime there is a new CloudStack release.
>
> On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>>
>> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>>
>>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>
>>> Today during the CloudStackdays we did a round table about Release
>>> management targeting the next 4.6 releases.
>>>
>>>
>>> Quick bullet point discussions:
>>>
>>> ideas to change release planning
>>>
>>> - Plugin contribution is complicated because often a new plugin involve
>>> change on the core:
>>> - ex: storage plugin involve changes on Hypervisor code
>>> - There is an idea of going on a 2 weeks release model which could
>>> introduce issue the database schema.
>>> - Database schema version should be different then the application
>>> version.
>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>> job on PullRequest.
>>> - Some people (I'm part of them) are concerned on our current way of
>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>> 4.5.x). But the current level of confidence against latest release is low,
>>> so that need to be improved.
>>>
>>>
>>> So, the main messages is that w'd like to improve the release velocity, and
>>> release branch stability. so we would like to propose few change in the
>>> way we would add code to the 4.6 branch as follow:
>>>
>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>> which would trigger a simulator job, ideally only if that pass the PR would
>>> be accepted and automatically merged. At this time, I think we pretty much
>>> have everything in place to do that. At a first step we would use
>>> simulator+marvin jobs then improve tests coverage from there.
>>>
>>> Please comments :-)
>>
>> 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.
>
>
>
> --
> Daan
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: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
Rohit, the issues you mention are not as painful if we release in a
two week schedule as the period of creating a fix to seeing it in a
release will be shorter. Some releases will be broken for some people,
I don't think we can prevent this. The target we are aiming for is to
big to cover it completely.
Your points are valid, though.
.1 a three person release team makes sense. I have been really happy
with the help I got from Pierre-Luc and I think David can do with help
the coming time as well.
.2 Hopefully people won't need to test every release so extensively
anymore as the changes become smaller. (and my initial remark the
above applies as well)
On Fri, Apr 24, 2015 at 2:43 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
> I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
>
> The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
>
>> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>> - Plugin contribution is complicated because often a new plugin involve
>> change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>> - There is an idea of going on a 2 weeks release model which could
>> introduce issue the database schema.
>> - Database schema version should be different then the application
>> version.
>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>> job on PullRequest.
>> - Some people (I'm part of them) are concerned on our current way of
>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>> 4.5.x). But the current level of confidence against latest release is low,
>> so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release velocity, and
>> release branch stability. so we would like to propose few change in the
>> way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>> which would trigger a simulator job, ideally only if that pass the PR would
>> be accepted and automatically merged. At this time, I think we pretty much
>> have everything in place to do that. At a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>>
>> Please comments :-)
>
> 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.
--
Daan
Re: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <ro...@shapeblue.com>.
I think we need to have a faster release management to speed up process in general, and for that I propose that we have at least two co-pilots for the release manager who would support them with things like reviewing/merging patches, creating RC candidates etc whenever necessary. Having only one person as a release manager can become a bottleneck for a speedy release.
The other issue is getting people to test a (release) branch, fix bugs and expect a review/result in 72 hours. This has usually failed if people are busy and not getting enough time for this. As an example, I think 4.5 is delayed because it lacked people actively testing it or fixing issues, or when issues were found only around the RC testing period which delayed RC voting by 1-2 weeks every time that happened. (I’ll post details about where I think we are wrt 4.5 in another thread).
> On 17-Apr-2015, at 12:49 am, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated because often a new plugin involve
> change on the core:
> - ex: storage plugin involve changes on Hypervisor code
> - There is an idea of going on a 2 weeks release model which could
> introduce issue the database schema.
> - Database schema version should be different then the application
> version.
> - There is a will to enforce git workflow in 4.6 and trigger simulator
> job on PullRequest.
> - Some people (I'm part of them) are concerned on our current way of
> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
> 4.5.x). But the current level of confidence against latest release is low,
> so that need to be improved.
>
>
> So, the main messages is that w'd like to improve the release velocity, and
> release branch stability. so we would like to propose few change in the
> way we would add code to the 4.6 branch as follow:
>
> - All new contribution to 4.6 would be thru Pull Request or merge request,
> which would trigger a simulator job, ideally only if that pass the PR would
> be accepted and automatically merged. At this time, I think we pretty much
> have everything in place to do that. At a first step we would use
> simulator+marvin jobs then improve tests coverage from there.
>
> Please comments :-)
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: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
I never intended for all 6 RM to be involved in every commit. Just to have
6 in order to spread the load. I just want at least two of them to verify
each merge.
Op wo 13 mei 2015 om 18:32 schreef sebgoa <ru...@gmail.com>:
>
> On May 13, 2015, at 6:07 PM, David Nalley <da...@gnsa.us> wrote:
>
> > On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
> > <WR...@schubergphilis.com> wrote:
> >> Hi guys,
> >>
> >> I hope that’s not too late to react on this one.
> >>
> >> Having 6 RMs seems a bit too much for me. For PRs containing a few
> lines of code, just bug fixes or changing maven files, python, sh, etc it
> might be simple and quick. However, if we get a PR with +30 commits and 10k
> lines added, it gets really difficult to get the community to test/review
> the PR. So, for 2 people to go over it is already taking too long to get
> the code imagine, now imagine 4 or 6.
> >>
> >> Rohit has done an excellent job in looking into the PRs, commenting on
> them and some times testing as well. But there are things that cannot
> simply get him, or perhaps other guys, to test properly a PR; having time
> and environment as the main reasons.
> >>
> >> I would say that in case we have a PR that contains:
> >>
> >> 1. Documentation on the Apache CS Wiki
> >> 2. Unit Tests (a lot of them, minimum 70% for the code changed)
> >> 3. Marvin Test Results report - test_routers, test_vpc_routers,
> test_vm_life_cycle, test_account, at least.
> >>
> >> Should be given priority and get less RMs involved in order to speed up
> our development/release processes. Unless, of course, the people would have
> time to look into the PR immediately.
> >>
> >> What do you think?
> >>
> >> Cheers,
> >> Wilder
> >>
> >
> >
> > I like this.
> > We have to live by our tests. So enforcing good coverage, and gating
> > on good results makes sense to me.
> > No human can reliably eyeball all of this.
> >
> > --David
>
> I don't think we are saying anything different to this.
>
> Any PR should pass the Travis tests (…and there should be more tests).
> Review should not allow anything that does not have unit test either.
> For new features, they should come with documentation patches as well.
>
> bottom line, I don't think we disagree. Or maybe I missing something.
>
> -sebastien
>
>
>
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
On May 13, 2015, at 6:07 PM, David Nalley <da...@gnsa.us> wrote:
> On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
> <WR...@schubergphilis.com> wrote:
>> Hi guys,
>>
>> I hope that’s not too late to react on this one.
>>
>> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of code, just bug fixes or changing maven files, python, sh, etc it might be simple and quick. However, if we get a PR with +30 commits and 10k lines added, it gets really difficult to get the community to test/review the PR. So, for 2 people to go over it is already taking too long to get the code imagine, now imagine 4 or 6.
>>
>> Rohit has done an excellent job in looking into the PRs, commenting on them and some times testing as well. But there are things that cannot simply get him, or perhaps other guys, to test properly a PR; having time and environment as the main reasons.
>>
>> I would say that in case we have a PR that contains:
>>
>> 1. Documentation on the Apache CS Wiki
>> 2. Unit Tests (a lot of them, minimum 70% for the code changed)
>> 3. Marvin Test Results report - test_routers, test_vpc_routers, test_vm_life_cycle, test_account, at least.
>>
>> Should be given priority and get less RMs involved in order to speed up our development/release processes. Unless, of course, the people would have time to look into the PR immediately.
>>
>> What do you think?
>>
>> Cheers,
>> Wilder
>>
>
>
> I like this.
> We have to live by our tests. So enforcing good coverage, and gating
> on good results makes sense to me.
> No human can reliably eyeball all of this.
>
> --David
I don't think we are saying anything different to this.
Any PR should pass the Travis tests (…and there should be more tests).
Review should not allow anything that does not have unit test either.
For new features, they should come with documentation patches as well.
bottom line, I don't think we disagree. Or maybe I missing something.
-sebastien
Re: [DISCUSS] 4.6 release management
Posted by Wilder Rodrigues <WR...@schubergphilis.com>.
Thanks, David. I really appreciate that!
Should we change the subject to development guidelines? It is also related the way we commit/push code to git. I can contribute on that by writing a few lines that would help the community on producing better code (i.e increasing coverage) and having a clear process concerning the way everybody contributes to ACS.
Cheers,
Wilder
Sent from my iPhone
> On 13 May 2015, at 18:10, David Nalley <da...@gnsa.us> wrote:
>
> On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
> <WR...@schubergphilis.com> wrote:
>> Hi guys,
>>
>> I hope that’s not too late to react on this one.
>>
>> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of code, just bug fixes or changing maven files, python, sh, etc it might be simple and quick. However, if we get a PR with +30 commits and 10k lines added, it gets really difficult to get the community to test/review the PR. So, for 2 people to go over it is already taking too long to get the code imagine, now imagine 4 or 6.
>>
>> Rohit has done an excellent job in looking into the PRs, commenting on them and some times testing as well. But there are things that cannot simply get him, or perhaps other guys, to test properly a PR; having time and environment as the main reasons.
>>
>> I would say that in case we have a PR that contains:
>>
>> 1. Documentation on the Apache CS Wiki
>> 2. Unit Tests (a lot of them, minimum 70% for the code changed)
>> 3. Marvin Test Results report - test_routers, test_vpc_routers, test_vm_life_cycle, test_account, at least.
>>
>> Should be given priority and get less RMs involved in order to speed up our development/release processes. Unless, of course, the people would have time to look into the PR immediately.
>>
>> What do you think?
>>
>> Cheers,
>> Wilder
>
>
> I like this.
> We have to live by our tests. So enforcing good coverage, and gating
> on good results makes sense to me.
> No human can reliably eyeball all of this.
>
> --David
Re: [DISCUSS] 4.6 release management
Posted by David Nalley <da...@gnsa.us>.
On Wed, May 13, 2015 at 8:36 AM, Wilder Rodrigues
<WR...@schubergphilis.com> wrote:
> Hi guys,
>
> I hope that’s not too late to react on this one.
>
> Having 6 RMs seems a bit too much for me. For PRs containing a few lines of code, just bug fixes or changing maven files, python, sh, etc it might be simple and quick. However, if we get a PR with +30 commits and 10k lines added, it gets really difficult to get the community to test/review the PR. So, for 2 people to go over it is already taking too long to get the code imagine, now imagine 4 or 6.
>
> Rohit has done an excellent job in looking into the PRs, commenting on them and some times testing as well. But there are things that cannot simply get him, or perhaps other guys, to test properly a PR; having time and environment as the main reasons.
>
> I would say that in case we have a PR that contains:
>
> 1. Documentation on the Apache CS Wiki
> 2. Unit Tests (a lot of them, minimum 70% for the code changed)
> 3. Marvin Test Results report - test_routers, test_vpc_routers, test_vm_life_cycle, test_account, at least.
>
> Should be given priority and get less RMs involved in order to speed up our development/release processes. Unless, of course, the people would have time to look into the PR immediately.
>
> What do you think?
>
> Cheers,
> Wilder
>
I like this.
We have to live by our tests. So enforcing good coverage, and gating
on good results makes sense to me.
No human can reliably eyeball all of this.
--David
Re: [DISCUSS] 4.6 release management
Posted by Wilder Rodrigues <WR...@schubergphilis.com>.
Hi guys,
I hope that’s not too late to react on this one.
Having 6 RMs seems a bit too much for me. For PRs containing a few lines of code, just bug fixes or changing maven files, python, sh, etc it might be simple and quick. However, if we get a PR with +30 commits and 10k lines added, it gets really difficult to get the community to test/review the PR. So, for 2 people to go over it is already taking too long to get the code imagine, now imagine 4 or 6.
Rohit has done an excellent job in looking into the PRs, commenting on them and some times testing as well. But there are things that cannot simply get him, or perhaps other guys, to test properly a PR; having time and environment as the main reasons.
I would say that in case we have a PR that contains:
1. Documentation on the Apache CS Wiki
2. Unit Tests (a lot of them, minimum 70% for the code changed)
3. Marvin Test Results report - test_routers, test_vpc_routers, test_vm_life_cycle, test_account, at least.
Should be given priority and get less RMs involved in order to speed up our development/release processes. Unless, of course, the people would have time to look into the PR immediately.
What do you think?
Cheers,
Wilder
On 11 May 2015, at 15:54, Rohit Yadav <ro...@shapeblue.com>> wrote:
On 11-May-2015, at 2:51 pm, Daan Hoogland <da...@gmail.com>> wrote:
I'm fine with that: rm must have a reviewer on merges? Seem heavy for
trivial changes but alright
On Mon, 11 May 2015 14:16 Sebastien Goasguen <ru...@gmail.com>> wrote:
On May 11, 2015, at 2:00 PM, Daan Hoogland <da...@gmail.com>>
wrote:
+1 how about my proposal to have 6 RM and demand that at least 2 agree on
each PR?
+0.5
we can say that we need two pairs of eyes to ok the PR for merge.
no need to formally have 6 RMs ?
so 1 RM (you or me) + another pair of eyes would work ?
I’ve been doing PR reviews as a habit, happy to chip-in as a co-pilot.
Op ma 11 mei 2015 om 09:52 schreef sebgoa <ru...@gmail.com>>:
On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>>
wrote:
I can have a look at the merge of 4.5.1 and am willing to be one of the
RMs, not to be the RM!
I can RM as well.
How about we lock down master on wednesday ?
From that point forward we only take PR into master -either you or me-
all
other direct commits to master will be reverted !!!!
-sebastien
Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>>:
So no -1 on this.
Do we have volunteers to RM 4.6 on the master branch ?
I propose to set a date asap, tag master and tell everyone that
starting
from that tag all commits to master except from RM will be reverted.
will need to make sure that all of 4.5.1 is in master
-sebastien
On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>>
wrote:
Let's not do more quality improvement proces but just improve
quality.
If
anybody want to add to the pages on the wiki, you're welkom but
nobody
did
for long time. +1 for the present state of Sebastien's views on
things.
We
can refine at any time.
Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>>:
On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>>
wrote:
Hi,
In my mind it was kind of making more sense to start by keeping 4.6
into
a
separate branch, enforce pull-requests and deploy the CI. smaller
step
but
faster result, and from there, once we get stable with the CI
I hear you.
But we have waited for way too long for better CI. I see great
efforts
in
that direction.
But I personally do not want to wait any longer to make a move.
We do open source, we should have fun, take risks, move fast, fail
fast,
recover etc….
so let's JFDI
and git flow;
move into master, do fastest releases cycle. If we consider we can
do
all
that starting in 4.6, I'm all for it!
Is there really a difference between creating a 4.6 and doing what
you
say, and tagging master (start) and doing it on master leading to
4.6
release ?
Assuming the QA does not improve, 4.6 would not be worse than 4.5.
If
we
can improve a bit on the QA then we win.
Plus I think a different commit model will help a lot in quality.
Marcus: are you preparing a proposal on this? wiki page? I can help
We can do this proposal on email..and once we have consensus write
it
up
for archive in the wiki.
If we move to the wiki now, this effort is going to die.
Seb: doesn't the vote would confirm the consensus?
if we have consensus no need for vote.
Raja: do we have any documentation somewhere on how to use,
contribute
to
the smoke test? that could be our start for the CI tests?
Cheers
On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
runseb@gmail.com<ma...@gmail.com>>
wrote:
On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com>> wrote:
After reviewing the history as mentioned by Daan, unless we
propose
and vote on a newer workflow model I think the best we can do is
to
simply be more strict about commits to master. They all need to
be
merges that have been tested against master before merge. This
will
in
theory make master more stable, but doesn't really change the
workflow
we've already agreed upon and have been working under (although
bugfixes sometimes were not coming in from branches, and
cherry-picked
bugfixes from branches will need to go into a branch first,
tested
against master, and merged to master). We can essentially set a
date
and do that any time, with some advance notice that direct
commits
will be reverted.
Yes +1.
-Set a date
-Tag master for reference
-Find a volunteer or two to RM master
-automatic revert on master if not from RM
-all commits to master come from PR, need clear review and green
tests
-harden master (basic QA process), release 4.6 as a tag on master
-all features and fixes need to be made on branches or forks and
onus
is
on devs to rebase to master
-brings everyone onto 4.6 (make sure we have upgrade paths from
4.3,
4.4,
etc)
-from there forward only maintain a linear release through master
Feel free to add, tweak
PS: No need to vote if we have consensus. Taking a clue from ASF
members,
votes should be avoided at all cost, they mean that we do not have
clear
consensus.
On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
runseb@gmail.com<ma...@gmail.com>
wrote:
On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com>
wrote:
Have they diverged that much? Due to cherry-picking, I guess.
Otherwise you should be able to do it cleanly.
There's a good opportunity to do this next release. Instead of
creating a release branch, we freeze master and start creating
dev
branches.
+1
This just amounts to treating master now like a release branch.
Getting
back to PL suggestion, that means
that any commit to master would be through a PR or MERGE request
on
the
ML. Anything else will be reverted by the RM.
Marcus, do you feel like writing down a little process for this
and
some dates that we can target.
It would be nice to do this for 4.6.
On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
daan.hoogland@gmail.com<ma...@gmail.com>> wrote:
We heavily invested in code now on master. Not looking forward
to
backporting that.
mobile dev with bilingual spelling checker used (read at your
own
risk)
Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>>:
Well, would we just swap the last release branch with master?
Master
is the dev branch, and the last release is really what we
have
as a
stable branch.
On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
daan.hoogland@gmail.com<ma...@gmail.com>>
wrote:
On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
runseb@gmail.com<ma...@gmail.com>>
wrote:
On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
pdion@cloudops.com<ma...@cloudops.com>
wrote:
Today during the CloudStackdays we did a round table
about
Release
management targeting the next 4.6 releases.
Quick bullet point discussions:
ideas to change release planning
- Plugin contribution is complicated because often a new
plugin
involve
change on the core:
- ex: storage plugin involve changes on Hypervisor code
- There is an idea of going on a 2 weeks release model
which
could
introduce issue the database schema.
- Database schema version should be different then the
application
version.
- There is a will to enforce git workflow in 4.6 and
trigger
simulator
job on PullRequest.
- Some people (I'm part of them) are concerned on our
current
way
of
supporting and back porting fixes to multiple release
(4.3.x,
4.4.x,
4.5.x). But the current level of confidence against latest
release
is low,
so that need to be improved.
So, the main messages is that w'd like to improve the
release
velocity, and
release branch stability. so we would like to propose few
change
in
the
way we would add code to the 4.6 branch as follow:
- All new contribution to 4.6 would be thru Pull Request
or
merge
request,
which would trigger a simulator job, ideally only if that
pass
the PR
would
be accepted and automatically merged. At this time, I
think
we
pretty
much
have everything in place to do that. At a first step we
would
use
simulator+marvin jobs then improve tests coverage from
there.
+1
We do need to realize what this means and be all fine with
it.
It means that if someone who is not RM directly commits to
the
release
branch, the commit will be reverted.
And that from the beginning of the branching…
I agree and we can even go as far as reverting fixes that
are
cherry-picked in favour of merged forward.
IMHO, I think this would be a good step but I don’t think
it
goes
far
enough.
Agreed here as well but let's take the step while discussing
further
steps and not implement to much process as well
This still uses a paradigm where a release is made from a
release
branch that was started from an unstable development branch.
Hence you still need *extensive* QA.
The problem here is that there is no stable point to fork
from
at
the
moment. We will get there and we shouldn't stop taking steps
in
that
direction.
If we truly want to release faster, we need to release from
the
same
QA’d branch time after time….a release needs to be based on a
previous
release
Basically, we need a rolling release cycle. That will have
the
added
benefit to not leave releases behind and have to focus on
backporting.
Please comments :-)
--
Daan
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.yadav@shapeblue.com<ma...@shapeblue.com>
Blog: bhaisaab.org<http://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: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <ro...@shapeblue.com>.
> On 11-May-2015, at 2:51 pm, Daan Hoogland <da...@gmail.com> wrote:
>
> I'm fine with that: rm must have a reviewer on merges? Seem heavy for
> trivial changes but alright
>
> On Mon, 11 May 2015 14:16 Sebastien Goasguen <ru...@gmail.com> wrote:
>
>>
>>> On May 11, 2015, at 2:00 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>>
>>> +1 how about my proposal to have 6 RM and demand that at least 2 agree on
>>> each PR?
>>
>> +0.5
>>
>> we can say that we need two pairs of eyes to ok the PR for merge.
>> no need to formally have 6 RMs ?
>>
>> so 1 RM (you or me) + another pair of eyes would work ?
I’ve been doing PR reviews as a habit, happy to chip-in as a co-pilot.
>>> Op ma 11 mei 2015 om 09:52 schreef sebgoa <ru...@gmail.com>:
>>>
>>>>
>>>> On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>
>>>>> I can have a look at the merge of 4.5.1 and am willing to be one of the
>>>>> RMs, not to be the RM!
>>>>>
>>>>
>>>> I can RM as well.
>>>>
>>>> How about we lock down master on wednesday ?
>>>> From that point forward we only take PR into master -either you or me-
>> all
>>>> other direct commits to master will be reverted !!!!
>>>>
>>>>
>>>> -sebastien
>>>>
>>>>
>>>>
>>>>> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>>>>>
>>>>>> So no -1 on this.
>>>>>>
>>>>>> Do we have volunteers to RM 4.6 on the master branch ?
>>>>>>
>>>>>> I propose to set a date asap, tag master and tell everyone that
>> starting
>>>>>> from that tag all commits to master except from RM will be reverted.
>>>>>>
>>>>>> will need to make sure that all of 4.5.1 is in master
>>>>>>
>>>>>> -sebastien
>>>>>>
>>>>>>
>>>>>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> Let's not do more quality improvement proces but just improve
>> quality.
>>>> If
>>>>>>> anybody want to add to the pages on the wiki, you're welkom but
>> nobody
>>>>>> did
>>>>>>> for long time. +1 for the present state of Sebastien's views on
>> things.
>>>>>> We
>>>>>>> can refine at any time.
>>>>>>>
>>>>>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>>>>>>>
>>>>>>>>
>>>>>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In my mind it was kind of making more sense to start by keeping 4.6
>>>>>> into
>>>>>>>> a
>>>>>>>>> separate branch, enforce pull-requests and deploy the CI. smaller
>>>> step
>>>>>>>> but
>>>>>>>>> faster result, and from there, once we get stable with the CI
>>>>>>>>
>>>>>>>> I hear you.
>>>>>>>>
>>>>>>>> But we have waited for way too long for better CI. I see great
>> efforts
>>>>>> in
>>>>>>>> that direction.
>>>>>>>> But I personally do not want to wait any longer to make a move.
>>>>>>>>
>>>>>>>> We do open source, we should have fun, take risks, move fast, fail
>>>> fast,
>>>>>>>> recover etc….
>>>>>>>>
>>>>>>>> so let's JFDI
>>>>>>>>
>>>>>>>>> and git flow;
>>>>>>>>> move into master, do fastest releases cycle. If we consider we can
>> do
>>>>>> all
>>>>>>>>> that starting in 4.6, I'm all for it!
>>>>>>>>
>>>>>>>>
>>>>>>>> Is there really a difference between creating a 4.6 and doing what
>> you
>>>>>>>> say, and tagging master (start) and doing it on master leading to
>> 4.6
>>>>>>>> release ?
>>>>>>>>
>>>>>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5.
>> If
>>>> we
>>>>>>>> can improve a bit on the QA then we win.
>>>>>>>> Plus I think a different commit model will help a lot in quality.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>>>>>>>>>
>>>>>>>>
>>>>>>>> We can do this proposal on email..and once we have consensus write
>> it
>>>> up
>>>>>>>> for archive in the wiki.
>>>>>>>> If we move to the wiki now, this effort is going to die.
>>>>>>>>
>>>>>>>>> Seb: doesn't the vote would confirm the consensus?
>>>>>>>>>
>>>>>>>>
>>>>>>>> if we have consensus no need for vote.
>>>>>>>>
>>>>>>>>> Raja: do we have any documentation somewhere on how to use,
>>>> contribute
>>>>>>>> to
>>>>>>>>> the smoke test? that could be our start for the CI tests?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
>>>> runseb@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> After reviewing the history as mentioned by Daan, unless we
>> propose
>>>>>>>>>>> and vote on a newer workflow model I think the best we can do is
>> to
>>>>>>>>>>> simply be more strict about commits to master. They all need to
>> be
>>>>>>>>>>> merges that have been tested against master before merge. This
>> will
>>>>>> in
>>>>>>>>>>> theory make master more stable, but doesn't really change the
>>>>>> workflow
>>>>>>>>>>> we've already agreed upon and have been working under (although
>>>>>>>>>>> bugfixes sometimes were not coming in from branches, and
>>>>>> cherry-picked
>>>>>>>>>>> bugfixes from branches will need to go into a branch first,
>> tested
>>>>>>>>>>> against master, and merged to master). We can essentially set a
>>>> date
>>>>>>>>>>> and do that any time, with some advance notice that direct
>> commits
>>>>>>>>>>> will be reverted.
>>>>>>>>>>
>>>>>>>>>> Yes +1.
>>>>>>>>>>
>>>>>>>>>> -Set a date
>>>>>>>>>> -Tag master for reference
>>>>>>>>>> -Find a volunteer or two to RM master
>>>>>>>>>> -automatic revert on master if not from RM
>>>>>>>>>> -all commits to master come from PR, need clear review and green
>>>> tests
>>>>>>>>>> -harden master (basic QA process), release 4.6 as a tag on master
>>>>>>>>>> -all features and fixes need to be made on branches or forks and
>>>> onus
>>>>>> is
>>>>>>>>>> on devs to rebase to master
>>>>>>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from
>> 4.3,
>>>>>>>> 4.4,
>>>>>>>>>> etc)
>>>>>>>>>> -from there forward only maintain a linear release through master
>>>>>>>>>>
>>>>>>>>>> Feel free to add, tweak
>>>>>>>>>>
>>>>>>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>>>>>>>> members,
>>>>>>>>>> votes should be avoided at all cost, they mean that we do not have
>>>>>> clear
>>>>>>>>>> consensus.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>>>>>> runseb@gmail.com
>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com>
>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>>>>>>>>>> Otherwise you should be able to do it cleanly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> There's a good opportunity to do this next release. Instead of
>>>>>>>>>>>>> creating a release branch, we freeze master and start creating
>>>> dev
>>>>>>>>>>>>> branches.
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>
>>>>>>>>>>>> This just amounts to treating master now like a release branch.
>>>>>>>> Getting
>>>>>>>>>> back to PL suggestion, that means
>>>>>>>>>>>> that any commit to master would be through a PR or MERGE request
>>>> on
>>>>>>>> the
>>>>>>>>>> ML. Anything else will be reverted by the RM.
>>>>>>>>>>>>
>>>>>>>>>>>> Marcus, do you feel like writing down a little process for this
>>>> and
>>>>>>>>>> some dates that we can target.
>>>>>>>>>>>> It would be nice to do this for 4.6.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>>>>>>>>>> daan.hoogland@gmail.com> wrote:
>>>>>>>>>>>>>> We heavily invested in code now on master. Not looking forward
>>>> to
>>>>>>>>>>>>>> backporting that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
>>>> own
>>>>>>>>>> risk)
>>>>>>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Well, would we just swap the last release branch with master?
>>>>>>>> Master
>>>>>>>>>>>>>>> is the dev branch, and the last release is really what we
>> have
>>>>>> as a
>>>>>>>>>>>>>>> stable branch.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>>>>>>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>>>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>>>>>>>> pdion@cloudops.com
>>>>>>>>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Today during the CloudStackdays we did a round table
>> about
>>>>>>>>>> Release
>>>>>>>>>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ideas to change release planning
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
>>>>>> plugin
>>>>>>>>>>>>>>> involve
>>>>>>>>>>>>>>>>>> change on the core:
>>>>>>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model
>> which
>>>>>>>> could
>>>>>>>>>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>>>>>>>>>> - Database schema version should be different then the
>>>>>>>> application
>>>>>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
>>>> trigger
>>>>>>>>>>>>>>> simulator
>>>>>>>>>>>>>>>>>> job on PullRequest.
>>>>>>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
>>>> current
>>>>>>>> way
>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> supporting and back porting fixes to multiple release
>>>> (4.3.x,
>>>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>>>>>>>> release
>>>>>>>>>>>>>>> is low,
>>>>>>>>>>>>>>>>>> so that need to be improved.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
>>>> release
>>>>>>>>>>>>>>> velocity, and
>>>>>>>>>>>>>>>>>> release branch stability. so we would like to propose few
>>>>>>>> change
>>>>>>>>>> in
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request
>> or
>>>>>>>> merge
>>>>>>>>>>>>>>> request,
>>>>>>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
>>>> pass
>>>>>>>>>> the PR
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>> be accepted and automatically merged. At this time, I
>> think
>>>>>> we
>>>>>>>>>> pretty
>>>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>>>> have everything in place to do that. At a first step we
>>>> would
>>>>>>>> use
>>>>>>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
>>>> there.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We do need to realize what this means and be all fine with
>>>> it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It means that if someone who is not RM directly commits to
>>>> the
>>>>>>>>>> release
>>>>>>>>>>>>>>> branch, the commit will be reverted.
>>>>>>>>>>>>>>>>> And that from the beginning of the branching…
>>>>>>>>>>>>>>>> I agree and we can even go as far as reverting fixes that
>> are
>>>>>>>>>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think
>> it
>>>>>> goes
>>>>>>>>>> far
>>>>>>>>>>>>>>> enough.
>>>>>>>>>>>>>>>> Agreed here as well but let's take the step while discussing
>>>>>>>> further
>>>>>>>>>>>>>>>> steps and not implement to much process as well
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This still uses a paradigm where a release is made from a
>>>>>> release
>>>>>>>>>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>>>>>>>>>> The problem here is that there is no stable point to fork
>> from
>>>>>> at
>>>>>>>>>> the
>>>>>>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
>>>> in
>>>>>>>> that
>>>>>>>>>>>>>>>> direction.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If we truly want to release faster, we need to release from
>>>> the
>>>>>>>>>> same
>>>>>>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
>>>>>>>>>> previous
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
>>>> the
>>>>>>>>>> added
>>>>>>>>>>>>>>> benefit to not leave releases behind and have to focus on
>>>>>>>>>> backporting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Please comments :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Daan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
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: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
I'm fine with that: rm must have a reviewer on merges? Seem heavy for
trivial changes but alright
On Mon, 11 May 2015 14:16 Sebastien Goasguen <ru...@gmail.com> wrote:
>
> > On May 11, 2015, at 2:00 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> >
> > +1 how about my proposal to have 6 RM and demand that at least 2 agree on
> > each PR?
>
> +0.5
>
> we can say that we need two pairs of eyes to ok the PR for merge.
> no need to formally have 6 RMs ?
>
> so 1 RM (you or me) + another pair of eyes would work ?
>
> >
> > Op ma 11 mei 2015 om 09:52 schreef sebgoa <ru...@gmail.com>:
> >
> >>
> >> On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
> >> wrote:
> >>
> >>> I can have a look at the merge of 4.5.1 and am willing to be one of the
> >>> RMs, not to be the RM!
> >>>
> >>
> >> I can RM as well.
> >>
> >> How about we lock down master on wednesday ?
> >> From that point forward we only take PR into master -either you or me-
> all
> >> other direct commits to master will be reverted !!!!
> >>
> >>
> >> -sebastien
> >>
> >>
> >>
> >>> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
> >>>
> >>>> So no -1 on this.
> >>>>
> >>>> Do we have volunteers to RM 4.6 on the master branch ?
> >>>>
> >>>> I propose to set a date asap, tag master and tell everyone that
> starting
> >>>> from that tag all commits to master except from RM will be reverted.
> >>>>
> >>>> will need to make sure that all of 4.5.1 is in master
> >>>>
> >>>> -sebastien
> >>>>
> >>>>
> >>>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Let's not do more quality improvement proces but just improve
> quality.
> >> If
> >>>>> anybody want to add to the pages on the wiki, you're welkom but
> nobody
> >>>> did
> >>>>> for long time. +1 for the present state of Sebastien's views on
> things.
> >>>> We
> >>>>> can refine at any time.
> >>>>>
> >>>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
> >>>>>
> >>>>>>
> >>>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> In my mind it was kind of making more sense to start by keeping 4.6
> >>>> into
> >>>>>> a
> >>>>>>> separate branch, enforce pull-requests and deploy the CI. smaller
> >> step
> >>>>>> but
> >>>>>>> faster result, and from there, once we get stable with the CI
> >>>>>>
> >>>>>> I hear you.
> >>>>>>
> >>>>>> But we have waited for way too long for better CI. I see great
> efforts
> >>>> in
> >>>>>> that direction.
> >>>>>> But I personally do not want to wait any longer to make a move.
> >>>>>>
> >>>>>> We do open source, we should have fun, take risks, move fast, fail
> >> fast,
> >>>>>> recover etc….
> >>>>>>
> >>>>>> so let's JFDI
> >>>>>>
> >>>>>>> and git flow;
> >>>>>>> move into master, do fastest releases cycle. If we consider we can
> do
> >>>> all
> >>>>>>> that starting in 4.6, I'm all for it!
> >>>>>>
> >>>>>>
> >>>>>> Is there really a difference between creating a 4.6 and doing what
> you
> >>>>>> say, and tagging master (start) and doing it on master leading to
> 4.6
> >>>>>> release ?
> >>>>>>
> >>>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5.
> If
> >> we
> >>>>>> can improve a bit on the QA then we win.
> >>>>>> Plus I think a different commit model will help a lot in quality.
> >>>>>>
> >>>>>>>
> >>>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
> >>>>>>>
> >>>>>>
> >>>>>> We can do this proposal on email..and once we have consensus write
> it
> >> up
> >>>>>> for archive in the wiki.
> >>>>>> If we move to the wiki now, this effort is going to die.
> >>>>>>
> >>>>>>> Seb: doesn't the vote would confirm the consensus?
> >>>>>>>
> >>>>>>
> >>>>>> if we have consensus no need for vote.
> >>>>>>
> >>>>>>> Raja: do we have any documentation somewhere on how to use,
> >> contribute
> >>>>>> to
> >>>>>>> the smoke test? that could be our start for the CI tests?
> >>>>>>>
> >>>>>>>
> >>>>>>> Cheers
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
> >> runseb@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> After reviewing the history as mentioned by Daan, unless we
> propose
> >>>>>>>>> and vote on a newer workflow model I think the best we can do is
> to
> >>>>>>>>> simply be more strict about commits to master. They all need to
> be
> >>>>>>>>> merges that have been tested against master before merge. This
> will
> >>>> in
> >>>>>>>>> theory make master more stable, but doesn't really change the
> >>>> workflow
> >>>>>>>>> we've already agreed upon and have been working under (although
> >>>>>>>>> bugfixes sometimes were not coming in from branches, and
> >>>> cherry-picked
> >>>>>>>>> bugfixes from branches will need to go into a branch first,
> tested
> >>>>>>>>> against master, and merged to master). We can essentially set a
> >> date
> >>>>>>>>> and do that any time, with some advance notice that direct
> commits
> >>>>>>>>> will be reverted.
> >>>>>>>>
> >>>>>>>> Yes +1.
> >>>>>>>>
> >>>>>>>> -Set a date
> >>>>>>>> -Tag master for reference
> >>>>>>>> -Find a volunteer or two to RM master
> >>>>>>>> -automatic revert on master if not from RM
> >>>>>>>> -all commits to master come from PR, need clear review and green
> >> tests
> >>>>>>>> -harden master (basic QA process), release 4.6 as a tag on master
> >>>>>>>> -all features and fixes need to be made on branches or forks and
> >> onus
> >>>> is
> >>>>>>>> on devs to rebase to master
> >>>>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from
> 4.3,
> >>>>>> 4.4,
> >>>>>>>> etc)
> >>>>>>>> -from there forward only maintain a linear release through master
> >>>>>>>>
> >>>>>>>> Feel free to add, tweak
> >>>>>>>>
> >>>>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
> >>>>>> members,
> >>>>>>>> votes should be avoided at all cost, they mean that we do not have
> >>>> clear
> >>>>>>>> consensus.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
> >>>> runseb@gmail.com
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com>
> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >>>>>>>>>>> Otherwise you should be able to do it cleanly.
> >>>>>>>>>>>
> >>>>>>>>>>> There's a good opportunity to do this next release. Instead of
> >>>>>>>>>>> creating a release branch, we freeze master and start creating
> >> dev
> >>>>>>>>>>> branches.
> >>>>>>>>>>
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>> This just amounts to treating master now like a release branch.
> >>>>>> Getting
> >>>>>>>> back to PL suggestion, that means
> >>>>>>>>>> that any commit to master would be through a PR or MERGE request
> >> on
> >>>>>> the
> >>>>>>>> ML. Anything else will be reverted by the RM.
> >>>>>>>>>>
> >>>>>>>>>> Marcus, do you feel like writing down a little process for this
> >> and
> >>>>>>>> some dates that we can target.
> >>>>>>>>>> It would be nice to do this for 4.6.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >>>>>>>> daan.hoogland@gmail.com> wrote:
> >>>>>>>>>>>> We heavily invested in code now on master. Not looking forward
> >> to
> >>>>>>>>>>>> backporting that.
> >>>>>>>>>>>>
> >>>>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
> >> own
> >>>>>>>> risk)
> >>>>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Well, would we just swap the last release branch with master?
> >>>>>> Master
> >>>>>>>>>>>>> is the dev branch, and the last release is really what we
> have
> >>>> as a
> >>>>>>>>>>>>> stable branch.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >>>>>>>> daan.hoogland@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >>>>>>>> runseb@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> >>>>>> pdion@cloudops.com
> >>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Today during the CloudStackdays we did a round table
> about
> >>>>>>>> Release
> >>>>>>>>>>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Quick bullet point discussions:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ideas to change release planning
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
> >>>> plugin
> >>>>>>>>>>>>> involve
> >>>>>>>>>>>>>>>> change on the core:
> >>>>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model
> which
> >>>>>> could
> >>>>>>>>>>>>>>>> introduce issue the database schema.
> >>>>>>>>>>>>>>>> - Database schema version should be different then the
> >>>>>> application
> >>>>>>>>>>>>>>>> version.
> >>>>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
> >> trigger
> >>>>>>>>>>>>> simulator
> >>>>>>>>>>>>>>>> job on PullRequest.
> >>>>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
> >> current
> >>>>>> way
> >>>>>>>> of
> >>>>>>>>>>>>>>>> supporting and back porting fixes to multiple release
> >> (4.3.x,
> >>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
> >>>>>> release
> >>>>>>>>>>>>> is low,
> >>>>>>>>>>>>>>>> so that need to be improved.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
> >> release
> >>>>>>>>>>>>> velocity, and
> >>>>>>>>>>>>>>>> release branch stability. so we would like to propose few
> >>>>>> change
> >>>>>>>> in
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request
> or
> >>>>>> merge
> >>>>>>>>>>>>> request,
> >>>>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
> >> pass
> >>>>>>>> the PR
> >>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>> be accepted and automatically merged. At this time, I
> think
> >>>> we
> >>>>>>>> pretty
> >>>>>>>>>>>>> much
> >>>>>>>>>>>>>>>> have everything in place to do that. At a first step we
> >> would
> >>>>>> use
> >>>>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
> >> there.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We do need to realize what this means and be all fine with
> >> it.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It means that if someone who is not RM directly commits to
> >> the
> >>>>>>>> release
> >>>>>>>>>>>>> branch, the commit will be reverted.
> >>>>>>>>>>>>>>> And that from the beginning of the branching…
> >>>>>>>>>>>>>> I agree and we can even go as far as reverting fixes that
> are
> >>>>>>>>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think
> it
> >>>> goes
> >>>>>>>> far
> >>>>>>>>>>>>> enough.
> >>>>>>>>>>>>>> Agreed here as well but let's take the step while discussing
> >>>>>> further
> >>>>>>>>>>>>>> steps and not implement to much process as well
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This still uses a paradigm where a release is made from a
> >>>> release
> >>>>>>>>>>>>> branch that was started from an unstable development branch.
> >>>>>>>>>>>>>>> Hence you still need *extensive* QA.
> >>>>>>>>>>>>>> The problem here is that there is no stable point to fork
> from
> >>>> at
> >>>>>>>> the
> >>>>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
> >> in
> >>>>>> that
> >>>>>>>>>>>>>> direction.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If we truly want to release faster, we need to release from
> >> the
> >>>>>>>> same
> >>>>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
> >>>>>>>> previous
> >>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
> >> the
> >>>>>>>> added
> >>>>>>>>>>>>> benefit to not leave releases behind and have to focus on
> >>>>>>>> backporting.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Please comments :-)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Daan
> >>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On May 11, 2015, at 2:00 PM, Daan Hoogland <da...@gmail.com> wrote:
>
> +1 how about my proposal to have 6 RM and demand that at least 2 agree on
> each PR?
+0.5
we can say that we need two pairs of eyes to ok the PR for merge.
no need to formally have 6 RMs ?
so 1 RM (you or me) + another pair of eyes would work ?
>
> Op ma 11 mei 2015 om 09:52 schreef sebgoa <ru...@gmail.com>:
>
>>
>> On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>
>>> I can have a look at the merge of 4.5.1 and am willing to be one of the
>>> RMs, not to be the RM!
>>>
>>
>> I can RM as well.
>>
>> How about we lock down master on wednesday ?
>> From that point forward we only take PR into master -either you or me- all
>> other direct commits to master will be reverted !!!!
>>
>>
>> -sebastien
>>
>>
>>
>>> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>>>
>>>> So no -1 on this.
>>>>
>>>> Do we have volunteers to RM 4.6 on the master branch ?
>>>>
>>>> I propose to set a date asap, tag master and tell everyone that starting
>>>> from that tag all commits to master except from RM will be reverted.
>>>>
>>>> will need to make sure that all of 4.5.1 is in master
>>>>
>>>> -sebastien
>>>>
>>>>
>>>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>>>
>>>>> Let's not do more quality improvement proces but just improve quality.
>> If
>>>>> anybody want to add to the pages on the wiki, you're welkom but nobody
>>>> did
>>>>> for long time. +1 for the present state of Sebastien's views on things.
>>>> We
>>>>> can refine at any time.
>>>>>
>>>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>>>>>
>>>>>>
>>>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> In my mind it was kind of making more sense to start by keeping 4.6
>>>> into
>>>>>> a
>>>>>>> separate branch, enforce pull-requests and deploy the CI. smaller
>> step
>>>>>> but
>>>>>>> faster result, and from there, once we get stable with the CI
>>>>>>
>>>>>> I hear you.
>>>>>>
>>>>>> But we have waited for way too long for better CI. I see great efforts
>>>> in
>>>>>> that direction.
>>>>>> But I personally do not want to wait any longer to make a move.
>>>>>>
>>>>>> We do open source, we should have fun, take risks, move fast, fail
>> fast,
>>>>>> recover etc….
>>>>>>
>>>>>> so let's JFDI
>>>>>>
>>>>>>> and git flow;
>>>>>>> move into master, do fastest releases cycle. If we consider we can do
>>>> all
>>>>>>> that starting in 4.6, I'm all for it!
>>>>>>
>>>>>>
>>>>>> Is there really a difference between creating a 4.6 and doing what you
>>>>>> say, and tagging master (start) and doing it on master leading to 4.6
>>>>>> release ?
>>>>>>
>>>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If
>> we
>>>>>> can improve a bit on the QA then we win.
>>>>>> Plus I think a different commit model will help a lot in quality.
>>>>>>
>>>>>>>
>>>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>>>>>>>
>>>>>>
>>>>>> We can do this proposal on email..and once we have consensus write it
>> up
>>>>>> for archive in the wiki.
>>>>>> If we move to the wiki now, this effort is going to die.
>>>>>>
>>>>>>> Seb: doesn't the vote would confirm the consensus?
>>>>>>>
>>>>>>
>>>>>> if we have consensus no need for vote.
>>>>>>
>>>>>>> Raja: do we have any documentation somewhere on how to use,
>> contribute
>>>>>> to
>>>>>>> the smoke test? that could be our start for the CI tests?
>>>>>>>
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
>> runseb@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> After reviewing the history as mentioned by Daan, unless we propose
>>>>>>>>> and vote on a newer workflow model I think the best we can do is to
>>>>>>>>> simply be more strict about commits to master. They all need to be
>>>>>>>>> merges that have been tested against master before merge. This will
>>>> in
>>>>>>>>> theory make master more stable, but doesn't really change the
>>>> workflow
>>>>>>>>> we've already agreed upon and have been working under (although
>>>>>>>>> bugfixes sometimes were not coming in from branches, and
>>>> cherry-picked
>>>>>>>>> bugfixes from branches will need to go into a branch first, tested
>>>>>>>>> against master, and merged to master). We can essentially set a
>> date
>>>>>>>>> and do that any time, with some advance notice that direct commits
>>>>>>>>> will be reverted.
>>>>>>>>
>>>>>>>> Yes +1.
>>>>>>>>
>>>>>>>> -Set a date
>>>>>>>> -Tag master for reference
>>>>>>>> -Find a volunteer or two to RM master
>>>>>>>> -automatic revert on master if not from RM
>>>>>>>> -all commits to master come from PR, need clear review and green
>> tests
>>>>>>>> -harden master (basic QA process), release 4.6 as a tag on master
>>>>>>>> -all features and fixes need to be made on branches or forks and
>> onus
>>>> is
>>>>>>>> on devs to rebase to master
>>>>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
>>>>>> 4.4,
>>>>>>>> etc)
>>>>>>>> -from there forward only maintain a linear release through master
>>>>>>>>
>>>>>>>> Feel free to add, tweak
>>>>>>>>
>>>>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>>>>>> members,
>>>>>>>> votes should be avoided at all cost, they mean that we do not have
>>>> clear
>>>>>>>> consensus.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>>>> runseb@gmail.com
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>>>>>>>> Otherwise you should be able to do it cleanly.
>>>>>>>>>>>
>>>>>>>>>>> There's a good opportunity to do this next release. Instead of
>>>>>>>>>>> creating a release branch, we freeze master and start creating
>> dev
>>>>>>>>>>> branches.
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>> This just amounts to treating master now like a release branch.
>>>>>> Getting
>>>>>>>> back to PL suggestion, that means
>>>>>>>>>> that any commit to master would be through a PR or MERGE request
>> on
>>>>>> the
>>>>>>>> ML. Anything else will be reverted by the RM.
>>>>>>>>>>
>>>>>>>>>> Marcus, do you feel like writing down a little process for this
>> and
>>>>>>>> some dates that we can target.
>>>>>>>>>> It would be nice to do this for 4.6.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>>>>>>>> daan.hoogland@gmail.com> wrote:
>>>>>>>>>>>> We heavily invested in code now on master. Not looking forward
>> to
>>>>>>>>>>>> backporting that.
>>>>>>>>>>>>
>>>>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
>> own
>>>>>>>> risk)
>>>>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Well, would we just swap the last release branch with master?
>>>>>> Master
>>>>>>>>>>>>> is the dev branch, and the last release is really what we have
>>>> as a
>>>>>>>>>>>>> stable branch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>>>>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>>>>>>>> runseb@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>>>>>> pdion@cloudops.com
>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>>>>>>>> Release
>>>>>>>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ideas to change release planning
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
>>>> plugin
>>>>>>>>>>>>> involve
>>>>>>>>>>>>>>>> change on the core:
>>>>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
>>>>>> could
>>>>>>>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>>>>>>>> - Database schema version should be different then the
>>>>>> application
>>>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
>> trigger
>>>>>>>>>>>>> simulator
>>>>>>>>>>>>>>>> job on PullRequest.
>>>>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
>> current
>>>>>> way
>>>>>>>> of
>>>>>>>>>>>>>>>> supporting and back porting fixes to multiple release
>> (4.3.x,
>>>>>>>> 4.4.x,
>>>>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>>>>>> release
>>>>>>>>>>>>> is low,
>>>>>>>>>>>>>>>> so that need to be improved.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
>> release
>>>>>>>>>>>>> velocity, and
>>>>>>>>>>>>>>>> release branch stability. so we would like to propose few
>>>>>> change
>>>>>>>> in
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>>>>>> merge
>>>>>>>>>>>>> request,
>>>>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
>> pass
>>>>>>>> the PR
>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>> be accepted and automatically merged. At this time, I think
>>>> we
>>>>>>>> pretty
>>>>>>>>>>>>> much
>>>>>>>>>>>>>>>> have everything in place to do that. At a first step we
>> would
>>>>>> use
>>>>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
>> there.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We do need to realize what this means and be all fine with
>> it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It means that if someone who is not RM directly commits to
>> the
>>>>>>>> release
>>>>>>>>>>>>> branch, the commit will be reverted.
>>>>>>>>>>>>>>> And that from the beginning of the branching…
>>>>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>>>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
>>>> goes
>>>>>>>> far
>>>>>>>>>>>>> enough.
>>>>>>>>>>>>>> Agreed here as well but let's take the step while discussing
>>>>>> further
>>>>>>>>>>>>>> steps and not implement to much process as well
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This still uses a paradigm where a release is made from a
>>>> release
>>>>>>>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>>>>>>>> The problem here is that there is no stable point to fork from
>>>> at
>>>>>>>> the
>>>>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
>> in
>>>>>> that
>>>>>>>>>>>>>> direction.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we truly want to release faster, we need to release from
>> the
>>>>>>>> same
>>>>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
>>>>>>>> previous
>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
>> the
>>>>>>>> added
>>>>>>>>>>>>> benefit to not leave releases behind and have to focus on
>>>>>>>> backporting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please comments :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Daan
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
+1 how about my proposal to have 6 RM and demand that at least 2 agree on
each PR?
Op ma 11 mei 2015 om 09:52 schreef sebgoa <ru...@gmail.com>:
>
> On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
> wrote:
>
> > I can have a look at the merge of 4.5.1 and am willing to be one of the
> > RMs, not to be the RM!
> >
>
> I can RM as well.
>
> How about we lock down master on wednesday ?
> From that point forward we only take PR into master -either you or me- all
> other direct commits to master will be reverted !!!!
>
>
> -sebastien
>
>
>
> > Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
> >
> >> So no -1 on this.
> >>
> >> Do we have volunteers to RM 4.6 on the master branch ?
> >>
> >> I propose to set a date asap, tag master and tell everyone that starting
> >> from that tag all commits to master except from RM will be reverted.
> >>
> >> will need to make sure that all of 4.5.1 is in master
> >>
> >> -sebastien
> >>
> >>
> >> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> >>
> >>> Let's not do more quality improvement proces but just improve quality.
> If
> >>> anybody want to add to the pages on the wiki, you're welkom but nobody
> >> did
> >>> for long time. +1 for the present state of Sebastien's views on things.
> >> We
> >>> can refine at any time.
> >>>
> >>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
> >>>
> >>>>
> >>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> In my mind it was kind of making more sense to start by keeping 4.6
> >> into
> >>>> a
> >>>>> separate branch, enforce pull-requests and deploy the CI. smaller
> step
> >>>> but
> >>>>> faster result, and from there, once we get stable with the CI
> >>>>
> >>>> I hear you.
> >>>>
> >>>> But we have waited for way too long for better CI. I see great efforts
> >> in
> >>>> that direction.
> >>>> But I personally do not want to wait any longer to make a move.
> >>>>
> >>>> We do open source, we should have fun, take risks, move fast, fail
> fast,
> >>>> recover etc….
> >>>>
> >>>> so let's JFDI
> >>>>
> >>>>> and git flow;
> >>>>> move into master, do fastest releases cycle. If we consider we can do
> >> all
> >>>>> that starting in 4.6, I'm all for it!
> >>>>
> >>>>
> >>>> Is there really a difference between creating a 4.6 and doing what you
> >>>> say, and tagging master (start) and doing it on master leading to 4.6
> >>>> release ?
> >>>>
> >>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If
> we
> >>>> can improve a bit on the QA then we win.
> >>>> Plus I think a different commit model will help a lot in quality.
> >>>>
> >>>>>
> >>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
> >>>>>
> >>>>
> >>>> We can do this proposal on email..and once we have consensus write it
> up
> >>>> for archive in the wiki.
> >>>> If we move to the wiki now, this effort is going to die.
> >>>>
> >>>>> Seb: doesn't the vote would confirm the consensus?
> >>>>>
> >>>>
> >>>> if we have consensus no need for vote.
> >>>>
> >>>>> Raja: do we have any documentation somewhere on how to use,
> contribute
> >>>> to
> >>>>> the smoke test? that could be our start for the CI tests?
> >>>>>
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> After reviewing the history as mentioned by Daan, unless we propose
> >>>>>>> and vote on a newer workflow model I think the best we can do is to
> >>>>>>> simply be more strict about commits to master. They all need to be
> >>>>>>> merges that have been tested against master before merge. This will
> >> in
> >>>>>>> theory make master more stable, but doesn't really change the
> >> workflow
> >>>>>>> we've already agreed upon and have been working under (although
> >>>>>>> bugfixes sometimes were not coming in from branches, and
> >> cherry-picked
> >>>>>>> bugfixes from branches will need to go into a branch first, tested
> >>>>>>> against master, and merged to master). We can essentially set a
> date
> >>>>>>> and do that any time, with some advance notice that direct commits
> >>>>>>> will be reverted.
> >>>>>>
> >>>>>> Yes +1.
> >>>>>>
> >>>>>> -Set a date
> >>>>>> -Tag master for reference
> >>>>>> -Find a volunteer or two to RM master
> >>>>>> -automatic revert on master if not from RM
> >>>>>> -all commits to master come from PR, need clear review and green
> tests
> >>>>>> -harden master (basic QA process), release 4.6 as a tag on master
> >>>>>> -all features and fixes need to be made on branches or forks and
> onus
> >> is
> >>>>>> on devs to rebase to master
> >>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
> >>>> 4.4,
> >>>>>> etc)
> >>>>>> -from there forward only maintain a linear release through master
> >>>>>>
> >>>>>> Feel free to add, tweak
> >>>>>>
> >>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
> >>>> members,
> >>>>>> votes should be avoided at all cost, they mean that we do not have
> >> clear
> >>>>>> consensus.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >>>>>>>>> Otherwise you should be able to do it cleanly.
> >>>>>>>>>
> >>>>>>>>> There's a good opportunity to do this next release. Instead of
> >>>>>>>>> creating a release branch, we freeze master and start creating
> dev
> >>>>>>>>> branches.
> >>>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> This just amounts to treating master now like a release branch.
> >>>> Getting
> >>>>>> back to PL suggestion, that means
> >>>>>>>> that any commit to master would be through a PR or MERGE request
> on
> >>>> the
> >>>>>> ML. Anything else will be reverted by the RM.
> >>>>>>>>
> >>>>>>>> Marcus, do you feel like writing down a little process for this
> and
> >>>>>> some dates that we can target.
> >>>>>>>> It would be nice to do this for 4.6.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >>>>>> daan.hoogland@gmail.com> wrote:
> >>>>>>>>>> We heavily invested in code now on master. Not looking forward
> to
> >>>>>>>>>> backporting that.
> >>>>>>>>>>
> >>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
> own
> >>>>>> risk)
> >>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>>> Well, would we just swap the last release branch with master?
> >>>> Master
> >>>>>>>>>>> is the dev branch, and the last release is really what we have
> >> as a
> >>>>>>>>>>> stable branch.
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >>>>>> daan.hoogland@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >>>>>> runseb@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> >>>> pdion@cloudops.com
> >>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
> >>>>>> Release
> >>>>>>>>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Quick bullet point discussions:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ideas to change release planning
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
> >> plugin
> >>>>>>>>>>> involve
> >>>>>>>>>>>>>> change on the core:
> >>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
> >>>> could
> >>>>>>>>>>>>>> introduce issue the database schema.
> >>>>>>>>>>>>>> - Database schema version should be different then the
> >>>> application
> >>>>>>>>>>>>>> version.
> >>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
> trigger
> >>>>>>>>>>> simulator
> >>>>>>>>>>>>>> job on PullRequest.
> >>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
> current
> >>>> way
> >>>>>> of
> >>>>>>>>>>>>>> supporting and back porting fixes to multiple release
> (4.3.x,
> >>>>>> 4.4.x,
> >>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
> >>>> release
> >>>>>>>>>>> is low,
> >>>>>>>>>>>>>> so that need to be improved.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
> release
> >>>>>>>>>>> velocity, and
> >>>>>>>>>>>>>> release branch stability. so we would like to propose few
> >>>> change
> >>>>>> in
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
> >>>> merge
> >>>>>>>>>>> request,
> >>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
> pass
> >>>>>> the PR
> >>>>>>>>>>> would
> >>>>>>>>>>>>>> be accepted and automatically merged. At this time, I think
> >> we
> >>>>>> pretty
> >>>>>>>>>>> much
> >>>>>>>>>>>>>> have everything in place to do that. At a first step we
> would
> >>>> use
> >>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
> there.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We do need to realize what this means and be all fine with
> it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It means that if someone who is not RM directly commits to
> the
> >>>>>> release
> >>>>>>>>>>> branch, the commit will be reverted.
> >>>>>>>>>>>>> And that from the beginning of the branching…
> >>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
> >>>>>>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
> >> goes
> >>>>>> far
> >>>>>>>>>>> enough.
> >>>>>>>>>>>> Agreed here as well but let's take the step while discussing
> >>>> further
> >>>>>>>>>>>> steps and not implement to much process as well
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This still uses a paradigm where a release is made from a
> >> release
> >>>>>>>>>>> branch that was started from an unstable development branch.
> >>>>>>>>>>>>> Hence you still need *extensive* QA.
> >>>>>>>>>>>> The problem here is that there is no stable point to fork from
> >> at
> >>>>>> the
> >>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
> in
> >>>> that
> >>>>>>>>>>>> direction.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we truly want to release faster, we need to release from
> the
> >>>>>> same
> >>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
> >>>>>> previous
> >>>>>>>>>>> release
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
> the
> >>>>>> added
> >>>>>>>>>>> benefit to not leave releases behind and have to focus on
> >>>>>> backporting.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please comments :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Daan
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com> wrote:
> I can have a look at the merge of 4.5.1 and am willing to be one of the
> RMs, not to be the RM!
>
I can RM as well.
How about we lock down master on wednesday ?
From that point forward we only take PR into master -either you or me- all other direct commits to master will be reverted !!!!
-sebastien
> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>
>> So no -1 on this.
>>
>> Do we have volunteers to RM 4.6 on the master branch ?
>>
>> I propose to set a date asap, tag master and tell everyone that starting
>> from that tag all commits to master except from RM will be reverted.
>>
>> will need to make sure that all of 4.5.1 is in master
>>
>> -sebastien
>>
>>
>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com> wrote:
>>
>>> Let's not do more quality improvement proces but just improve quality. If
>>> anybody want to add to the pages on the wiki, you're welkom but nobody
>> did
>>> for long time. +1 for the present state of Sebastien's views on things.
>> We
>>> can refine at any time.
>>>
>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>>>
>>>>
>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In my mind it was kind of making more sense to start by keeping 4.6
>> into
>>>> a
>>>>> separate branch, enforce pull-requests and deploy the CI. smaller step
>>>> but
>>>>> faster result, and from there, once we get stable with the CI
>>>>
>>>> I hear you.
>>>>
>>>> But we have waited for way too long for better CI. I see great efforts
>> in
>>>> that direction.
>>>> But I personally do not want to wait any longer to make a move.
>>>>
>>>> We do open source, we should have fun, take risks, move fast, fail fast,
>>>> recover etc….
>>>>
>>>> so let's JFDI
>>>>
>>>>> and git flow;
>>>>> move into master, do fastest releases cycle. If we consider we can do
>> all
>>>>> that starting in 4.6, I'm all for it!
>>>>
>>>>
>>>> Is there really a difference between creating a 4.6 and doing what you
>>>> say, and tagging master (start) and doing it on master leading to 4.6
>>>> release ?
>>>>
>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
>>>> can improve a bit on the QA then we win.
>>>> Plus I think a different commit model will help a lot in quality.
>>>>
>>>>>
>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>>>>>
>>>>
>>>> We can do this proposal on email..and once we have consensus write it up
>>>> for archive in the wiki.
>>>> If we move to the wiki now, this effort is going to die.
>>>>
>>>>> Seb: doesn't the vote would confirm the consensus?
>>>>>
>>>>
>>>> if we have consensus no need for vote.
>>>>
>>>>> Raja: do we have any documentation somewhere on how to use, contribute
>>>> to
>>>>> the smoke test? that could be our start for the CI tests?
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>>
>>>>>>> After reviewing the history as mentioned by Daan, unless we propose
>>>>>>> and vote on a newer workflow model I think the best we can do is to
>>>>>>> simply be more strict about commits to master. They all need to be
>>>>>>> merges that have been tested against master before merge. This will
>> in
>>>>>>> theory make master more stable, but doesn't really change the
>> workflow
>>>>>>> we've already agreed upon and have been working under (although
>>>>>>> bugfixes sometimes were not coming in from branches, and
>> cherry-picked
>>>>>>> bugfixes from branches will need to go into a branch first, tested
>>>>>>> against master, and merged to master). We can essentially set a date
>>>>>>> and do that any time, with some advance notice that direct commits
>>>>>>> will be reverted.
>>>>>>
>>>>>> Yes +1.
>>>>>>
>>>>>> -Set a date
>>>>>> -Tag master for reference
>>>>>> -Find a volunteer or two to RM master
>>>>>> -automatic revert on master if not from RM
>>>>>> -all commits to master come from PR, need clear review and green tests
>>>>>> -harden master (basic QA process), release 4.6 as a tag on master
>>>>>> -all features and fixes need to be made on branches or forks and onus
>> is
>>>>>> on devs to rebase to master
>>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
>>>> 4.4,
>>>>>> etc)
>>>>>> -from there forward only maintain a linear release through master
>>>>>>
>>>>>> Feel free to add, tweak
>>>>>>
>>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>>>> members,
>>>>>> votes should be avoided at all cost, they mean that we do not have
>> clear
>>>>>> consensus.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>> runseb@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>>>>>> Otherwise you should be able to do it cleanly.
>>>>>>>>>
>>>>>>>>> There's a good opportunity to do this next release. Instead of
>>>>>>>>> creating a release branch, we freeze master and start creating dev
>>>>>>>>> branches.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> This just amounts to treating master now like a release branch.
>>>> Getting
>>>>>> back to PL suggestion, that means
>>>>>>>> that any commit to master would be through a PR or MERGE request on
>>>> the
>>>>>> ML. Anything else will be reverted by the RM.
>>>>>>>>
>>>>>>>> Marcus, do you feel like writing down a little process for this and
>>>>>> some dates that we can target.
>>>>>>>> It would be nice to do this for 4.6.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>>>>>> daan.hoogland@gmail.com> wrote:
>>>>>>>>>> We heavily invested in code now on master. Not looking forward to
>>>>>>>>>> backporting that.
>>>>>>>>>>
>>>>>>>>>> mobile dev with bilingual spelling checker used (read at your own
>>>>>> risk)
>>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Well, would we just swap the last release branch with master?
>>>> Master
>>>>>>>>>>> is the dev branch, and the last release is really what we have
>> as a
>>>>>>>>>>> stable branch.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>>>>>> runseb@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>>>> pdion@cloudops.com
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>>>>>> Release
>>>>>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ideas to change release planning
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
>> plugin
>>>>>>>>>>> involve
>>>>>>>>>>>>>> change on the core:
>>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
>>>> could
>>>>>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>>>>>> - Database schema version should be different then the
>>>> application
>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>>>>>>>> simulator
>>>>>>>>>>>>>> job on PullRequest.
>>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our current
>>>> way
>>>>>> of
>>>>>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
>>>>>> 4.4.x,
>>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>>>> release
>>>>>>>>>>> is low,
>>>>>>>>>>>>>> so that need to be improved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>>>>>>>> velocity, and
>>>>>>>>>>>>>> release branch stability. so we would like to propose few
>>>> change
>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>>>> merge
>>>>>>>>>>> request,
>>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that pass
>>>>>> the PR
>>>>>>>>>>> would
>>>>>>>>>>>>>> be accepted and automatically merged. At this time, I think
>> we
>>>>>> pretty
>>>>>>>>>>> much
>>>>>>>>>>>>>> have everything in place to do that. At a first step we would
>>>> use
>>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It means that if someone who is not RM directly commits to the
>>>>>> release
>>>>>>>>>>> branch, the commit will be reverted.
>>>>>>>>>>>>> And that from the beginning of the branching…
>>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
>> goes
>>>>>> far
>>>>>>>>>>> enough.
>>>>>>>>>>>> Agreed here as well but let's take the step while discussing
>>>> further
>>>>>>>>>>>> steps and not implement to much process as well
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This still uses a paradigm where a release is made from a
>> release
>>>>>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>>>>>> The problem here is that there is no stable point to fork from
>> at
>>>>>> the
>>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps in
>>>> that
>>>>>>>>>>>> direction.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we truly want to release faster, we need to release from the
>>>>>> same
>>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
>>>>>> previous
>>>>>>>>>>> release
>>>>>>>>>>>>>
>>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have the
>>>>>> added
>>>>>>>>>>> benefit to not leave releases behind and have to focus on
>>>>>> backporting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please comments :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Daan
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
I just did a test merge:
~/cloudstack/cloudstack (master)> git merge --no-ff --edit -s ours 4.5
gives a clean merge of the last bits from 4.5 and merges without conflicts
I will rerun a merge and push if the RC passes
Op wo 6 mei 2015 om 10:59 schreef Daan Hoogland <da...@gmail.com>:
> I can have a look at the merge of 4.5.1 and am willing to be one of the
> RMs, not to be the RM!
>
> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>
> So no -1 on this.
>>
>> Do we have volunteers to RM 4.6 on the master branch ?
>>
>> I propose to set a date asap, tag master and tell everyone that starting
>> from that tag all commits to master except from RM will be reverted.
>>
>> will need to make sure that all of 4.5.1 is in master
>>
>> -sebastien
>>
>>
>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
>> wrote:
>>
>> > Let's not do more quality improvement proces but just improve quality.
>> If
>> > anybody want to add to the pages on the wiki, you're welkom but nobody
>> did
>> > for long time. +1 for the present state of Sebastien's views on things.
>> We
>> > can refine at any time.
>> >
>> > Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>> >
>> >>
>> >> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> In my mind it was kind of making more sense to start by keeping 4.6
>> into
>> >> a
>> >>> separate branch, enforce pull-requests and deploy the CI. smaller step
>> >> but
>> >>> faster result, and from there, once we get stable with the CI
>> >>
>> >> I hear you.
>> >>
>> >> But we have waited for way too long for better CI. I see great efforts
>> in
>> >> that direction.
>> >> But I personally do not want to wait any longer to make a move.
>> >>
>> >> We do open source, we should have fun, take risks, move fast, fail
>> fast,
>> >> recover etc….
>> >>
>> >> so let's JFDI
>> >>
>> >>> and git flow;
>> >>> move into master, do fastest releases cycle. If we consider we can do
>> all
>> >>> that starting in 4.6, I'm all for it!
>> >>
>> >>
>> >> Is there really a difference between creating a 4.6 and doing what you
>> >> say, and tagging master (start) and doing it on master leading to 4.6
>> >> release ?
>> >>
>> >> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If
>> we
>> >> can improve a bit on the QA then we win.
>> >> Plus I think a different commit model will help a lot in quality.
>> >>
>> >>>
>> >>> Marcus: are you preparing a proposal on this? wiki page? I can help
>> >>>
>> >>
>> >> We can do this proposal on email..and once we have consensus write it
>> up
>> >> for archive in the wiki.
>> >> If we move to the wiki now, this effort is going to die.
>> >>
>> >>> Seb: doesn't the vote would confirm the consensus?
>> >>>
>> >>
>> >> if we have consensus no need for vote.
>> >>
>> >>> Raja: do we have any documentation somewhere on how to use,
>> contribute
>> >> to
>> >>> the smoke test? that could be our start for the CI tests?
>> >>>
>> >>>
>> >>> Cheers
>> >>>
>> >>>
>> >>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <runseb@gmail.com
>> >
>> >>> wrote:
>> >>>
>> >>>>
>> >>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>> >>>>>
>> >>>>> After reviewing the history as mentioned by Daan, unless we propose
>> >>>>> and vote on a newer workflow model I think the best we can do is to
>> >>>>> simply be more strict about commits to master. They all need to be
>> >>>>> merges that have been tested against master before merge. This will
>> in
>> >>>>> theory make master more stable, but doesn't really change the
>> workflow
>> >>>>> we've already agreed upon and have been working under (although
>> >>>>> bugfixes sometimes were not coming in from branches, and
>> cherry-picked
>> >>>>> bugfixes from branches will need to go into a branch first, tested
>> >>>>> against master, and merged to master). We can essentially set a date
>> >>>>> and do that any time, with some advance notice that direct commits
>> >>>>> will be reverted.
>> >>>>
>> >>>> Yes +1.
>> >>>>
>> >>>> -Set a date
>> >>>> -Tag master for reference
>> >>>> -Find a volunteer or two to RM master
>> >>>> -automatic revert on master if not from RM
>> >>>> -all commits to master come from PR, need clear review and green
>> tests
>> >>>> -harden master (basic QA process), release 4.6 as a tag on master
>> >>>> -all features and fixes need to be made on branches or forks and
>> onus is
>> >>>> on devs to rebase to master
>> >>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
>> >> 4.4,
>> >>>> etc)
>> >>>> -from there forward only maintain a linear release through master
>> >>>>
>> >>>> Feel free to add, tweak
>> >>>>
>> >>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>> >> members,
>> >>>> votes should be avoided at all cost, they mean that we do not have
>> clear
>> >>>> consensus.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>> runseb@gmail.com
>> >>>
>> >>>> wrote:
>> >>>>>>
>> >>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>> >>>>>>> Otherwise you should be able to do it cleanly.
>> >>>>>>>
>> >>>>>>> There's a good opportunity to do this next release. Instead of
>> >>>>>>> creating a release branch, we freeze master and start creating dev
>> >>>>>>> branches.
>> >>>>>>
>> >>>>>> +1
>> >>>>>>
>> >>>>>> This just amounts to treating master now like a release branch.
>> >> Getting
>> >>>> back to PL suggestion, that means
>> >>>>>> that any commit to master would be through a PR or MERGE request on
>> >> the
>> >>>> ML. Anything else will be reverted by the RM.
>> >>>>>>
>> >>>>>> Marcus, do you feel like writing down a little process for this and
>> >>>> some dates that we can target.
>> >>>>>> It would be nice to do this for 4.6.
>> >>>>>>
>> >>>>>>>
>> >>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>> >>>> daan.hoogland@gmail.com> wrote:
>> >>>>>>>> We heavily invested in code now on master. Not looking forward to
>> >>>>>>>> backporting that.
>> >>>>>>>>
>> >>>>>>>> mobile dev with bilingual spelling checker used (read at your own
>> >>>> risk)
>> >>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>> >>>>>>>>
>> >>>>>>>>> Well, would we just swap the last release branch with master?
>> >> Master
>> >>>>>>>>> is the dev branch, and the last release is really what we have
>> as a
>> >>>>>>>>> stable branch.
>> >>>>>>>>>
>> >>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>> >>>> daan.hoogland@gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>> >>>> runseb@gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>> >> pdion@cloudops.com
>> >>>>>
>> >>>>>>>>> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>> >>>> Release
>> >>>>>>>>>>>> management targeting the next 4.6 releases.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Quick bullet point discussions:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> ideas to change release planning
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> - Plugin contribution is complicated because often a new
>> plugin
>> >>>>>>>>> involve
>> >>>>>>>>>>>> change on the core:
>> >>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>> >>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
>> >> could
>> >>>>>>>>>>>> introduce issue the database schema.
>> >>>>>>>>>>>> - Database schema version should be different then the
>> >> application
>> >>>>>>>>>>>> version.
>> >>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>> >>>>>>>>> simulator
>> >>>>>>>>>>>> job on PullRequest.
>> >>>>>>>>>>>> - Some people (I'm part of them) are concerned on our current
>> >> way
>> >>>> of
>> >>>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
>> >>>> 4.4.x,
>> >>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>> >> release
>> >>>>>>>>> is low,
>> >>>>>>>>>>>> so that need to be improved.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> So, the main messages is that w'd like to improve the release
>> >>>>>>>>> velocity, and
>> >>>>>>>>>>>> release branch stability. so we would like to propose few
>> >> change
>> >>>> in
>> >>>>>>>>> the
>> >>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>> >> merge
>> >>>>>>>>> request,
>> >>>>>>>>>>>> which would trigger a simulator job, ideally only if that
>> pass
>> >>>> the PR
>> >>>>>>>>> would
>> >>>>>>>>>>>> be accepted and automatically merged. At this time, I think
>> we
>> >>>> pretty
>> >>>>>>>>> much
>> >>>>>>>>>>>> have everything in place to do that. At a first step we would
>> >> use
>> >>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>> >>>>>>>>>>>
>> >>>>>>>>>>> +1
>> >>>>>>>>>>>
>> >>>>>>>>>>> We do need to realize what this means and be all fine with it.
>> >>>>>>>>>>>
>> >>>>>>>>>>> It means that if someone who is not RM directly commits to the
>> >>>> release
>> >>>>>>>>> branch, the commit will be reverted.
>> >>>>>>>>>>> And that from the beginning of the branching…
>> >>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>> >>>>>>>>>> cherry-picked in favour of merged forward.
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
>> goes
>> >>>> far
>> >>>>>>>>> enough.
>> >>>>>>>>>> Agreed here as well but let's take the step while discussing
>> >> further
>> >>>>>>>>>> steps and not implement to much process as well
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> This still uses a paradigm where a release is made from a
>> release
>> >>>>>>>>> branch that was started from an unstable development branch.
>> >>>>>>>>>>> Hence you still need *extensive* QA.
>> >>>>>>>>>> The problem here is that there is no stable point to fork from
>> at
>> >>>> the
>> >>>>>>>>>> moment. We will get there and we shouldn't stop taking steps in
>> >> that
>> >>>>>>>>>> direction.
>> >>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> If we truly want to release faster, we need to release from
>> the
>> >>>> same
>> >>>>>>>>> QA’d branch time after time….a release needs to be based on a
>> >>>> previous
>> >>>>>>>>> release
>> >>>>>>>>>>>
>> >>>>>>>>>>> Basically, we need a rolling release cycle. That will have the
>> >>>> added
>> >>>>>>>>> benefit to not leave releases behind and have to focus on
>> >>>> backporting.
>> >>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Please comments :-)
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Daan
>> >>>>>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
Will do tomorrow
On Wed, 6 May 2015 17:27 Rohit Yadav <bh...@apache.org> wrote:
> Hi Daan,
>
> I've merged awsapi after it passed travisCI tests and packaging worked
> (Here's a test repo without awsapi package:
> http://packages.bhaisaab.org/cloudstack/nukeawsapi/).
> Please go ahead with merging 4.5 on master. Let me know you've time
> and bandwidth to do it otherwise I can help with that as well.
>
> Regards.
>
> On Wed, May 6, 2015 at 4:00 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> > Fcourse
> >
> >
> > On Wed, 6 May 2015 15:02 Sebastien Goasguen <ru...@gmail.com> wrote:
> >>
> >> Can you sync with Rohit, who is merging the noawsapi stuff as well..
> >>
> >> > On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
> >> > wrote:
> >> >
> >> > I can have a look at the merge of 4.5.1 and am willing to be one of
> the
> >> > RMs, not to be the RM!
> >> >
> >> > Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
> >> >
> >> >> So no -1 on this.
> >> >>
> >> >> Do we have volunteers to RM 4.6 on the master branch ?
> >> >>
> >> >> I propose to set a date asap, tag master and tell everyone that
> >> >> starting
> >> >> from that tag all commits to master except from RM will be reverted.
> >> >>
> >> >> will need to make sure that all of 4.5.1 is in master
> >> >>
> >> >> -sebastien
> >> >>
> >> >>
> >> >> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Let's not do more quality improvement proces but just improve
> quality.
> >> >>> If
> >> >>> anybody want to add to the pages on the wiki, you're welkom but
> nobody
> >> >> did
> >> >>> for long time. +1 for the present state of Sebastien's views on
> >> >>> things.
> >> >> We
> >> >>> can refine at any time.
> >> >>>
> >> >>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
> >> >>>
> >> >>>>
> >> >>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
> >> >> wrote:
> >> >>>>
> >> >>>>> Hi,
> >> >>>>>
> >> >>>>> In my mind it was kind of making more sense to start by keeping
> 4.6
> >> >> into
> >> >>>> a
> >> >>>>> separate branch, enforce pull-requests and deploy the CI. smaller
> >> >>>>> step
> >> >>>> but
> >> >>>>> faster result, and from there, once we get stable with the CI
> >> >>>>
> >> >>>> I hear you.
> >> >>>>
> >> >>>> But we have waited for way too long for better CI. I see great
> >> >>>> efforts
> >> >> in
> >> >>>> that direction.
> >> >>>> But I personally do not want to wait any longer to make a move.
> >> >>>>
> >> >>>> We do open source, we should have fun, take risks, move fast, fail
> >> >>>> fast,
> >> >>>> recover etc....
> >> >>>>
> >> >>>> so let's JFDI
> >> >>>>
> >> >>>>> and git flow;
> >> >>>>> move into master, do fastest releases cycle. If we consider we can
> >> >>>>> do
> >> >> all
> >> >>>>> that starting in 4.6, I'm all for it!
> >> >>>>
> >> >>>>
> >> >>>> Is there really a difference between creating a 4.6 and doing what
> >> >>>> you
> >> >>>> say, and tagging master (start) and doing it on master leading to
> 4.6
> >> >>>> release ?
> >> >>>>
> >> >>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5.
> If
> >> >>>> we
> >> >>>> can improve a bit on the QA then we win.
> >> >>>> Plus I think a different commit model will help a lot in quality.
> >> >>>>
> >> >>>>>
> >> >>>>> Marcus: are you preparing a proposal on this? wiki page? I can
> help
> >> >>>>>
> >> >>>>
> >> >>>> We can do this proposal on email..and once we have consensus write
> it
> >> >>>> up
> >> >>>> for archive in the wiki.
> >> >>>> If we move to the wiki now, this effort is going to die.
> >> >>>>
> >> >>>>> Seb: doesn't the vote would confirm the consensus?
> >> >>>>>
> >> >>>>
> >> >>>> if we have consensus no need for vote.
> >> >>>>
> >> >>>>> Raja: do we have any documentation somewhere on how to use,
> >> >>>>> contribute
> >> >>>> to
> >> >>>>> the smoke test? that could be our start for the CI tests?
> >> >>>>>
> >> >>>>>
> >> >>>>> Cheers
> >> >>>>>
> >> >>>>>
> >> >>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen
> >> >>>>> <ru...@gmail.com>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>>
> >> >>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com>
> wrote:
> >> >>>>>>>
> >> >>>>>>> After reviewing the history as mentioned by Daan, unless we
> >> >>>>>>> propose
> >> >>>>>>> and vote on a newer workflow model I think the best we can do is
> >> >>>>>>> to
> >> >>>>>>> simply be more strict about commits to master. They all need to
> be
> >> >>>>>>> merges that have been tested against master before merge. This
> >> >>>>>>> will
> >> >> in
> >> >>>>>>> theory make master more stable, but doesn't really change the
> >> >> workflow
> >> >>>>>>> we've already agreed upon and have been working under (although
> >> >>>>>>> bugfixes sometimes were not coming in from branches, and
> >> >> cherry-picked
> >> >>>>>>> bugfixes from branches will need to go into a branch first,
> tested
> >> >>>>>>> against master, and merged to master). We can essentially set a
> >> >>>>>>> date
> >> >>>>>>> and do that any time, with some advance notice that direct
> commits
> >> >>>>>>> will be reverted.
> >> >>>>>>
> >> >>>>>> Yes +1.
> >> >>>>>>
> >> >>>>>> -Set a date
> >> >>>>>> -Tag master for reference
> >> >>>>>> -Find a volunteer or two to RM master
> >> >>>>>> -automatic revert on master if not from RM
> >> >>>>>> -all commits to master come from PR, need clear review and green
> >> >>>>>> tests
> >> >>>>>> -harden master (basic QA process), release 4.6 as a tag on master
> >> >>>>>> -all features and fixes need to be made on branches or forks and
> >> >>>>>> onus
> >> >> is
> >> >>>>>> on devs to rebase to master
> >> >>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from
> >> >>>>>> 4.3,
> >> >>>> 4.4,
> >> >>>>>> etc)
> >> >>>>>> -from there forward only maintain a linear release through master
> >> >>>>>>
> >> >>>>>> Feel free to add, tweak
> >> >>>>>>
> >> >>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
> >> >>>> members,
> >> >>>>>> votes should be avoided at all cost, they mean that we do not
> have
> >> >> clear
> >> >>>>>> consensus.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
> >> >> runseb@gmail.com
> >> >>>>>
> >> >>>>>> wrote:
> >> >>>>>>>>
> >> >>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com>
> wrote:
> >> >>>>>>>>>
> >> >>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >> >>>>>>>>> Otherwise you should be able to do it cleanly.
> >> >>>>>>>>>
> >> >>>>>>>>> There's a good opportunity to do this next release. Instead of
> >> >>>>>>>>> creating a release branch, we freeze master and start creating
> >> >>>>>>>>> dev
> >> >>>>>>>>> branches.
> >> >>>>>>>>
> >> >>>>>>>> +1
> >> >>>>>>>>
> >> >>>>>>>> This just amounts to treating master now like a release branch.
> >> >>>> Getting
> >> >>>>>> back to PL suggestion, that means
> >> >>>>>>>> that any commit to master would be through a PR or MERGE
> request
> >> >>>>>>>> on
> >> >>>> the
> >> >>>>>> ML. Anything else will be reverted by the RM.
> >> >>>>>>>>
> >> >>>>>>>> Marcus, do you feel like writing down a little process for this
> >> >>>>>>>> and
> >> >>>>>> some dates that we can target.
> >> >>>>>>>> It would be nice to do this for 4.6.
> >> >>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >> >>>>>> daan.hoogland@gmail.com> wrote:
> >> >>>>>>>>>> We heavily invested in code now on master. Not looking
> forward
> >> >>>>>>>>>> to
> >> >>>>>>>>>> backporting that.
> >> >>>>>>>>>>
> >> >>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
> >> >>>>>>>>>> own
> >> >>>>>> risk)
> >> >>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <shadowsor@gmail.com
> >:
> >> >>>>>>>>>>
> >> >>>>>>>>>>> Well, would we just swap the last release branch with
> master?
> >> >>>> Master
> >> >>>>>>>>>>> is the dev branch, and the last release is really what we
> have
> >> >> as a
> >> >>>>>>>>>>> stable branch.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >> >>>>>> daan.hoogland@gmail.com>
> >> >>>>>>>>>>> wrote:
> >> >>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >> >>>>>> runseb@gmail.com>
> >> >>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> >> >>>> pdion@cloudops.com
> >> >>>>>>>
> >> >>>>>>>>>>> wrote:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Today during the CloudStackdays we did a round table
> about
> >> >>>>>> Release
> >> >>>>>>>>>>>>>> management targeting the next 4.6 releases.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Quick bullet point discussions:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> ideas to change release planning
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
> >> >> plugin
> >> >>>>>>>>>>> involve
> >> >>>>>>>>>>>>>> change on the core:
> >> >>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >> >>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model
> >> >>>>>>>>>>>>>> which
> >> >>>> could
> >> >>>>>>>>>>>>>> introduce issue the database schema.
> >> >>>>>>>>>>>>>> - Database schema version should be different then the
> >> >>>> application
> >> >>>>>>>>>>>>>> version.
> >> >>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
> >> >>>>>>>>>>>>>> trigger
> >> >>>>>>>>>>> simulator
> >> >>>>>>>>>>>>>> job on PullRequest.
> >> >>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
> >> >>>>>>>>>>>>>> current
> >> >>>> way
> >> >>>>>> of
> >> >>>>>>>>>>>>>> supporting and back porting fixes to multiple release
> >> >>>>>>>>>>>>>> (4.3.x,
> >> >>>>>> 4.4.x,
> >> >>>>>>>>>>>>>> 4.5.x). But the current level of confidence against
> latest
> >> >>>> release
> >> >>>>>>>>>>> is low,
> >> >>>>>>>>>>>>>> so that need to be improved.
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
> >> >>>>>>>>>>>>>> release
> >> >>>>>>>>>>> velocity, and
> >> >>>>>>>>>>>>>> release branch stability. so we would like to propose
> few
> >> >>>> change
> >> >>>>>> in
> >> >>>>>>>>>>> the
> >> >>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request
> or
> >> >>>> merge
> >> >>>>>>>>>>> request,
> >> >>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
> >> >>>>>>>>>>>>>> pass
> >> >>>>>> the PR
> >> >>>>>>>>>>> would
> >> >>>>>>>>>>>>>> be accepted and automatically merged. At this time, I
> >> >>>>>>>>>>>>>> think
> >> >> we
> >> >>>>>> pretty
> >> >>>>>>>>>>> much
> >> >>>>>>>>>>>>>> have everything in place to do that. At a first step we
> >> >>>>>>>>>>>>>> would
> >> >>>> use
> >> >>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
> >> >>>>>>>>>>>>>> there.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> +1
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> We do need to realize what this means and be all fine with
> >> >>>>>>>>>>>>> it.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> It means that if someone who is not RM directly commits to
> >> >>>>>>>>>>>>> the
> >> >>>>>> release
> >> >>>>>>>>>>> branch, the commit will be reverted.
> >> >>>>>>>>>>>>> And that from the beginning of the branching...
> >> >>>>>>>>>>>> I agree and we can even go as far as reverting fixes that
> are
> >> >>>>>>>>>>>> cherry-picked in favour of merged forward.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> IMHO, I think this would be a good step but I don't think
> it
> >> >> goes
> >> >>>>>> far
> >> >>>>>>>>>>> enough.
> >> >>>>>>>>>>>> Agreed here as well but let's take the step while
> discussing
> >> >>>> further
> >> >>>>>>>>>>>> steps and not implement to much process as well
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> This still uses a paradigm where a release is made from a
> >> >> release
> >> >>>>>>>>>>> branch that was started from an unstable development branch.
> >> >>>>>>>>>>>>> Hence you still need *extensive* QA.
> >> >>>>>>>>>>>> The problem here is that there is no stable point to fork
> >> >>>>>>>>>>>> from
> >> >> at
> >> >>>>>> the
> >> >>>>>>>>>>>> moment. We will get there and we shouldn't stop taking
> steps
> >> >>>>>>>>>>>> in
> >> >>>> that
> >> >>>>>>>>>>>> direction.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> If we truly want to release faster, we need to release
> from
> >> >>>>>>>>>>>>> the
> >> >>>>>> same
> >> >>>>>>>>>>> QA'd branch time after time....a release needs to be based
> on a
> >> >>>>>> previous
> >> >>>>>>>>>>> release
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
> >> >>>>>>>>>>>>> the
> >> >>>>>> added
> >> >>>>>>>>>>> benefit to not leave releases behind and have to focus on
> >> >>>>>> backporting.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>> Please comments :-)
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>> --
> >> >>>>>>>>>>>> Daan
> >> >>>>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >
>
Re: [DISCUSS] 4.6 release management
Posted by Rohit Yadav <bh...@apache.org>.
Hi Daan,
I've merged awsapi after it passed travisCI tests and packaging worked
(Here's a test repo without awsapi package:
http://packages.bhaisaab.org/cloudstack/nukeawsapi/).
Please go ahead with merging 4.5 on master. Let me know you've time
and bandwidth to do it otherwise I can help with that as well.
Regards.
On Wed, May 6, 2015 at 4:00 PM, Daan Hoogland <da...@gmail.com> wrote:
> Fcourse
>
>
> On Wed, 6 May 2015 15:02 Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>> Can you sync with Rohit, who is merging the noawsapi stuff as well..
>>
>> > On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
>> > wrote:
>> >
>> > I can have a look at the merge of 4.5.1 and am willing to be one of the
>> > RMs, not to be the RM!
>> >
>> > Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>> >
>> >> So no -1 on this.
>> >>
>> >> Do we have volunteers to RM 4.6 on the master branch ?
>> >>
>> >> I propose to set a date asap, tag master and tell everyone that
>> >> starting
>> >> from that tag all commits to master except from RM will be reverted.
>> >>
>> >> will need to make sure that all of 4.5.1 is in master
>> >>
>> >> -sebastien
>> >>
>> >>
>> >> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
>> >> wrote:
>> >>
>> >>> Let's not do more quality improvement proces but just improve quality.
>> >>> If
>> >>> anybody want to add to the pages on the wiki, you're welkom but nobody
>> >> did
>> >>> for long time. +1 for the present state of Sebastien's views on
>> >>> things.
>> >> We
>> >>> can refine at any time.
>> >>>
>> >>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>> >>>
>> >>>>
>> >>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>> >> wrote:
>> >>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> In my mind it was kind of making more sense to start by keeping 4.6
>> >> into
>> >>>> a
>> >>>>> separate branch, enforce pull-requests and deploy the CI. smaller
>> >>>>> step
>> >>>> but
>> >>>>> faster result, and from there, once we get stable with the CI
>> >>>>
>> >>>> I hear you.
>> >>>>
>> >>>> But we have waited for way too long for better CI. I see great
>> >>>> efforts
>> >> in
>> >>>> that direction.
>> >>>> But I personally do not want to wait any longer to make a move.
>> >>>>
>> >>>> We do open source, we should have fun, take risks, move fast, fail
>> >>>> fast,
>> >>>> recover etc....
>> >>>>
>> >>>> so let's JFDI
>> >>>>
>> >>>>> and git flow;
>> >>>>> move into master, do fastest releases cycle. If we consider we can
>> >>>>> do
>> >> all
>> >>>>> that starting in 4.6, I'm all for it!
>> >>>>
>> >>>>
>> >>>> Is there really a difference between creating a 4.6 and doing what
>> >>>> you
>> >>>> say, and tagging master (start) and doing it on master leading to 4.6
>> >>>> release ?
>> >>>>
>> >>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If
>> >>>> we
>> >>>> can improve a bit on the QA then we win.
>> >>>> Plus I think a different commit model will help a lot in quality.
>> >>>>
>> >>>>>
>> >>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>> >>>>>
>> >>>>
>> >>>> We can do this proposal on email..and once we have consensus write it
>> >>>> up
>> >>>> for archive in the wiki.
>> >>>> If we move to the wiki now, this effort is going to die.
>> >>>>
>> >>>>> Seb: doesn't the vote would confirm the consensus?
>> >>>>>
>> >>>>
>> >>>> if we have consensus no need for vote.
>> >>>>
>> >>>>> Raja: do we have any documentation somewhere on how to use,
>> >>>>> contribute
>> >>>> to
>> >>>>> the smoke test? that could be our start for the CI tests?
>> >>>>>
>> >>>>>
>> >>>>> Cheers
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen
>> >>>>> <ru...@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>>
>> >>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> After reviewing the history as mentioned by Daan, unless we
>> >>>>>>> propose
>> >>>>>>> and vote on a newer workflow model I think the best we can do is
>> >>>>>>> to
>> >>>>>>> simply be more strict about commits to master. They all need to be
>> >>>>>>> merges that have been tested against master before merge. This
>> >>>>>>> will
>> >> in
>> >>>>>>> theory make master more stable, but doesn't really change the
>> >> workflow
>> >>>>>>> we've already agreed upon and have been working under (although
>> >>>>>>> bugfixes sometimes were not coming in from branches, and
>> >> cherry-picked
>> >>>>>>> bugfixes from branches will need to go into a branch first, tested
>> >>>>>>> against master, and merged to master). We can essentially set a
>> >>>>>>> date
>> >>>>>>> and do that any time, with some advance notice that direct commits
>> >>>>>>> will be reverted.
>> >>>>>>
>> >>>>>> Yes +1.
>> >>>>>>
>> >>>>>> -Set a date
>> >>>>>> -Tag master for reference
>> >>>>>> -Find a volunteer or two to RM master
>> >>>>>> -automatic revert on master if not from RM
>> >>>>>> -all commits to master come from PR, need clear review and green
>> >>>>>> tests
>> >>>>>> -harden master (basic QA process), release 4.6 as a tag on master
>> >>>>>> -all features and fixes need to be made on branches or forks and
>> >>>>>> onus
>> >> is
>> >>>>>> on devs to rebase to master
>> >>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from
>> >>>>>> 4.3,
>> >>>> 4.4,
>> >>>>>> etc)
>> >>>>>> -from there forward only maintain a linear release through master
>> >>>>>>
>> >>>>>> Feel free to add, tweak
>> >>>>>>
>> >>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>> >>>> members,
>> >>>>>> votes should be avoided at all cost, they mean that we do not have
>> >> clear
>> >>>>>> consensus.
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>> >> runseb@gmail.com
>> >>>>>
>> >>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>> >>>>>>>>> Otherwise you should be able to do it cleanly.
>> >>>>>>>>>
>> >>>>>>>>> There's a good opportunity to do this next release. Instead of
>> >>>>>>>>> creating a release branch, we freeze master and start creating
>> >>>>>>>>> dev
>> >>>>>>>>> branches.
>> >>>>>>>>
>> >>>>>>>> +1
>> >>>>>>>>
>> >>>>>>>> This just amounts to treating master now like a release branch.
>> >>>> Getting
>> >>>>>> back to PL suggestion, that means
>> >>>>>>>> that any commit to master would be through a PR or MERGE request
>> >>>>>>>> on
>> >>>> the
>> >>>>>> ML. Anything else will be reverted by the RM.
>> >>>>>>>>
>> >>>>>>>> Marcus, do you feel like writing down a little process for this
>> >>>>>>>> and
>> >>>>>> some dates that we can target.
>> >>>>>>>> It would be nice to do this for 4.6.
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>> >>>>>> daan.hoogland@gmail.com> wrote:
>> >>>>>>>>>> We heavily invested in code now on master. Not looking forward
>> >>>>>>>>>> to
>> >>>>>>>>>> backporting that.
>> >>>>>>>>>>
>> >>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
>> >>>>>>>>>> own
>> >>>>>> risk)
>> >>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>> >>>>>>>>>>
>> >>>>>>>>>>> Well, would we just swap the last release branch with master?
>> >>>> Master
>> >>>>>>>>>>> is the dev branch, and the last release is really what we have
>> >> as a
>> >>>>>>>>>>> stable branch.
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>> >>>>>> daan.hoogland@gmail.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>> >>>>>> runseb@gmail.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>> >>>> pdion@cloudops.com
>> >>>>>>>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>> >>>>>> Release
>> >>>>>>>>>>>>>> management targeting the next 4.6 releases.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Quick bullet point discussions:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> ideas to change release planning
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
>> >> plugin
>> >>>>>>>>>>> involve
>> >>>>>>>>>>>>>> change on the core:
>> >>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>> >>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model
>> >>>>>>>>>>>>>> which
>> >>>> could
>> >>>>>>>>>>>>>> introduce issue the database schema.
>> >>>>>>>>>>>>>> - Database schema version should be different then the
>> >>>> application
>> >>>>>>>>>>>>>> version.
>> >>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
>> >>>>>>>>>>>>>> trigger
>> >>>>>>>>>>> simulator
>> >>>>>>>>>>>>>> job on PullRequest.
>> >>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
>> >>>>>>>>>>>>>> current
>> >>>> way
>> >>>>>> of
>> >>>>>>>>>>>>>> supporting and back porting fixes to multiple release
>> >>>>>>>>>>>>>> (4.3.x,
>> >>>>>> 4.4.x,
>> >>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>> >>>> release
>> >>>>>>>>>>> is low,
>> >>>>>>>>>>>>>> so that need to be improved.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
>> >>>>>>>>>>>>>> release
>> >>>>>>>>>>> velocity, and
>> >>>>>>>>>>>>>> release branch stability. so we would like to propose few
>> >>>> change
>> >>>>>> in
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>> >>>> merge
>> >>>>>>>>>>> request,
>> >>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
>> >>>>>>>>>>>>>> pass
>> >>>>>> the PR
>> >>>>>>>>>>> would
>> >>>>>>>>>>>>>> be accepted and automatically merged. At this time, I
>> >>>>>>>>>>>>>> think
>> >> we
>> >>>>>> pretty
>> >>>>>>>>>>> much
>> >>>>>>>>>>>>>> have everything in place to do that. At a first step we
>> >>>>>>>>>>>>>> would
>> >>>> use
>> >>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
>> >>>>>>>>>>>>>> there.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> We do need to realize what this means and be all fine with
>> >>>>>>>>>>>>> it.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> It means that if someone who is not RM directly commits to
>> >>>>>>>>>>>>> the
>> >>>>>> release
>> >>>>>>>>>>> branch, the commit will be reverted.
>> >>>>>>>>>>>>> And that from the beginning of the branching...
>> >>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>> >>>>>>>>>>>> cherry-picked in favour of merged forward.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> IMHO, I think this would be a good step but I don't think it
>> >> goes
>> >>>>>> far
>> >>>>>>>>>>> enough.
>> >>>>>>>>>>>> Agreed here as well but let's take the step while discussing
>> >>>> further
>> >>>>>>>>>>>> steps and not implement to much process as well
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> This still uses a paradigm where a release is made from a
>> >> release
>> >>>>>>>>>>> branch that was started from an unstable development branch.
>> >>>>>>>>>>>>> Hence you still need *extensive* QA.
>> >>>>>>>>>>>> The problem here is that there is no stable point to fork
>> >>>>>>>>>>>> from
>> >> at
>> >>>>>> the
>> >>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
>> >>>>>>>>>>>> in
>> >>>> that
>> >>>>>>>>>>>> direction.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> If we truly want to release faster, we need to release from
>> >>>>>>>>>>>>> the
>> >>>>>> same
>> >>>>>>>>>>> QA'd branch time after time....a release needs to be based on a
>> >>>>>> previous
>> >>>>>>>>>>> release
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
>> >>>>>>>>>>>>> the
>> >>>>>> added
>> >>>>>>>>>>> benefit to not leave releases behind and have to focus on
>> >>>>>> backporting.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Please comments :-)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> --
>> >>>>>>>>>>>> Daan
>> >>>>>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>
>> >>
>>
>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
Fcourse
On Wed, 6 May 2015 15:02 Sebastien Goasguen <ru...@gmail.com> wrote:
> Can you sync with Rohit, who is merging the noawsapi stuff as well..
>
> > On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> >
> > I can have a look at the merge of 4.5.1 and am willing to be one of the
> > RMs, not to be the RM!
> >
> > Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
> >
> >> So no -1 on this.
> >>
> >> Do we have volunteers to RM 4.6 on the master branch ?
> >>
> >> I propose to set a date asap, tag master and tell everyone that starting
> >> from that tag all commits to master except from RM will be reverted.
> >>
> >> will need to make sure that all of 4.5.1 is in master
> >>
> >> -sebastien
> >>
> >>
> >> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com>
> wrote:
> >>
> >>> Let's not do more quality improvement proces but just improve quality.
> If
> >>> anybody want to add to the pages on the wiki, you're welkom but nobody
> >> did
> >>> for long time. +1 for the present state of Sebastien's views on things.
> >> We
> >>> can refine at any time.
> >>>
> >>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
> >>>
> >>>>
> >>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
> >> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> In my mind it was kind of making more sense to start by keeping 4.6
> >> into
> >>>> a
> >>>>> separate branch, enforce pull-requests and deploy the CI. smaller
> step
> >>>> but
> >>>>> faster result, and from there, once we get stable with the CI
> >>>>
> >>>> I hear you.
> >>>>
> >>>> But we have waited for way too long for better CI. I see great efforts
> >> in
> >>>> that direction.
> >>>> But I personally do not want to wait any longer to make a move.
> >>>>
> >>>> We do open source, we should have fun, take risks, move fast, fail
> fast,
> >>>> recover etc….
> >>>>
> >>>> so let's JFDI
> >>>>
> >>>>> and git flow;
> >>>>> move into master, do fastest releases cycle. If we consider we can do
> >> all
> >>>>> that starting in 4.6, I'm all for it!
> >>>>
> >>>>
> >>>> Is there really a difference between creating a 4.6 and doing what you
> >>>> say, and tagging master (start) and doing it on master leading to 4.6
> >>>> release ?
> >>>>
> >>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If
> we
> >>>> can improve a bit on the QA then we win.
> >>>> Plus I think a different commit model will help a lot in quality.
> >>>>
> >>>>>
> >>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
> >>>>>
> >>>>
> >>>> We can do this proposal on email..and once we have consensus write it
> up
> >>>> for archive in the wiki.
> >>>> If we move to the wiki now, this effort is going to die.
> >>>>
> >>>>> Seb: doesn't the vote would confirm the consensus?
> >>>>>
> >>>>
> >>>> if we have consensus no need for vote.
> >>>>
> >>>>> Raja: do we have any documentation somewhere on how to use,
> contribute
> >>>> to
> >>>>> the smoke test? that could be our start for the CI tests?
> >>>>>
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> After reviewing the history as mentioned by Daan, unless we propose
> >>>>>>> and vote on a newer workflow model I think the best we can do is to
> >>>>>>> simply be more strict about commits to master. They all need to be
> >>>>>>> merges that have been tested against master before merge. This will
> >> in
> >>>>>>> theory make master more stable, but doesn't really change the
> >> workflow
> >>>>>>> we've already agreed upon and have been working under (although
> >>>>>>> bugfixes sometimes were not coming in from branches, and
> >> cherry-picked
> >>>>>>> bugfixes from branches will need to go into a branch first, tested
> >>>>>>> against master, and merged to master). We can essentially set a
> date
> >>>>>>> and do that any time, with some advance notice that direct commits
> >>>>>>> will be reverted.
> >>>>>>
> >>>>>> Yes +1.
> >>>>>>
> >>>>>> -Set a date
> >>>>>> -Tag master for reference
> >>>>>> -Find a volunteer or two to RM master
> >>>>>> -automatic revert on master if not from RM
> >>>>>> -all commits to master come from PR, need clear review and green
> tests
> >>>>>> -harden master (basic QA process), release 4.6 as a tag on master
> >>>>>> -all features and fixes need to be made on branches or forks and
> onus
> >> is
> >>>>>> on devs to rebase to master
> >>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
> >>>> 4.4,
> >>>>>> etc)
> >>>>>> -from there forward only maintain a linear release through master
> >>>>>>
> >>>>>> Feel free to add, tweak
> >>>>>>
> >>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
> >>>> members,
> >>>>>> votes should be avoided at all cost, they mean that we do not have
> >> clear
> >>>>>> consensus.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
> >> runseb@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >>>>>>>>> Otherwise you should be able to do it cleanly.
> >>>>>>>>>
> >>>>>>>>> There's a good opportunity to do this next release. Instead of
> >>>>>>>>> creating a release branch, we freeze master and start creating
> dev
> >>>>>>>>> branches.
> >>>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>> This just amounts to treating master now like a release branch.
> >>>> Getting
> >>>>>> back to PL suggestion, that means
> >>>>>>>> that any commit to master would be through a PR or MERGE request
> on
> >>>> the
> >>>>>> ML. Anything else will be reverted by the RM.
> >>>>>>>>
> >>>>>>>> Marcus, do you feel like writing down a little process for this
> and
> >>>>>> some dates that we can target.
> >>>>>>>> It would be nice to do this for 4.6.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >>>>>> daan.hoogland@gmail.com> wrote:
> >>>>>>>>>> We heavily invested in code now on master. Not looking forward
> to
> >>>>>>>>>> backporting that.
> >>>>>>>>>>
> >>>>>>>>>> mobile dev with bilingual spelling checker used (read at your
> own
> >>>>>> risk)
> >>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>>> Well, would we just swap the last release branch with master?
> >>>> Master
> >>>>>>>>>>> is the dev branch, and the last release is really what we have
> >> as a
> >>>>>>>>>>> stable branch.
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >>>>>> daan.hoogland@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >>>>>> runseb@gmail.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> >>>> pdion@cloudops.com
> >>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
> >>>>>> Release
> >>>>>>>>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Quick bullet point discussions:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ideas to change release planning
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
> >> plugin
> >>>>>>>>>>> involve
> >>>>>>>>>>>>>> change on the core:
> >>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
> >>>> could
> >>>>>>>>>>>>>> introduce issue the database schema.
> >>>>>>>>>>>>>> - Database schema version should be different then the
> >>>> application
> >>>>>>>>>>>>>> version.
> >>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and
> trigger
> >>>>>>>>>>> simulator
> >>>>>>>>>>>>>> job on PullRequest.
> >>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our
> current
> >>>> way
> >>>>>> of
> >>>>>>>>>>>>>> supporting and back porting fixes to multiple release
> (4.3.x,
> >>>>>> 4.4.x,
> >>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
> >>>> release
> >>>>>>>>>>> is low,
> >>>>>>>>>>>>>> so that need to be improved.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So, the main messages is that w'd like to improve the
> release
> >>>>>>>>>>> velocity, and
> >>>>>>>>>>>>>> release branch stability. so we would like to propose few
> >>>> change
> >>>>>> in
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
> >>>> merge
> >>>>>>>>>>> request,
> >>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that
> pass
> >>>>>> the PR
> >>>>>>>>>>> would
> >>>>>>>>>>>>>> be accepted and automatically merged. At this time, I think
> >> we
> >>>>>> pretty
> >>>>>>>>>>> much
> >>>>>>>>>>>>>> have everything in place to do that. At a first step we
> would
> >>>> use
> >>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from
> there.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> +1
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We do need to realize what this means and be all fine with
> it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It means that if someone who is not RM directly commits to
> the
> >>>>>> release
> >>>>>>>>>>> branch, the commit will be reverted.
> >>>>>>>>>>>>> And that from the beginning of the branching…
> >>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
> >>>>>>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
> >> goes
> >>>>>> far
> >>>>>>>>>>> enough.
> >>>>>>>>>>>> Agreed here as well but let's take the step while discussing
> >>>> further
> >>>>>>>>>>>> steps and not implement to much process as well
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This still uses a paradigm where a release is made from a
> >> release
> >>>>>>>>>>> branch that was started from an unstable development branch.
> >>>>>>>>>>>>> Hence you still need *extensive* QA.
> >>>>>>>>>>>> The problem here is that there is no stable point to fork from
> >> at
> >>>>>> the
> >>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps
> in
> >>>> that
> >>>>>>>>>>>> direction.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we truly want to release faster, we need to release from
> the
> >>>>>> same
> >>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
> >>>>>> previous
> >>>>>>>>>>> release
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have
> the
> >>>>>> added
> >>>>>>>>>>> benefit to not leave releases behind and have to focus on
> >>>>>> backporting.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Please comments :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Daan
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
Can you sync with Rohit, who is merging the noawsapi stuff as well..
> On May 6, 2015, at 10:59 AM, Daan Hoogland <da...@gmail.com> wrote:
>
> I can have a look at the merge of 4.5.1 and am willing to be one of the
> RMs, not to be the RM!
>
> Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
>
>> So no -1 on this.
>>
>> Do we have volunteers to RM 4.6 on the master branch ?
>>
>> I propose to set a date asap, tag master and tell everyone that starting
>> from that tag all commits to master except from RM will be reverted.
>>
>> will need to make sure that all of 4.5.1 is in master
>>
>> -sebastien
>>
>>
>> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com> wrote:
>>
>>> Let's not do more quality improvement proces but just improve quality. If
>>> anybody want to add to the pages on the wiki, you're welkom but nobody
>> did
>>> for long time. +1 for the present state of Sebastien's views on things.
>> We
>>> can refine at any time.
>>>
>>> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>>>
>>>>
>>>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In my mind it was kind of making more sense to start by keeping 4.6
>> into
>>>> a
>>>>> separate branch, enforce pull-requests and deploy the CI. smaller step
>>>> but
>>>>> faster result, and from there, once we get stable with the CI
>>>>
>>>> I hear you.
>>>>
>>>> But we have waited for way too long for better CI. I see great efforts
>> in
>>>> that direction.
>>>> But I personally do not want to wait any longer to make a move.
>>>>
>>>> We do open source, we should have fun, take risks, move fast, fail fast,
>>>> recover etc….
>>>>
>>>> so let's JFDI
>>>>
>>>>> and git flow;
>>>>> move into master, do fastest releases cycle. If we consider we can do
>> all
>>>>> that starting in 4.6, I'm all for it!
>>>>
>>>>
>>>> Is there really a difference between creating a 4.6 and doing what you
>>>> say, and tagging master (start) and doing it on master leading to 4.6
>>>> release ?
>>>>
>>>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
>>>> can improve a bit on the QA then we win.
>>>> Plus I think a different commit model will help a lot in quality.
>>>>
>>>>>
>>>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>>>>>
>>>>
>>>> We can do this proposal on email..and once we have consensus write it up
>>>> for archive in the wiki.
>>>> If we move to the wiki now, this effort is going to die.
>>>>
>>>>> Seb: doesn't the vote would confirm the consensus?
>>>>>
>>>>
>>>> if we have consensus no need for vote.
>>>>
>>>>> Raja: do we have any documentation somewhere on how to use, contribute
>>>> to
>>>>> the smoke test? that could be our start for the CI tests?
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>>>>>
>>>>>>> After reviewing the history as mentioned by Daan, unless we propose
>>>>>>> and vote on a newer workflow model I think the best we can do is to
>>>>>>> simply be more strict about commits to master. They all need to be
>>>>>>> merges that have been tested against master before merge. This will
>> in
>>>>>>> theory make master more stable, but doesn't really change the
>> workflow
>>>>>>> we've already agreed upon and have been working under (although
>>>>>>> bugfixes sometimes were not coming in from branches, and
>> cherry-picked
>>>>>>> bugfixes from branches will need to go into a branch first, tested
>>>>>>> against master, and merged to master). We can essentially set a date
>>>>>>> and do that any time, with some advance notice that direct commits
>>>>>>> will be reverted.
>>>>>>
>>>>>> Yes +1.
>>>>>>
>>>>>> -Set a date
>>>>>> -Tag master for reference
>>>>>> -Find a volunteer or two to RM master
>>>>>> -automatic revert on master if not from RM
>>>>>> -all commits to master come from PR, need clear review and green tests
>>>>>> -harden master (basic QA process), release 4.6 as a tag on master
>>>>>> -all features and fixes need to be made on branches or forks and onus
>> is
>>>>>> on devs to rebase to master
>>>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
>>>> 4.4,
>>>>>> etc)
>>>>>> -from there forward only maintain a linear release through master
>>>>>>
>>>>>> Feel free to add, tweak
>>>>>>
>>>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>>>> members,
>>>>>> votes should be avoided at all cost, they mean that we do not have
>> clear
>>>>>> consensus.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
>> runseb@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>>>>>> Otherwise you should be able to do it cleanly.
>>>>>>>>>
>>>>>>>>> There's a good opportunity to do this next release. Instead of
>>>>>>>>> creating a release branch, we freeze master and start creating dev
>>>>>>>>> branches.
>>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> This just amounts to treating master now like a release branch.
>>>> Getting
>>>>>> back to PL suggestion, that means
>>>>>>>> that any commit to master would be through a PR or MERGE request on
>>>> the
>>>>>> ML. Anything else will be reverted by the RM.
>>>>>>>>
>>>>>>>> Marcus, do you feel like writing down a little process for this and
>>>>>> some dates that we can target.
>>>>>>>> It would be nice to do this for 4.6.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>>>>>> daan.hoogland@gmail.com> wrote:
>>>>>>>>>> We heavily invested in code now on master. Not looking forward to
>>>>>>>>>> backporting that.
>>>>>>>>>>
>>>>>>>>>> mobile dev with bilingual spelling checker used (read at your own
>>>>>> risk)
>>>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Well, would we just swap the last release branch with master?
>>>> Master
>>>>>>>>>>> is the dev branch, and the last release is really what we have
>> as a
>>>>>>>>>>> stable branch.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>>>>>> daan.hoogland@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>>>>>> runseb@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>>>> pdion@cloudops.com
>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>>>>>> Release
>>>>>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ideas to change release planning
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Plugin contribution is complicated because often a new
>> plugin
>>>>>>>>>>> involve
>>>>>>>>>>>>>> change on the core:
>>>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
>>>> could
>>>>>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>>>>>> - Database schema version should be different then the
>>>> application
>>>>>>>>>>>>>> version.
>>>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>>>>>>>> simulator
>>>>>>>>>>>>>> job on PullRequest.
>>>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our current
>>>> way
>>>>>> of
>>>>>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
>>>>>> 4.4.x,
>>>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>>>> release
>>>>>>>>>>> is low,
>>>>>>>>>>>>>> so that need to be improved.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>>>>>>>> velocity, and
>>>>>>>>>>>>>> release branch stability. so we would like to propose few
>>>> change
>>>>>> in
>>>>>>>>>>> the
>>>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>>>> merge
>>>>>>>>>>> request,
>>>>>>>>>>>>>> which would trigger a simulator job, ideally only if that pass
>>>>>> the PR
>>>>>>>>>>> would
>>>>>>>>>>>>>> be accepted and automatically merged. At this time, I think
>> we
>>>>>> pretty
>>>>>>>>>>> much
>>>>>>>>>>>>>> have everything in place to do that. At a first step we would
>>>> use
>>>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>>>>>>>
>>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It means that if someone who is not RM directly commits to the
>>>>>> release
>>>>>>>>>>> branch, the commit will be reverted.
>>>>>>>>>>>>> And that from the beginning of the branching…
>>>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
>> goes
>>>>>> far
>>>>>>>>>>> enough.
>>>>>>>>>>>> Agreed here as well but let's take the step while discussing
>>>> further
>>>>>>>>>>>> steps and not implement to much process as well
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This still uses a paradigm where a release is made from a
>> release
>>>>>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>>>>>> The problem here is that there is no stable point to fork from
>> at
>>>>>> the
>>>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps in
>>>> that
>>>>>>>>>>>> direction.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we truly want to release faster, we need to release from the
>>>>>> same
>>>>>>>>>>> QA’d branch time after time….a release needs to be based on a
>>>>>> previous
>>>>>>>>>>> release
>>>>>>>>>>>>>
>>>>>>>>>>>>> Basically, we need a rolling release cycle. That will have the
>>>>>> added
>>>>>>>>>>> benefit to not leave releases behind and have to focus on
>>>>>> backporting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please comments :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Daan
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
I can have a look at the merge of 4.5.1 and am willing to be one of the
RMs, not to be the RM!
Op wo 6 mei 2015 om 09:47 schreef sebgoa <ru...@gmail.com>:
> So no -1 on this.
>
> Do we have volunteers to RM 4.6 on the master branch ?
>
> I propose to set a date asap, tag master and tell everyone that starting
> from that tag all commits to master except from RM will be reverted.
>
> will need to make sure that all of 4.5.1 is in master
>
> -sebastien
>
>
> On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com> wrote:
>
> > Let's not do more quality improvement proces but just improve quality. If
> > anybody want to add to the pages on the wiki, you're welkom but nobody
> did
> > for long time. +1 for the present state of Sebastien's views on things.
> We
> > can refine at any time.
> >
> > Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
> >
> >>
> >> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> In my mind it was kind of making more sense to start by keeping 4.6
> into
> >> a
> >>> separate branch, enforce pull-requests and deploy the CI. smaller step
> >> but
> >>> faster result, and from there, once we get stable with the CI
> >>
> >> I hear you.
> >>
> >> But we have waited for way too long for better CI. I see great efforts
> in
> >> that direction.
> >> But I personally do not want to wait any longer to make a move.
> >>
> >> We do open source, we should have fun, take risks, move fast, fail fast,
> >> recover etc….
> >>
> >> so let's JFDI
> >>
> >>> and git flow;
> >>> move into master, do fastest releases cycle. If we consider we can do
> all
> >>> that starting in 4.6, I'm all for it!
> >>
> >>
> >> Is there really a difference between creating a 4.6 and doing what you
> >> say, and tagging master (start) and doing it on master leading to 4.6
> >> release ?
> >>
> >> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
> >> can improve a bit on the QA then we win.
> >> Plus I think a different commit model will help a lot in quality.
> >>
> >>>
> >>> Marcus: are you preparing a proposal on this? wiki page? I can help
> >>>
> >>
> >> We can do this proposal on email..and once we have consensus write it up
> >> for archive in the wiki.
> >> If we move to the wiki now, this effort is going to die.
> >>
> >>> Seb: doesn't the vote would confirm the consensus?
> >>>
> >>
> >> if we have consensus no need for vote.
> >>
> >>> Raja: do we have any documentation somewhere on how to use, contribute
> >> to
> >>> the smoke test? that could be our start for the CI tests?
> >>>
> >>>
> >>> Cheers
> >>>
> >>>
> >>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
> >>> wrote:
> >>>
> >>>>
> >>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >>>>>
> >>>>> After reviewing the history as mentioned by Daan, unless we propose
> >>>>> and vote on a newer workflow model I think the best we can do is to
> >>>>> simply be more strict about commits to master. They all need to be
> >>>>> merges that have been tested against master before merge. This will
> in
> >>>>> theory make master more stable, but doesn't really change the
> workflow
> >>>>> we've already agreed upon and have been working under (although
> >>>>> bugfixes sometimes were not coming in from branches, and
> cherry-picked
> >>>>> bugfixes from branches will need to go into a branch first, tested
> >>>>> against master, and merged to master). We can essentially set a date
> >>>>> and do that any time, with some advance notice that direct commits
> >>>>> will be reverted.
> >>>>
> >>>> Yes +1.
> >>>>
> >>>> -Set a date
> >>>> -Tag master for reference
> >>>> -Find a volunteer or two to RM master
> >>>> -automatic revert on master if not from RM
> >>>> -all commits to master come from PR, need clear review and green tests
> >>>> -harden master (basic QA process), release 4.6 as a tag on master
> >>>> -all features and fixes need to be made on branches or forks and onus
> is
> >>>> on devs to rebase to master
> >>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
> >> 4.4,
> >>>> etc)
> >>>> -from there forward only maintain a linear release through master
> >>>>
> >>>> Feel free to add, tweak
> >>>>
> >>>> PS: No need to vote if we have consensus. Taking a clue from ASF
> >> members,
> >>>> votes should be avoided at all cost, they mean that we do not have
> clear
> >>>> consensus.
> >>>>
> >>>>
> >>>>>
> >>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <
> runseb@gmail.com
> >>>
> >>>> wrote:
> >>>>>>
> >>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >>>>>>> Otherwise you should be able to do it cleanly.
> >>>>>>>
> >>>>>>> There's a good opportunity to do this next release. Instead of
> >>>>>>> creating a release branch, we freeze master and start creating dev
> >>>>>>> branches.
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> This just amounts to treating master now like a release branch.
> >> Getting
> >>>> back to PL suggestion, that means
> >>>>>> that any commit to master would be through a PR or MERGE request on
> >> the
> >>>> ML. Anything else will be reverted by the RM.
> >>>>>>
> >>>>>> Marcus, do you feel like writing down a little process for this and
> >>>> some dates that we can target.
> >>>>>> It would be nice to do this for 4.6.
> >>>>>>
> >>>>>>>
> >>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >>>> daan.hoogland@gmail.com> wrote:
> >>>>>>>> We heavily invested in code now on master. Not looking forward to
> >>>>>>>> backporting that.
> >>>>>>>>
> >>>>>>>> mobile dev with bilingual spelling checker used (read at your own
> >>>> risk)
> >>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>>>>>
> >>>>>>>>> Well, would we just swap the last release branch with master?
> >> Master
> >>>>>>>>> is the dev branch, and the last release is really what we have
> as a
> >>>>>>>>> stable branch.
> >>>>>>>>>
> >>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >>>> daan.hoogland@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >>>> runseb@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> >> pdion@cloudops.com
> >>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Today during the CloudStackdays we did a round table about
> >>>> Release
> >>>>>>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Quick bullet point discussions:
> >>>>>>>>>>>>
> >>>>>>>>>>>> ideas to change release planning
> >>>>>>>>>>>>
> >>>>>>>>>>>> - Plugin contribution is complicated because often a new
> plugin
> >>>>>>>>> involve
> >>>>>>>>>>>> change on the core:
> >>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
> >> could
> >>>>>>>>>>>> introduce issue the database schema.
> >>>>>>>>>>>> - Database schema version should be different then the
> >> application
> >>>>>>>>>>>> version.
> >>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
> >>>>>>>>> simulator
> >>>>>>>>>>>> job on PullRequest.
> >>>>>>>>>>>> - Some people (I'm part of them) are concerned on our current
> >> way
> >>>> of
> >>>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
> >>>> 4.4.x,
> >>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
> >> release
> >>>>>>>>> is low,
> >>>>>>>>>>>> so that need to be improved.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> So, the main messages is that w'd like to improve the release
> >>>>>>>>> velocity, and
> >>>>>>>>>>>> release branch stability. so we would like to propose few
> >> change
> >>>> in
> >>>>>>>>> the
> >>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
> >> merge
> >>>>>>>>> request,
> >>>>>>>>>>>> which would trigger a simulator job, ideally only if that pass
> >>>> the PR
> >>>>>>>>> would
> >>>>>>>>>>>> be accepted and automatically merged. At this time, I think
> we
> >>>> pretty
> >>>>>>>>> much
> >>>>>>>>>>>> have everything in place to do that. At a first step we would
> >> use
> >>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
> >>>>>>>>>>>
> >>>>>>>>>>> +1
> >>>>>>>>>>>
> >>>>>>>>>>> We do need to realize what this means and be all fine with it.
> >>>>>>>>>>>
> >>>>>>>>>>> It means that if someone who is not RM directly commits to the
> >>>> release
> >>>>>>>>> branch, the commit will be reverted.
> >>>>>>>>>>> And that from the beginning of the branching…
> >>>>>>>>>> I agree and we can even go as far as reverting fixes that are
> >>>>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it
> goes
> >>>> far
> >>>>>>>>> enough.
> >>>>>>>>>> Agreed here as well but let's take the step while discussing
> >> further
> >>>>>>>>>> steps and not implement to much process as well
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> This still uses a paradigm where a release is made from a
> release
> >>>>>>>>> branch that was started from an unstable development branch.
> >>>>>>>>>>> Hence you still need *extensive* QA.
> >>>>>>>>>> The problem here is that there is no stable point to fork from
> at
> >>>> the
> >>>>>>>>>> moment. We will get there and we shouldn't stop taking steps in
> >> that
> >>>>>>>>>> direction.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> If we truly want to release faster, we need to release from the
> >>>> same
> >>>>>>>>> QA’d branch time after time….a release needs to be based on a
> >>>> previous
> >>>>>>>>> release
> >>>>>>>>>>>
> >>>>>>>>>>> Basically, we need a rolling release cycle. That will have the
> >>>> added
> >>>>>>>>> benefit to not leave releases behind and have to focus on
> >>>> backporting.
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Please comments :-)
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Daan
> >>>>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
So no -1 on this.
Do we have volunteers to RM 4.6 on the master branch ?
I propose to set a date asap, tag master and tell everyone that starting from that tag all commits to master except from RM will be reverted.
will need to make sure that all of 4.5.1 is in master
-sebastien
On May 1, 2015, at 1:19 PM, Daan Hoogland <da...@gmail.com> wrote:
> Let's not do more quality improvement proces but just improve quality. If
> anybody want to add to the pages on the wiki, you're welkom but nobody did
> for long time. +1 for the present state of Sebastien's views on things. We
> can refine at any time.
>
> Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>
>>
>> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> In my mind it was kind of making more sense to start by keeping 4.6 into
>> a
>>> separate branch, enforce pull-requests and deploy the CI. smaller step
>> but
>>> faster result, and from there, once we get stable with the CI
>>
>> I hear you.
>>
>> But we have waited for way too long for better CI. I see great efforts in
>> that direction.
>> But I personally do not want to wait any longer to make a move.
>>
>> We do open source, we should have fun, take risks, move fast, fail fast,
>> recover etc….
>>
>> so let's JFDI
>>
>>> and git flow;
>>> move into master, do fastest releases cycle. If we consider we can do all
>>> that starting in 4.6, I'm all for it!
>>
>>
>> Is there really a difference between creating a 4.6 and doing what you
>> say, and tagging master (start) and doing it on master leading to 4.6
>> release ?
>>
>> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
>> can improve a bit on the QA then we win.
>> Plus I think a different commit model will help a lot in quality.
>>
>>>
>>> Marcus: are you preparing a proposal on this? wiki page? I can help
>>>
>>
>> We can do this proposal on email..and once we have consensus write it up
>> for archive in the wiki.
>> If we move to the wiki now, this effort is going to die.
>>
>>> Seb: doesn't the vote would confirm the consensus?
>>>
>>
>> if we have consensus no need for vote.
>>
>>> Raja: do we have any documentation somewhere on how to use, contribute
>> to
>>> the smoke test? that could be our start for the CI tests?
>>>
>>>
>>> Cheers
>>>
>>>
>>> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>>>
>>>>> After reviewing the history as mentioned by Daan, unless we propose
>>>>> and vote on a newer workflow model I think the best we can do is to
>>>>> simply be more strict about commits to master. They all need to be
>>>>> merges that have been tested against master before merge. This will in
>>>>> theory make master more stable, but doesn't really change the workflow
>>>>> we've already agreed upon and have been working under (although
>>>>> bugfixes sometimes were not coming in from branches, and cherry-picked
>>>>> bugfixes from branches will need to go into a branch first, tested
>>>>> against master, and merged to master). We can essentially set a date
>>>>> and do that any time, with some advance notice that direct commits
>>>>> will be reverted.
>>>>
>>>> Yes +1.
>>>>
>>>> -Set a date
>>>> -Tag master for reference
>>>> -Find a volunteer or two to RM master
>>>> -automatic revert on master if not from RM
>>>> -all commits to master come from PR, need clear review and green tests
>>>> -harden master (basic QA process), release 4.6 as a tag on master
>>>> -all features and fixes need to be made on branches or forks and onus is
>>>> on devs to rebase to master
>>>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
>> 4.4,
>>>> etc)
>>>> -from there forward only maintain a linear release through master
>>>>
>>>> Feel free to add, tweak
>>>>
>>>> PS: No need to vote if we have consensus. Taking a clue from ASF
>> members,
>>>> votes should be avoided at all cost, they mean that we do not have clear
>>>> consensus.
>>>>
>>>>
>>>>>
>>>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <runseb@gmail.com
>>>
>>>> wrote:
>>>>>>
>>>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>>>>>
>>>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>>>> Otherwise you should be able to do it cleanly.
>>>>>>>
>>>>>>> There's a good opportunity to do this next release. Instead of
>>>>>>> creating a release branch, we freeze master and start creating dev
>>>>>>> branches.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> This just amounts to treating master now like a release branch.
>> Getting
>>>> back to PL suggestion, that means
>>>>>> that any commit to master would be through a PR or MERGE request on
>> the
>>>> ML. Anything else will be reverted by the RM.
>>>>>>
>>>>>> Marcus, do you feel like writing down a little process for this and
>>>> some dates that we can target.
>>>>>> It would be nice to do this for 4.6.
>>>>>>
>>>>>>>
>>>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>>>> daan.hoogland@gmail.com> wrote:
>>>>>>>> We heavily invested in code now on master. Not looking forward to
>>>>>>>> backporting that.
>>>>>>>>
>>>>>>>> mobile dev with bilingual spelling checker used (read at your own
>>>> risk)
>>>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>>>
>>>>>>>>> Well, would we just swap the last release branch with master?
>> Master
>>>>>>>>> is the dev branch, and the last release is really what we have as a
>>>>>>>>> stable branch.
>>>>>>>>>
>>>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>>>> daan.hoogland@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>>>> runseb@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
>> pdion@cloudops.com
>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Today during the CloudStackdays we did a round table about
>>>> Release
>>>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>>>
>>>>>>>>>>>> ideas to change release planning
>>>>>>>>>>>>
>>>>>>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>>>>>>> involve
>>>>>>>>>>>> change on the core:
>>>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>>>> - There is an idea of going on a 2 weeks release model which
>> could
>>>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>>>> - Database schema version should be different then the
>> application
>>>>>>>>>>>> version.
>>>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>>>>>> simulator
>>>>>>>>>>>> job on PullRequest.
>>>>>>>>>>>> - Some people (I'm part of them) are concerned on our current
>> way
>>>> of
>>>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
>>>> 4.4.x,
>>>>>>>>>>>> 4.5.x). But the current level of confidence against latest
>> release
>>>>>>>>> is low,
>>>>>>>>>>>> so that need to be improved.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>>>>>> velocity, and
>>>>>>>>>>>> release branch stability. so we would like to propose few
>> change
>>>> in
>>>>>>>>> the
>>>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>>>
>>>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
>> merge
>>>>>>>>> request,
>>>>>>>>>>>> which would trigger a simulator job, ideally only if that pass
>>>> the PR
>>>>>>>>> would
>>>>>>>>>>>> be accepted and automatically merged. At this time, I think we
>>>> pretty
>>>>>>>>> much
>>>>>>>>>>>> have everything in place to do that. At a first step we would
>> use
>>>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>
>>>>>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>>>>>
>>>>>>>>>>> It means that if someone who is not RM directly commits to the
>>>> release
>>>>>>>>> branch, the commit will be reverted.
>>>>>>>>>>> And that from the beginning of the branching…
>>>>>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> IMHO, I think this would be a good step but I don’t think it goes
>>>> far
>>>>>>>>> enough.
>>>>>>>>>> Agreed here as well but let's take the step while discussing
>> further
>>>>>>>>>> steps and not implement to much process as well
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This still uses a paradigm where a release is made from a release
>>>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>>>> The problem here is that there is no stable point to fork from at
>>>> the
>>>>>>>>>> moment. We will get there and we shouldn't stop taking steps in
>> that
>>>>>>>>>> direction.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If we truly want to release faster, we need to release from the
>>>> same
>>>>>>>>> QA’d branch time after time….a release needs to be based on a
>>>> previous
>>>>>>>>> release
>>>>>>>>>>>
>>>>>>>>>>> Basically, we need a rolling release cycle. That will have the
>>>> added
>>>>>>>>> benefit to not leave releases behind and have to focus on
>>>> backporting.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please comments :-)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Daan
>>>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
Let's not do more quality improvement proces but just improve quality. If
anybody want to add to the pages on the wiki, you're welkom but nobody did
for long time. +1 for the present state of Sebastien's views on things. We
can refine at any time.
Op vr 1 mei 2015 om 09:55 schreef sebgoa <ru...@gmail.com>:
>
> On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org> wrote:
>
> > Hi,
> >
> > In my mind it was kind of making more sense to start by keeping 4.6 into
> a
> > separate branch, enforce pull-requests and deploy the CI. smaller step
> but
> > faster result, and from there, once we get stable with the CI
>
> I hear you.
>
> But we have waited for way too long for better CI. I see great efforts in
> that direction.
> But I personally do not want to wait any longer to make a move.
>
> We do open source, we should have fun, take risks, move fast, fail fast,
> recover etc….
>
> so let's JFDI
>
> > and git flow;
> > move into master, do fastest releases cycle. If we consider we can do all
> > that starting in 4.6, I'm all for it!
>
>
> Is there really a difference between creating a 4.6 and doing what you
> say, and tagging master (start) and doing it on master leading to 4.6
> release ?
>
> Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we
> can improve a bit on the QA then we win.
> Plus I think a different commit model will help a lot in quality.
>
> >
> > Marcus: are you preparing a proposal on this? wiki page? I can help
> >
>
> We can do this proposal on email..and once we have consensus write it up
> for archive in the wiki.
> If we move to the wiki now, this effort is going to die.
>
> > Seb: doesn't the vote would confirm the consensus?
> >
>
> if we have consensus no need for vote.
>
> > Raja: do we have any documentation somewhere on how to use, contribute
> to
> > the smoke test? that could be our start for the CI tests?
> >
> >
> > Cheers
> >
> >
> > On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
> > wrote:
> >
> >>
> >>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >>>
> >>> After reviewing the history as mentioned by Daan, unless we propose
> >>> and vote on a newer workflow model I think the best we can do is to
> >>> simply be more strict about commits to master. They all need to be
> >>> merges that have been tested against master before merge. This will in
> >>> theory make master more stable, but doesn't really change the workflow
> >>> we've already agreed upon and have been working under (although
> >>> bugfixes sometimes were not coming in from branches, and cherry-picked
> >>> bugfixes from branches will need to go into a branch first, tested
> >>> against master, and merged to master). We can essentially set a date
> >>> and do that any time, with some advance notice that direct commits
> >>> will be reverted.
> >>
> >> Yes +1.
> >>
> >> -Set a date
> >> -Tag master for reference
> >> -Find a volunteer or two to RM master
> >> -automatic revert on master if not from RM
> >> -all commits to master come from PR, need clear review and green tests
> >> -harden master (basic QA process), release 4.6 as a tag on master
> >> -all features and fixes need to be made on branches or forks and onus is
> >> on devs to rebase to master
> >> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3,
> 4.4,
> >> etc)
> >> -from there forward only maintain a linear release through master
> >>
> >> Feel free to add, tweak
> >>
> >> PS: No need to vote if we have consensus. Taking a clue from ASF
> members,
> >> votes should be avoided at all cost, they mean that we do not have clear
> >> consensus.
> >>
> >>
> >>>
> >>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <runseb@gmail.com
> >
> >> wrote:
> >>>>
> >>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
> >>>>>
> >>>>> Have they diverged that much? Due to cherry-picking, I guess.
> >>>>> Otherwise you should be able to do it cleanly.
> >>>>>
> >>>>> There's a good opportunity to do this next release. Instead of
> >>>>> creating a release branch, we freeze master and start creating dev
> >>>>> branches.
> >>>>
> >>>> +1
> >>>>
> >>>> This just amounts to treating master now like a release branch.
> Getting
> >> back to PL suggestion, that means
> >>>> that any commit to master would be through a PR or MERGE request on
> the
> >> ML. Anything else will be reverted by the RM.
> >>>>
> >>>> Marcus, do you feel like writing down a little process for this and
> >> some dates that we can target.
> >>>> It would be nice to do this for 4.6.
> >>>>
> >>>>>
> >>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> >> daan.hoogland@gmail.com> wrote:
> >>>>>> We heavily invested in code now on master. Not looking forward to
> >>>>>> backporting that.
> >>>>>>
> >>>>>> mobile dev with bilingual spelling checker used (read at your own
> >> risk)
> >>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>>>
> >>>>>>> Well, would we just swap the last release branch with master?
> Master
> >>>>>>> is the dev branch, and the last release is really what we have as a
> >>>>>>> stable branch.
> >>>>>>>
> >>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> >> daan.hoogland@gmail.com>
> >>>>>>> wrote:
> >>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> >> runseb@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <
> pdion@cloudops.com
> >>>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Today during the CloudStackdays we did a round table about
> >> Release
> >>>>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Quick bullet point discussions:
> >>>>>>>>>>
> >>>>>>>>>> ideas to change release planning
> >>>>>>>>>>
> >>>>>>>>>> - Plugin contribution is complicated because often a new plugin
> >>>>>>> involve
> >>>>>>>>>> change on the core:
> >>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>>>> - There is an idea of going on a 2 weeks release model which
> could
> >>>>>>>>>> introduce issue the database schema.
> >>>>>>>>>> - Database schema version should be different then the
> application
> >>>>>>>>>> version.
> >>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
> >>>>>>> simulator
> >>>>>>>>>> job on PullRequest.
> >>>>>>>>>> - Some people (I'm part of them) are concerned on our current
> way
> >> of
> >>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
> >> 4.4.x,
> >>>>>>>>>> 4.5.x). But the current level of confidence against latest
> release
> >>>>>>> is low,
> >>>>>>>>>> so that need to be improved.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> So, the main messages is that w'd like to improve the release
> >>>>>>> velocity, and
> >>>>>>>>>> release branch stability. so we would like to propose few
> change
> >> in
> >>>>>>> the
> >>>>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>>>
> >>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or
> merge
> >>>>>>> request,
> >>>>>>>>>> which would trigger a simulator job, ideally only if that pass
> >> the PR
> >>>>>>> would
> >>>>>>>>>> be accepted and automatically merged. At this time, I think we
> >> pretty
> >>>>>>> much
> >>>>>>>>>> have everything in place to do that. At a first step we would
> use
> >>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> We do need to realize what this means and be all fine with it.
> >>>>>>>>>
> >>>>>>>>> It means that if someone who is not RM directly commits to the
> >> release
> >>>>>>> branch, the commit will be reverted.
> >>>>>>>>> And that from the beginning of the branching…
> >>>>>>>> I agree and we can even go as far as reverting fixes that are
> >>>>>>>> cherry-picked in favour of merged forward.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> IMHO, I think this would be a good step but I don’t think it goes
> >> far
> >>>>>>> enough.
> >>>>>>>> Agreed here as well but let's take the step while discussing
> further
> >>>>>>>> steps and not implement to much process as well
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This still uses a paradigm where a release is made from a release
> >>>>>>> branch that was started from an unstable development branch.
> >>>>>>>>> Hence you still need *extensive* QA.
> >>>>>>>> The problem here is that there is no stable point to fork from at
> >> the
> >>>>>>>> moment. We will get there and we shouldn't stop taking steps in
> that
> >>>>>>>> direction.
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> If we truly want to release faster, we need to release from the
> >> same
> >>>>>>> QA’d branch time after time….a release needs to be based on a
> >> previous
> >>>>>>> release
> >>>>>>>>>
> >>>>>>>>> Basically, we need a rolling release cycle. That will have the
> >> added
> >>>>>>> benefit to not leave releases behind and have to focus on
> >> backporting.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Please comments :-)
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Daan
> >>>>>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <pd...@apache.org> wrote:
> Hi,
>
> In my mind it was kind of making more sense to start by keeping 4.6 into a
> separate branch, enforce pull-requests and deploy the CI. smaller step but
> faster result, and from there, once we get stable with the CI
I hear you.
But we have waited for way too long for better CI. I see great efforts in that direction.
But I personally do not want to wait any longer to make a move.
We do open source, we should have fun, take risks, move fast, fail fast, recover etc….
so let's JFDI
> and git flow;
> move into master, do fastest releases cycle. If we consider we can do all
> that starting in 4.6, I'm all for it!
Is there really a difference between creating a 4.6 and doing what you say, and tagging master (start) and doing it on master leading to 4.6 release ?
Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we can improve a bit on the QA then we win.
Plus I think a different commit model will help a lot in quality.
>
> Marcus: are you preparing a proposal on this? wiki page? I can help
>
We can do this proposal on email..and once we have consensus write it up for archive in the wiki.
If we move to the wiki now, this effort is going to die.
> Seb: doesn't the vote would confirm the consensus?
>
if we have consensus no need for vote.
> Raja: do we have any documentation somewhere on how to use, contribute to
> the smoke test? that could be our start for the CI tests?
>
>
> Cheers
>
>
> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
>
>>
>>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>>
>>> After reviewing the history as mentioned by Daan, unless we propose
>>> and vote on a newer workflow model I think the best we can do is to
>>> simply be more strict about commits to master. They all need to be
>>> merges that have been tested against master before merge. This will in
>>> theory make master more stable, but doesn't really change the workflow
>>> we've already agreed upon and have been working under (although
>>> bugfixes sometimes were not coming in from branches, and cherry-picked
>>> bugfixes from branches will need to go into a branch first, tested
>>> against master, and merged to master). We can essentially set a date
>>> and do that any time, with some advance notice that direct commits
>>> will be reverted.
>>
>> Yes +1.
>>
>> -Set a date
>> -Tag master for reference
>> -Find a volunteer or two to RM master
>> -automatic revert on master if not from RM
>> -all commits to master come from PR, need clear review and green tests
>> -harden master (basic QA process), release 4.6 as a tag on master
>> -all features and fixes need to be made on branches or forks and onus is
>> on devs to rebase to master
>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4,
>> etc)
>> -from there forward only maintain a linear release through master
>>
>> Feel free to add, tweak
>>
>> PS: No need to vote if we have consensus. Taking a clue from ASF members,
>> votes should be avoided at all cost, they mean that we do not have clear
>> consensus.
>>
>>
>>>
>>> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>>>>
>>>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>>>
>>>>> Have they diverged that much? Due to cherry-picking, I guess.
>>>>> Otherwise you should be able to do it cleanly.
>>>>>
>>>>> There's a good opportunity to do this next release. Instead of
>>>>> creating a release branch, we freeze master and start creating dev
>>>>> branches.
>>>>
>>>> +1
>>>>
>>>> This just amounts to treating master now like a release branch. Getting
>> back to PL suggestion, that means
>>>> that any commit to master would be through a PR or MERGE request on the
>> ML. Anything else will be reverted by the RM.
>>>>
>>>> Marcus, do you feel like writing down a little process for this and
>> some dates that we can target.
>>>> It would be nice to do this for 4.6.
>>>>
>>>>>
>>>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
>> daan.hoogland@gmail.com> wrote:
>>>>>> We heavily invested in code now on master. Not looking forward to
>>>>>> backporting that.
>>>>>>
>>>>>> mobile dev with bilingual spelling checker used (read at your own
>> risk)
>>>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>>>
>>>>>>> Well, would we just swap the last release branch with master? Master
>>>>>>> is the dev branch, and the last release is really what we have as a
>>>>>>> stable branch.
>>>>>>>
>>>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
>> daan.hoogland@gmail.com>
>>>>>>> wrote:
>>>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
>> runseb@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pdion@cloudops.com
>>>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Today during the CloudStackdays we did a round table about
>> Release
>>>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Quick bullet point discussions:
>>>>>>>>>>
>>>>>>>>>> ideas to change release planning
>>>>>>>>>>
>>>>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>>>>> involve
>>>>>>>>>> change on the core:
>>>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>>>>> introduce issue the database schema.
>>>>>>>>>> - Database schema version should be different then the application
>>>>>>>>>> version.
>>>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>>>> simulator
>>>>>>>>>> job on PullRequest.
>>>>>>>>>> - Some people (I'm part of them) are concerned on our current way
>> of
>>>>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
>> 4.4.x,
>>>>>>>>>> 4.5.x). But the current level of confidence against latest release
>>>>>>> is low,
>>>>>>>>>> so that need to be improved.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>>>> velocity, and
>>>>>>>>>> release branch stability. so we would like to propose few change
>> in
>>>>>>> the
>>>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>>>
>>>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>>>>> request,
>>>>>>>>>> which would trigger a simulator job, ideally only if that pass
>> the PR
>>>>>>> would
>>>>>>>>>> be accepted and automatically merged. At this time, I think we
>> pretty
>>>>>>> much
>>>>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>>>
>>>>>>>>> It means that if someone who is not RM directly commits to the
>> release
>>>>>>> branch, the commit will be reverted.
>>>>>>>>> And that from the beginning of the branching…
>>>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>>>> cherry-picked in favour of merged forward.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> IMHO, I think this would be a good step but I don’t think it goes
>> far
>>>>>>> enough.
>>>>>>>> Agreed here as well but let's take the step while discussing further
>>>>>>>> steps and not implement to much process as well
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This still uses a paradigm where a release is made from a release
>>>>>>> branch that was started from an unstable development branch.
>>>>>>>>> Hence you still need *extensive* QA.
>>>>>>>> The problem here is that there is no stable point to fork from at
>> the
>>>>>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>>>>>> direction.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If we truly want to release faster, we need to release from the
>> same
>>>>>>> QA’d branch time after time….a release needs to be based on a
>> previous
>>>>>>> release
>>>>>>>>>
>>>>>>>>> Basically, we need a rolling release cycle. That will have the
>> added
>>>>>>> benefit to not leave releases behind and have to focus on
>> backporting.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please comments :-)
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Daan
>>>>>>>
>>>>
>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Pierre-Luc Dion <pd...@apache.org>.
Hi,
In my mind it was kind of making more sense to start by keeping 4.6 into a
separate branch, enforce pull-requests and deploy the CI. smaller step but
faster result, and from there, once we get stable with the CI and git flow;
move into master, do fastest releases cycle. If we consider we can do all
that starting in 4.6, I'm all for it!
Marcus: are you preparing a proposal on this? wiki page? I can help
Seb: doesn't the vote would confirm the consensus?
Raja: do we have any documentation somewhere on how to use, contribute to
the smoke test? that could be our start for the CI tests?
Cheers
On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com>
wrote:
>
> > On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
> >
> > After reviewing the history as mentioned by Daan, unless we propose
> > and vote on a newer workflow model I think the best we can do is to
> > simply be more strict about commits to master. They all need to be
> > merges that have been tested against master before merge. This will in
> > theory make master more stable, but doesn't really change the workflow
> > we've already agreed upon and have been working under (although
> > bugfixes sometimes were not coming in from branches, and cherry-picked
> > bugfixes from branches will need to go into a branch first, tested
> > against master, and merged to master). We can essentially set a date
> > and do that any time, with some advance notice that direct commits
> > will be reverted.
>
> Yes +1.
>
> -Set a date
> -Tag master for reference
> -Find a volunteer or two to RM master
> -automatic revert on master if not from RM
> -all commits to master come from PR, need clear review and green tests
> -harden master (basic QA process), release 4.6 as a tag on master
> -all features and fixes need to be made on branches or forks and onus is
> on devs to rebase to master
> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4,
> etc)
> -from there forward only maintain a linear release through master
>
> Feel free to add, tweak
>
> PS: No need to vote if we have consensus. Taking a clue from ASF members,
> votes should be avoided at all cost, they mean that we do not have clear
> consensus.
>
>
> >
> > On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
> >>>
> >>> Have they diverged that much? Due to cherry-picking, I guess.
> >>> Otherwise you should be able to do it cleanly.
> >>>
> >>> There's a good opportunity to do this next release. Instead of
> >>> creating a release branch, we freeze master and start creating dev
> >>> branches.
> >>
> >> +1
> >>
> >> This just amounts to treating master now like a release branch. Getting
> back to PL suggestion, that means
> >> that any commit to master would be through a PR or MERGE request on the
> ML. Anything else will be reverted by the RM.
> >>
> >> Marcus, do you feel like writing down a little process for this and
> some dates that we can target.
> >> It would be nice to do this for 4.6.
> >>
> >>>
> >>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <
> daan.hoogland@gmail.com> wrote:
> >>>> We heavily invested in code now on master. Not looking forward to
> >>>> backporting that.
> >>>>
> >>>> mobile dev with bilingual spelling checker used (read at your own
> risk)
> >>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> >>>>
> >>>>> Well, would we just swap the last release branch with master? Master
> >>>>> is the dev branch, and the last release is really what we have as a
> >>>>> stable branch.
> >>>>>
> >>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <
> daan.hoogland@gmail.com>
> >>>>> wrote:
> >>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pdion@cloudops.com
> >
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Today during the CloudStackdays we did a round table about
> Release
> >>>>>>>> management targeting the next 4.6 releases.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Quick bullet point discussions:
> >>>>>>>>
> >>>>>>>> ideas to change release planning
> >>>>>>>>
> >>>>>>>> - Plugin contribution is complicated because often a new plugin
> >>>>> involve
> >>>>>>>> change on the core:
> >>>>>>>> - ex: storage plugin involve changes on Hypervisor code
> >>>>>>>> - There is an idea of going on a 2 weeks release model which could
> >>>>>>>> introduce issue the database schema.
> >>>>>>>> - Database schema version should be different then the application
> >>>>>>>> version.
> >>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
> >>>>> simulator
> >>>>>>>> job on PullRequest.
> >>>>>>>> - Some people (I'm part of them) are concerned on our current way
> of
> >>>>>>>> supporting and back porting fixes to multiple release (4.3.x,
> 4.4.x,
> >>>>>>>> 4.5.x). But the current level of confidence against latest release
> >>>>> is low,
> >>>>>>>> so that need to be improved.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> So, the main messages is that w'd like to improve the release
> >>>>> velocity, and
> >>>>>>>> release branch stability. so we would like to propose few change
> in
> >>>>> the
> >>>>>>>> way we would add code to the 4.6 branch as follow:
> >>>>>>>>
> >>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
> >>>>> request,
> >>>>>>>> which would trigger a simulator job, ideally only if that pass
> the PR
> >>>>> would
> >>>>>>>> be accepted and automatically merged. At this time, I think we
> pretty
> >>>>> much
> >>>>>>>> have everything in place to do that. At a first step we would use
> >>>>>>>> simulator+marvin jobs then improve tests coverage from there.
> >>>>>>>
> >>>>>>> +1
> >>>>>>>
> >>>>>>> We do need to realize what this means and be all fine with it.
> >>>>>>>
> >>>>>>> It means that if someone who is not RM directly commits to the
> release
> >>>>> branch, the commit will be reverted.
> >>>>>>> And that from the beginning of the branching…
> >>>>>> I agree and we can even go as far as reverting fixes that are
> >>>>>> cherry-picked in favour of merged forward.
> >>>>>>
> >>>>>>>
> >>>>>>> IMHO, I think this would be a good step but I don’t think it goes
> far
> >>>>> enough.
> >>>>>> Agreed here as well but let's take the step while discussing further
> >>>>>> steps and not implement to much process as well
> >>>>>>
> >>>>>>>
> >>>>>>> This still uses a paradigm where a release is made from a release
> >>>>> branch that was started from an unstable development branch.
> >>>>>>> Hence you still need *extensive* QA.
> >>>>>> The problem here is that there is no stable point to fork from at
> the
> >>>>>> moment. We will get there and we shouldn't stop taking steps in that
> >>>>>> direction.
> >>>>>>
> >>>>>>>
> >>>>>>> If we truly want to release faster, we need to release from the
> same
> >>>>> QA’d branch time after time….a release needs to be based on a
> previous
> >>>>> release
> >>>>>>>
> >>>>>>> Basically, we need a rolling release cycle. That will have the
> added
> >>>>> benefit to not leave releases behind and have to focus on
> backporting.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Please comments :-)
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Daan
> >>>>>
> >>
>
>
Re: [DISCUSS] 4.6 release management
Posted by David Nalley <da...@gnsa.us>.
On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>>
>> After reviewing the history as mentioned by Daan, unless we propose
>> and vote on a newer workflow model I think the best we can do is to
>> simply be more strict about commits to master. They all need to be
>> merges that have been tested against master before merge. This will in
>> theory make master more stable, but doesn't really change the workflow
>> we've already agreed upon and have been working under (although
>> bugfixes sometimes were not coming in from branches, and cherry-picked
>> bugfixes from branches will need to go into a branch first, tested
>> against master, and merged to master). We can essentially set a date
>> and do that any time, with some advance notice that direct commits
>> will be reverted.
>
> Yes +1.
>
> -Set a date
> -Tag master for reference
> -Find a volunteer or two to RM master
> -automatic revert on master if not from RM
> -all commits to master come from PR, need clear review and green tests
> -harden master (basic QA process), release 4.6 as a tag on master
> -all features and fixes need to be made on branches or forks and onus is on devs to rebase to master
> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4, etc)
> -from there forward only maintain a linear release through master
>
> Feel free to add, tweak
I'm +0 on the above - what would push me to +1 would be stripping the
RM as gatekeeper and letting CI be the gatekeeper (e.g. - all commits
go in via PR that tests successfully.) I don't think that an RM is
capable of understanding all of the pieces enough to judge any given
patch, especially a more complicated patch, and its a SPOF - it's also
incredibly difficult for a single person to keep up with all of the
pending patches.
I'd also be okay with must be reviewed by another committer so that
two committers have to agree.
Now, that said, if velocity is high, it will make kicking a release
out somewhat difficult as the amount of churn is going to be high.
>
> PS: No need to vote if we have consensus. Taking a clue from ASF members, votes should be avoided at all cost, they mean that we do not have clear consensus.
>
>
YES - this!!
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On Apr 29, 2015, at 9:49 PM, Marcus <sh...@gmail.com> wrote:
>
> After reviewing the history as mentioned by Daan, unless we propose
> and vote on a newer workflow model I think the best we can do is to
> simply be more strict about commits to master. They all need to be
> merges that have been tested against master before merge. This will in
> theory make master more stable, but doesn't really change the workflow
> we've already agreed upon and have been working under (although
> bugfixes sometimes were not coming in from branches, and cherry-picked
> bugfixes from branches will need to go into a branch first, tested
> against master, and merged to master). We can essentially set a date
> and do that any time, with some advance notice that direct commits
> will be reverted.
Yes +1.
-Set a date
-Tag master for reference
-Find a volunteer or two to RM master
-automatic revert on master if not from RM
-all commits to master come from PR, need clear review and green tests
-harden master (basic QA process), release 4.6 as a tag on master
-all features and fixes need to be made on branches or forks and onus is on devs to rebase to master
-brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4, etc)
-from there forward only maintain a linear release through master
Feel free to add, tweak
PS: No need to vote if we have consensus. Taking a clue from ASF members, votes should be avoided at all cost, they mean that we do not have clear consensus.
>
> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>
>>> Have they diverged that much? Due to cherry-picking, I guess.
>>> Otherwise you should be able to do it cleanly.
>>>
>>> There's a good opportunity to do this next release. Instead of
>>> creating a release branch, we freeze master and start creating dev
>>> branches.
>>
>> +1
>>
>> This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
>> that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM.
>>
>> Marcus, do you feel like writing down a little process for this and some dates that we can target.
>> It would be nice to do this for 4.6.
>>
>>>
>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>>>> We heavily invested in code now on master. Not looking forward to
>>>> backporting that.
>>>>
>>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>
>>>>> Well, would we just swap the last release branch with master? Master
>>>>> is the dev branch, and the last release is really what we have as a
>>>>> stable branch.
>>>>>
>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>>>> wrote:
>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>
>>>>>>>>
>>>>>>>> Quick bullet point discussions:
>>>>>>>>
>>>>>>>> ideas to change release planning
>>>>>>>>
>>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>>> involve
>>>>>>>> change on the core:
>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>>> introduce issue the database schema.
>>>>>>>> - Database schema version should be different then the application
>>>>>>>> version.
>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>> simulator
>>>>>>>> job on PullRequest.
>>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>>> 4.5.x). But the current level of confidence against latest release
>>>>> is low,
>>>>>>>> so that need to be improved.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>> velocity, and
>>>>>>>> release branch stability. so we would like to propose few change in
>>>>> the
>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>
>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>>> request,
>>>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>>>> would
>>>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>>>> much
>>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>
>>>>>>> It means that if someone who is not RM directly commits to the release
>>>>> branch, the commit will be reverted.
>>>>>>> And that from the beginning of the branching…
>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>> cherry-picked in favour of merged forward.
>>>>>>
>>>>>>>
>>>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>>>> enough.
>>>>>> Agreed here as well but let's take the step while discussing further
>>>>>> steps and not implement to much process as well
>>>>>>
>>>>>>>
>>>>>>> This still uses a paradigm where a release is made from a release
>>>>> branch that was started from an unstable development branch.
>>>>>>> Hence you still need *extensive* QA.
>>>>>> The problem here is that there is no stable point to fork from at the
>>>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>>>> direction.
>>>>>>
>>>>>>>
>>>>>>> If we truly want to release faster, we need to release from the same
>>>>> QA’d branch time after time….a release needs to be based on a previous
>>>>> release
>>>>>>>
>>>>>>> Basically, we need a rolling release cycle. That will have the added
>>>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>>>
>>>>>>>>
>>>>>>>> Please comments :-)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>>
>>
Re: [DISCUSS] 4.6 release management
Posted by Marcus <sh...@gmail.com>.
After reviewing the history as mentioned by Daan, unless we propose
and vote on a newer workflow model I think the best we can do is to
simply be more strict about commits to master. They all need to be
merges that have been tested against master before merge. This will in
theory make master more stable, but doesn't really change the workflow
we've already agreed upon and have been working under (although
bugfixes sometimes were not coming in from branches, and cherry-picked
bugfixes from branches will need to go into a branch first, tested
against master, and merged to master). We can essentially set a date
and do that any time, with some advance notice that direct commits
will be reverted.
On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>
>> Have they diverged that much? Due to cherry-picking, I guess.
>> Otherwise you should be able to do it cleanly.
>>
>> There's a good opportunity to do this next release. Instead of
>> creating a release branch, we freeze master and start creating dev
>> branches.
>
> +1
>
> This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
> that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM.
>
> Marcus, do you feel like writing down a little process for this and some dates that we can target.
> It would be nice to do this for 4.6.
>
>>
>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>>> We heavily invested in code now on master. Not looking forward to
>>> backporting that.
>>>
>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>
>>>> Well, would we just swap the last release branch with master? Master
>>>> is the dev branch, and the last release is really what we have as a
>>>> stable branch.
>>>>
>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>>> wrote:
>>>>>>>
>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>> management targeting the next 4.6 releases.
>>>>>>>
>>>>>>>
>>>>>>> Quick bullet point discussions:
>>>>>>>
>>>>>>> ideas to change release planning
>>>>>>>
>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>> involve
>>>>>>> change on the core:
>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>> introduce issue the database schema.
>>>>>>> - Database schema version should be different then the application
>>>>>>> version.
>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>> simulator
>>>>>>> job on PullRequest.
>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>> 4.5.x). But the current level of confidence against latest release
>>>> is low,
>>>>>>> so that need to be improved.
>>>>>>>
>>>>>>>
>>>>>>> So, the main messages is that w'd like to improve the release
>>>> velocity, and
>>>>>>> release branch stability. so we would like to propose few change in
>>>> the
>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>
>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>> request,
>>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>>> would
>>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>>> much
>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>
>>>>>> It means that if someone who is not RM directly commits to the release
>>>> branch, the commit will be reverted.
>>>>>> And that from the beginning of the branching…
>>>>> I agree and we can even go as far as reverting fixes that are
>>>>> cherry-picked in favour of merged forward.
>>>>>
>>>>>>
>>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>>> enough.
>>>>> Agreed here as well but let's take the step while discussing further
>>>>> steps and not implement to much process as well
>>>>>
>>>>>>
>>>>>> This still uses a paradigm where a release is made from a release
>>>> branch that was started from an unstable development branch.
>>>>>> Hence you still need *extensive* QA.
>>>>> The problem here is that there is no stable point to fork from at the
>>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>>> direction.
>>>>>
>>>>>>
>>>>>> If we truly want to release faster, we need to release from the same
>>>> QA’d branch time after time….a release needs to be based on a previous
>>>> release
>>>>>>
>>>>>> Basically, we need a rolling release cycle. That will have the added
>>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>>
>>>>>>>
>>>>>>> Please comments :-)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>
AW: [DISCUSS] 4.6 release management
Posted by "S. Brüseke - proIO GmbH" <s....@proio.com>.
Hi all,
it is really hard for a newbie to follow all of your thought regarding this. Can somebody please explain it a little bit more?
Thank you very much!
Mit freundlichen Grüßen / With kind regards,
Swen Brüseke
-----Ursprüngliche Nachricht-----
Von: Simon Weller [mailto:sweller@ena.com]
Gesendet: Montag, 20. April 2015 15:24
An: dev@cloudstack.apache.org
Betreff: Re: [DISCUSS] 4.6 release management
>________________________________________
>From: Sebastien Goasguen <ru...@gmail.com>
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management
> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
> branches.
>+1
>This just amounts to treating master now like a release branch. Getting
>back to PL suggestion, that means that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the >RM.
+1 on this.
Ultimately this will be painful to start with, but it will pay dividends in the future with a much more stable (and tested) master, and hence future releases will be of higher quality.
With stable (and frequent iterative) releases, there will be much less pressure to back port fixes/features, because the community will see taking a new release as low risk.
- Si
>Marcus, do you feel like writing down a little process for this and some dates that we can target.
>It would be nice to do this for 4.6.
>
> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>> We heavily invested in code now on master. Not looking forward to
>> backporting that.
>>
>> mobile dev with bilingual spelling checker used (read at your own
>> risk) Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>
>>> Well, would we just swap the last release branch with master? Master
>>> is the dev branch, and the last release is really what we have as a
>>> stable branch.
>>>
>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland
>>> <da...@gmail.com>
>>> wrote:
>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen
>>>> <ru...@gmail.com>
>>> wrote:
>>>>>
>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion
>>>>>> <pd...@cloudops.com>
>>> wrote:
>>>>>>
>>>>>> Today during the CloudStackdays we did a round table about
>>>>>> Release management targeting the next 4.6 releases.
>>>>>>
>>>>>>
>>>>>> Quick bullet point discussions:
>>>>>>
>>>>>> ideas to change release planning
>>>>>>
>>>>>> - Plugin contribution is complicated because often a new plugin
>>> involve
>>>>>> change on the core:
>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>> - There is an idea of going on a 2 weeks release model which
>>>>>> could introduce issue the database schema.
>>>>>> - Database schema version should be different then the
>>>>>> application version.
>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>> simulator
>>>>>> job on PullRequest.
>>>>>> - Some people (I'm part of them) are concerned on our current
>>>>>> way of supporting and back porting fixes to multiple release
>>>>>> (4.3.x, 4.4.x, 4.5.x). But the current level of confidence
>>>>>> against latest release
>>> is low,
>>>>>> so that need to be improved.
>>>>>>
>>>>>>
>>>>>> So, the main messages is that w'd like to improve the release
>>> velocity, and
>>>>>> release branch stability. so we would like to propose few change
>>>>>> in
>>> the
>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>
>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request,
>>>>>> which would trigger a simulator job, ideally only if that pass
>>>>>> the PR
>>> would
>>>>>> be accepted and automatically merged. At this time, I think we
>>>>>> pretty
>>> much
>>>>>> have everything in place to do that. At a first step we would use
>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>
>>>>> +1
>>>>>
>>>>> We do need to realize what this means and be all fine with it.
>>>>>
>>>>> It means that if someone who is not RM directly commits to the
>>>>> release
>>> branch, the commit will be reverted.
>>>>> And that from the beginning of the branching.
>>>> I agree and we can even go as far as reverting fixes that are
>>>> cherry-picked in favour of merged forward.
>>>>
>>>>>
>>>>> IMHO, I think this would be a good step but I don't think it goes
>>>>> far
>>> enough.
>>>> Agreed here as well but let's take the step while discussing
>>>> further steps and not implement to much process as well
>>>>
>>>>>
>>>>> This still uses a paradigm where a release is made from a release
>>> branch that was started from an unstable development branch.
>>>>> Hence you still need *extensive* QA.
>>>> The problem here is that there is no stable point to fork from at
>>>> the moment. We will get there and we shouldn't stop taking steps in
>>>> that direction.
>>>>
>>>>>
>>>>> If we truly want to release faster, we need to release from the
>>>>> same
>>> QA'd branch time after time..a release needs to be based on a
>>> previous release
>>>>>
>>>>> Basically, we need a rolling release cycle. That will have the
>>>>> added
>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>
>>>>>>
>>>>>> Please comments :-)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main
USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail.
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: [DISCUSS] 4.6 release management
Posted by sebgoa <ru...@gmail.com>.
On Apr 20, 2015, at 4:12 PM, S. Brüseke - proIO GmbH <s....@proio.com> wrote:
> Hi all,
>
> it is really hard for a newbie to follow all of your thought regarding this. Can somebody please explain it a little bit more?
> Thank you very much!
>
Hi Swen,
I will try.
Currently we develop cloudstack in the master branch, and create a 'release' branch for major releases.
Hence we have a 4.3 branch, a 4.4 branch etc….
We are currently on 4.5 , which means that what is master now will become our 4.5 release.
The issue comes when stabilizing a release branch.
A traditional approach would hand off the release branch to a QA team and let the QA team harden that branch over several months. This tends to make each release a somewhat different product of each other. It also creates a maintenance headache, as we have to abandon branches. We do not want anyone to feel abandoned on some dead branches, thus we maintain upgrade paths that can become complex, with fixes and features that can't be merged in various branches and regressions. Bottom line:
headache, heartache, nightmares, no fun.
This is not something specific to cloudstack and other projects face similar issues.
I am of the opinion that for our community this is not a workable model, as we do not have a dedicated QA team. Even though some of us are paid to work on CloudStack.
So we are talking about finding a better release management model, that would allow us to release faster and more stable software (not to say that it is unstable right now, just that things can be improved).
One model among many, would be to treat master as our release branch and merge features/fixes into master once we know they are valid and do not break anything. This would increase our trust in master as production software and put us on a path of continuous deployment with an iterative/rolling upgrade mindset.
Since all committers have write access to master, treating master as a release branch (for example), involves all of us reaching consensus and agreeing that a release manager will be the only one allowed to touch that branch (for instance). This also involves being able to release much faster (which we have to do official through manual votes for legal purposes), reducing scope of each release etc….
I hope that clarifies things a bit,
-Sebastien
> Mit freundlichen Grüßen / With kind regards,
>
> Swen Brüseke
>
> -----Ursprüngliche Nachricht-----
> Von: Simon Weller [mailto:sweller@ena.com]
> Gesendet: Montag, 20. April 2015 15:24
> An: dev@cloudstack.apache.org
> Betreff: Re: [DISCUSS] 4.6 release management
>
>> ________________________________________
>> From: Sebastien Goasguen <ru...@gmail.com>
>> Sent: Saturday, April 18, 2015 2:50 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] 4.6 release management
>
>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>
>> Have they diverged that much? Due to cherry-picking, I guess.
>> Otherwise you should be able to do it cleanly.
>>
>> There's a good opportunity to do this next release. Instead of
>> creating a release branch, we freeze master and start creating dev
>> branches.
>
>> +1
>
>> This just amounts to treating master now like a release branch. Getting
>> back to PL suggestion, that means that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the >RM.
>
> +1 on this.
>
> Ultimately this will be painful to start with, but it will pay dividends in the future with a much more stable (and tested) master, and hence future releases will be of higher quality.
> With stable (and frequent iterative) releases, there will be much less pressure to back port fixes/features, because the community will see taking a new release as low risk.
>
> - Si
>
>> Marcus, do you feel like writing down a little process for this and some dates that we can target.
>> It would be nice to do this for 4.6.
>
>>
>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>>> We heavily invested in code now on master. Not looking forward to
>>> backporting that.
>>>
>>> mobile dev with bilingual spelling checker used (read at your own
>>> risk) Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>
>>>> Well, would we just swap the last release branch with master? Master
>>>> is the dev branch, and the last release is really what we have as a
>>>> stable branch.
>>>>
>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland
>>>> <da...@gmail.com>
>>>> wrote:
>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen
>>>>> <ru...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion
>>>>>>> <pd...@cloudops.com>
>>>> wrote:
>>>>>>>
>>>>>>> Today during the CloudStackdays we did a round table about
>>>>>>> Release management targeting the next 4.6 releases.
>>>>>>>
>>>>>>>
>>>>>>> Quick bullet point discussions:
>>>>>>>
>>>>>>> ideas to change release planning
>>>>>>>
>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>> involve
>>>>>>> change on the core:
>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>> - There is an idea of going on a 2 weeks release model which
>>>>>>> could introduce issue the database schema.
>>>>>>> - Database schema version should be different then the
>>>>>>> application version.
>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>> simulator
>>>>>>> job on PullRequest.
>>>>>>> - Some people (I'm part of them) are concerned on our current
>>>>>>> way of supporting and back porting fixes to multiple release
>>>>>>> (4.3.x, 4.4.x, 4.5.x). But the current level of confidence
>>>>>>> against latest release
>>>> is low,
>>>>>>> so that need to be improved.
>>>>>>>
>>>>>>>
>>>>>>> So, the main messages is that w'd like to improve the release
>>>> velocity, and
>>>>>>> release branch stability. so we would like to propose few change
>>>>>>> in
>>>> the
>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>
>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>> request,
>>>>>>> which would trigger a simulator job, ideally only if that pass
>>>>>>> the PR
>>>> would
>>>>>>> be accepted and automatically merged. At this time, I think we
>>>>>>> pretty
>>>> much
>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>
>>>>>> It means that if someone who is not RM directly commits to the
>>>>>> release
>>>> branch, the commit will be reverted.
>>>>>> And that from the beginning of the branching.
>>>>> I agree and we can even go as far as reverting fixes that are
>>>>> cherry-picked in favour of merged forward.
>>>>>
>>>>>>
>>>>>> IMHO, I think this would be a good step but I don't think it goes
>>>>>> far
>>>> enough.
>>>>> Agreed here as well but let's take the step while discussing
>>>>> further steps and not implement to much process as well
>>>>>
>>>>>>
>>>>>> This still uses a paradigm where a release is made from a release
>>>> branch that was started from an unstable development branch.
>>>>>> Hence you still need *extensive* QA.
>>>>> The problem here is that there is no stable point to fork from at
>>>>> the moment. We will get there and we shouldn't stop taking steps in
>>>>> that direction.
>>>>>
>>>>>>
>>>>>> If we truly want to release faster, we need to release from the
>>>>>> same
>>>> QA'd branch time after time..a release needs to be based on a
>>>> previous release
>>>>>>
>>>>>> Basically, we need a rolling release cycle. That will have the
>>>>>> added
>>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>>
>>>>>>>
>>>>>>> Please comments :-)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>
>
>
> - proIO GmbH -
> Geschäftsführer: Swen Brüseke
> Sitz der Gesellschaft: Frankfurt am Main
>
> USt-IdNr. DE 267 075 918
> Registergericht: Frankfurt am Main - HRB 86239
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
> informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.
>
> This e-mail may contain confidential and/or privileged information.
> If you are not the intended recipient (or have received this e-mail in error) please notify
> the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
>
>
Re: [DISCUSS] 4.6 release management
Posted by Simon Weller <sw...@ena.com>.
>________________________________________
>From: Sebastien Goasguen <ru...@gmail.com>
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management
> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
> branches.
>+1
>This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
>that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the >RM.
+1 on this.
Ultimately this will be painful to start with, but it will pay dividends in the future with a much more stable (and tested) master, and hence future releases will be of higher quality.
With stable (and frequent iterative) releases, there will be much less pressure to back port fixes/features, because the community will see taking a new release as low risk.
- Si
>Marcus, do you feel like writing down a little process for this and some dates that we can target.
>It would be nice to do this for 4.6.
>
> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>> We heavily invested in code now on master. Not looking forward to
>> backporting that.
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>
>>> Well, would we just swap the last release branch with master? Master
>>> is the dev branch, and the last release is really what we have as a
>>> stable branch.
>>>
>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>> wrote:
>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>>
>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>> wrote:
>>>>>>
>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>> management targeting the next 4.6 releases.
>>>>>>
>>>>>>
>>>>>> Quick bullet point discussions:
>>>>>>
>>>>>> ideas to change release planning
>>>>>>
>>>>>> - Plugin contribution is complicated because often a new plugin
>>> involve
>>>>>> change on the core:
>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>> introduce issue the database schema.
>>>>>> - Database schema version should be different then the application
>>>>>> version.
>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>> simulator
>>>>>> job on PullRequest.
>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>> 4.5.x). But the current level of confidence against latest release
>>> is low,
>>>>>> so that need to be improved.
>>>>>>
>>>>>>
>>>>>> So, the main messages is that w'd like to improve the release
>>> velocity, and
>>>>>> release branch stability. so we would like to propose few change in
>>> the
>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>
>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request,
>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>> would
>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>> much
>>>>>> have everything in place to do that. At a first step we would use
>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>
>>>>> +1
>>>>>
>>>>> We do need to realize what this means and be all fine with it.
>>>>>
>>>>> It means that if someone who is not RM directly commits to the release
>>> branch, the commit will be reverted.
>>>>> And that from the beginning of the branching…
>>>> I agree and we can even go as far as reverting fixes that are
>>>> cherry-picked in favour of merged forward.
>>>>
>>>>>
>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>> enough.
>>>> Agreed here as well but let's take the step while discussing further
>>>> steps and not implement to much process as well
>>>>
>>>>>
>>>>> This still uses a paradigm where a release is made from a release
>>> branch that was started from an unstable development branch.
>>>>> Hence you still need *extensive* QA.
>>>> The problem here is that there is no stable point to fork from at the
>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>> direction.
>>>>
>>>>>
>>>>> If we truly want to release faster, we need to release from the same
>>> QA’d branch time after time….a release needs to be based on a previous
>>> release
>>>>>
>>>>> Basically, we need a rolling release cycle. That will have the added
>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>
>>>>>>
>>>>>> Please comments :-)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
Marcus, I think we decided to take small steps in the direction of
something resambling git-workflow instead of adopting it as a
standard. merging branches for fixes and features was one of those
steps. We had a pre-vote discussion on git-flow and it was rejected as
such. That shouldn't stop us from implementing parts of it that aren't
objected against.
On Fri, Apr 24, 2015 at 12:21 AM, Marcus <sh...@gmail.com> wrote:
> Before I rough draft anything, I just wanted to ask if we had voted on
> moving to git-workflow, and dropping the multiple release branch
> design. This seems like a significant change, and while good in many
> ways, it also seems that many users are seeking for point releases to
> their pet version and I'm not sure how they'll take to a response that
> they need to upgrade. Overall I think it will approve stability and
> focus our efforts, but have we had a vote around this change?
>
> On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>>
>>> Have they diverged that much? Due to cherry-picking, I guess.
>>> Otherwise you should be able to do it cleanly.
>>>
>>> There's a good opportunity to do this next release. Instead of
>>> creating a release branch, we freeze master and start creating dev
>>> branches.
>>
>> +1
>>
>> This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
>> that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM.
>>
>> Marcus, do you feel like writing down a little process for this and some dates that we can target.
>> It would be nice to do this for 4.6.
>>
>>>
>>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>>>> We heavily invested in code now on master. Not looking forward to
>>>> backporting that.
>>>>
>>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>>
>>>>> Well, would we just swap the last release branch with master? Master
>>>>> is the dev branch, and the last release is really what we have as a
>>>>> stable branch.
>>>>>
>>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>>>> wrote:
>>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>>> management targeting the next 4.6 releases.
>>>>>>>>
>>>>>>>>
>>>>>>>> Quick bullet point discussions:
>>>>>>>>
>>>>>>>> ideas to change release planning
>>>>>>>>
>>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>>> involve
>>>>>>>> change on the core:
>>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>>> introduce issue the database schema.
>>>>>>>> - Database schema version should be different then the application
>>>>>>>> version.
>>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>>> simulator
>>>>>>>> job on PullRequest.
>>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>>> 4.5.x). But the current level of confidence against latest release
>>>>> is low,
>>>>>>>> so that need to be improved.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, the main messages is that w'd like to improve the release
>>>>> velocity, and
>>>>>>>> release branch stability. so we would like to propose few change in
>>>>> the
>>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>>
>>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>>> request,
>>>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>>>> would
>>>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>>>> much
>>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>>
>>>>>>> It means that if someone who is not RM directly commits to the release
>>>>> branch, the commit will be reverted.
>>>>>>> And that from the beginning of the branching…
>>>>>> I agree and we can even go as far as reverting fixes that are
>>>>>> cherry-picked in favour of merged forward.
>>>>>>
>>>>>>>
>>>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>>>> enough.
>>>>>> Agreed here as well but let's take the step while discussing further
>>>>>> steps and not implement to much process as well
>>>>>>
>>>>>>>
>>>>>>> This still uses a paradigm where a release is made from a release
>>>>> branch that was started from an unstable development branch.
>>>>>>> Hence you still need *extensive* QA.
>>>>>> The problem here is that there is no stable point to fork from at the
>>>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>>>> direction.
>>>>>>
>>>>>>>
>>>>>>> If we truly want to release faster, we need to release from the same
>>>>> QA’d branch time after time….a release needs to be based on a previous
>>>>> release
>>>>>>>
>>>>>>> Basically, we need a rolling release cycle. That will have the added
>>>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>>>
>>>>>>>>
>>>>>>>> Please comments :-)
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daan
>>>>>
>>
--
Daan
Re: [DISCUSS] 4.6 release management
Posted by Marcus <sh...@gmail.com>.
Before I rough draft anything, I just wanted to ask if we had voted on
moving to git-workflow, and dropping the multiple release branch
design. This seems like a significant change, and while good in many
ways, it also seems that many users are seeking for point releases to
their pet version and I'm not sure how they'll take to a response that
they need to upgrade. Overall I think it will approve stability and
focus our efforts, but have we had a vote around this change?
On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>>
>> Have they diverged that much? Due to cherry-picking, I guess.
>> Otherwise you should be able to do it cleanly.
>>
>> There's a good opportunity to do this next release. Instead of
>> creating a release branch, we freeze master and start creating dev
>> branches.
>
> +1
>
> This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
> that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM.
>
> Marcus, do you feel like writing down a little process for this and some dates that we can target.
> It would be nice to do this for 4.6.
>
>>
>> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>>> We heavily invested in code now on master. Not looking forward to
>>> backporting that.
>>>
>>> mobile dev with bilingual spelling checker used (read at your own risk)
>>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>>
>>>> Well, would we just swap the last release branch with master? Master
>>>> is the dev branch, and the last release is really what we have as a
>>>> stable branch.
>>>>
>>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>>> wrote:
>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>>> wrote:
>>>>>>>
>>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>>> management targeting the next 4.6 releases.
>>>>>>>
>>>>>>>
>>>>>>> Quick bullet point discussions:
>>>>>>>
>>>>>>> ideas to change release planning
>>>>>>>
>>>>>>> - Plugin contribution is complicated because often a new plugin
>>>> involve
>>>>>>> change on the core:
>>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>>> introduce issue the database schema.
>>>>>>> - Database schema version should be different then the application
>>>>>>> version.
>>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>>> simulator
>>>>>>> job on PullRequest.
>>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>>> 4.5.x). But the current level of confidence against latest release
>>>> is low,
>>>>>>> so that need to be improved.
>>>>>>>
>>>>>>>
>>>>>>> So, the main messages is that w'd like to improve the release
>>>> velocity, and
>>>>>>> release branch stability. so we would like to propose few change in
>>>> the
>>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>>
>>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>>> request,
>>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>>> would
>>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>>> much
>>>>>>> have everything in place to do that. At a first step we would use
>>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> We do need to realize what this means and be all fine with it.
>>>>>>
>>>>>> It means that if someone who is not RM directly commits to the release
>>>> branch, the commit will be reverted.
>>>>>> And that from the beginning of the branching…
>>>>> I agree and we can even go as far as reverting fixes that are
>>>>> cherry-picked in favour of merged forward.
>>>>>
>>>>>>
>>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>>> enough.
>>>>> Agreed here as well but let's take the step while discussing further
>>>>> steps and not implement to much process as well
>>>>>
>>>>>>
>>>>>> This still uses a paradigm where a release is made from a release
>>>> branch that was started from an unstable development branch.
>>>>>> Hence you still need *extensive* QA.
>>>>> The problem here is that there is no stable point to fork from at the
>>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>>> direction.
>>>>>
>>>>>>
>>>>>> If we truly want to release faster, we need to release from the same
>>>> QA’d branch time after time….a release needs to be based on a previous
>>>> release
>>>>>>
>>>>>> Basically, we need a rolling release cycle. That will have the added
>>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>>
>>>>>>>
>>>>>>> Please comments :-)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Daan
>>>>
>
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On Apr 18, 2015, at 8:36 AM, Marcus <sh...@gmail.com> wrote:
>
> Have they diverged that much? Due to cherry-picking, I guess.
> Otherwise you should be able to do it cleanly.
>
> There's a good opportunity to do this next release. Instead of
> creating a release branch, we freeze master and start creating dev
> branches.
+1
This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means
that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM.
Marcus, do you feel like writing down a little process for this and some dates that we can target.
It would be nice to do this for 4.6.
>
> On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
>> We heavily invested in code now on master. Not looking forward to
>> backporting that.
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>>
>>> Well, would we just swap the last release branch with master? Master
>>> is the dev branch, and the last release is really what we have as a
>>> stable branch.
>>>
>>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>>> wrote:
>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>>> wrote:
>>>>>
>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>>> wrote:
>>>>>>
>>>>>> Today during the CloudStackdays we did a round table about Release
>>>>>> management targeting the next 4.6 releases.
>>>>>>
>>>>>>
>>>>>> Quick bullet point discussions:
>>>>>>
>>>>>> ideas to change release planning
>>>>>>
>>>>>> - Plugin contribution is complicated because often a new plugin
>>> involve
>>>>>> change on the core:
>>>>>> - ex: storage plugin involve changes on Hypervisor code
>>>>>> - There is an idea of going on a 2 weeks release model which could
>>>>>> introduce issue the database schema.
>>>>>> - Database schema version should be different then the application
>>>>>> version.
>>>>>> - There is a will to enforce git workflow in 4.6 and trigger
>>> simulator
>>>>>> job on PullRequest.
>>>>>> - Some people (I'm part of them) are concerned on our current way of
>>>>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>>>>> 4.5.x). But the current level of confidence against latest release
>>> is low,
>>>>>> so that need to be improved.
>>>>>>
>>>>>>
>>>>>> So, the main messages is that w'd like to improve the release
>>> velocity, and
>>>>>> release branch stability. so we would like to propose few change in
>>> the
>>>>>> way we would add code to the 4.6 branch as follow:
>>>>>>
>>>>>> - All new contribution to 4.6 would be thru Pull Request or merge
>>> request,
>>>>>> which would trigger a simulator job, ideally only if that pass the PR
>>> would
>>>>>> be accepted and automatically merged. At this time, I think we pretty
>>> much
>>>>>> have everything in place to do that. At a first step we would use
>>>>>> simulator+marvin jobs then improve tests coverage from there.
>>>>>
>>>>> +1
>>>>>
>>>>> We do need to realize what this means and be all fine with it.
>>>>>
>>>>> It means that if someone who is not RM directly commits to the release
>>> branch, the commit will be reverted.
>>>>> And that from the beginning of the branching…
>>>> I agree and we can even go as far as reverting fixes that are
>>>> cherry-picked in favour of merged forward.
>>>>
>>>>>
>>>>> IMHO, I think this would be a good step but I don’t think it goes far
>>> enough.
>>>> Agreed here as well but let's take the step while discussing further
>>>> steps and not implement to much process as well
>>>>
>>>>>
>>>>> This still uses a paradigm where a release is made from a release
>>> branch that was started from an unstable development branch.
>>>>> Hence you still need *extensive* QA.
>>>> The problem here is that there is no stable point to fork from at the
>>>> moment. We will get there and we shouldn't stop taking steps in that
>>>> direction.
>>>>
>>>>>
>>>>> If we truly want to release faster, we need to release from the same
>>> QA’d branch time after time….a release needs to be based on a previous
>>> release
>>>>>
>>>>> Basically, we need a rolling release cycle. That will have the added
>>> benefit to not leave releases behind and have to focus on backporting.
>>>>>
>>>>>>
>>>>>> Please comments :-)
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Daan
>>>
Re: [DISCUSS] 4.6 release management
Posted by Marcus <sh...@gmail.com>.
Have they diverged that much? Due to cherry-picking, I guess.
Otherwise you should be able to do it cleanly.
There's a good opportunity to do this next release. Instead of
creating a release branch, we freeze master and start creating dev
branches.
On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <da...@gmail.com> wrote:
> We heavily invested in code now on master. Not looking forward to
> backporting that.
>
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
>
>> Well, would we just swap the last release branch with master? Master
>> is the dev branch, and the last release is really what we have as a
>> stable branch.
>>
>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
>> wrote:
>> > On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
>> wrote:
>> >>
>> >>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
>> wrote:
>> >>>
>> >>> Today during the CloudStackdays we did a round table about Release
>> >>> management targeting the next 4.6 releases.
>> >>>
>> >>>
>> >>> Quick bullet point discussions:
>> >>>
>> >>> ideas to change release planning
>> >>>
>> >>> - Plugin contribution is complicated because often a new plugin
>> involve
>> >>> change on the core:
>> >>> - ex: storage plugin involve changes on Hypervisor code
>> >>> - There is an idea of going on a 2 weeks release model which could
>> >>> introduce issue the database schema.
>> >>> - Database schema version should be different then the application
>> >>> version.
>> >>> - There is a will to enforce git workflow in 4.6 and trigger
>> simulator
>> >>> job on PullRequest.
>> >>> - Some people (I'm part of them) are concerned on our current way of
>> >>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>> >>> 4.5.x). But the current level of confidence against latest release
>> is low,
>> >>> so that need to be improved.
>> >>>
>> >>>
>> >>> So, the main messages is that w'd like to improve the release
>> velocity, and
>> >>> release branch stability. so we would like to propose few change in
>> the
>> >>> way we would add code to the 4.6 branch as follow:
>> >>>
>> >>> - All new contribution to 4.6 would be thru Pull Request or merge
>> request,
>> >>> which would trigger a simulator job, ideally only if that pass the PR
>> would
>> >>> be accepted and automatically merged. At this time, I think we pretty
>> much
>> >>> have everything in place to do that. At a first step we would use
>> >>> simulator+marvin jobs then improve tests coverage from there.
>> >>
>> >> +1
>> >>
>> >> We do need to realize what this means and be all fine with it.
>> >>
>> >> It means that if someone who is not RM directly commits to the release
>> branch, the commit will be reverted.
>> >> And that from the beginning of the branching…
>> > I agree and we can even go as far as reverting fixes that are
>> > cherry-picked in favour of merged forward.
>> >
>> >>
>> >> IMHO, I think this would be a good step but I don’t think it goes far
>> enough.
>> > Agreed here as well but let's take the step while discussing further
>> > steps and not implement to much process as well
>> >
>> >>
>> >> This still uses a paradigm where a release is made from a release
>> branch that was started from an unstable development branch.
>> >> Hence you still need *extensive* QA.
>> > The problem here is that there is no stable point to fork from at the
>> > moment. We will get there and we shouldn't stop taking steps in that
>> > direction.
>> >
>> >>
>> >> If we truly want to release faster, we need to release from the same
>> QA’d branch time after time….a release needs to be based on a previous
>> release
>> >>
>> >> Basically, we need a rolling release cycle. That will have the added
>> benefit to not leave releases behind and have to focus on backporting.
>> >>
>> >>>
>> >>> Please comments :-)
>> >>
>> >
>> >
>> >
>> > --
>> > Daan
>>
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
We heavily invested in code now on master. Not looking forward to
backporting that.
mobile dev with bilingual spelling checker used (read at your own risk)
Op 17 apr. 2015 21:02 schreef "Marcus" <sh...@gmail.com>:
> Well, would we just swap the last release branch with master? Master
> is the dev branch, and the last release is really what we have as a
> stable branch.
>
> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com>
> wrote:
> > On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com>
> wrote:
> >>
> >>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com>
> wrote:
> >>>
> >>> Today during the CloudStackdays we did a round table about Release
> >>> management targeting the next 4.6 releases.
> >>>
> >>>
> >>> Quick bullet point discussions:
> >>>
> >>> ideas to change release planning
> >>>
> >>> - Plugin contribution is complicated because often a new plugin
> involve
> >>> change on the core:
> >>> - ex: storage plugin involve changes on Hypervisor code
> >>> - There is an idea of going on a 2 weeks release model which could
> >>> introduce issue the database schema.
> >>> - Database schema version should be different then the application
> >>> version.
> >>> - There is a will to enforce git workflow in 4.6 and trigger
> simulator
> >>> job on PullRequest.
> >>> - Some people (I'm part of them) are concerned on our current way of
> >>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
> >>> 4.5.x). But the current level of confidence against latest release
> is low,
> >>> so that need to be improved.
> >>>
> >>>
> >>> So, the main messages is that w'd like to improve the release
> velocity, and
> >>> release branch stability. so we would like to propose few change in
> the
> >>> way we would add code to the 4.6 branch as follow:
> >>>
> >>> - All new contribution to 4.6 would be thru Pull Request or merge
> request,
> >>> which would trigger a simulator job, ideally only if that pass the PR
> would
> >>> be accepted and automatically merged. At this time, I think we pretty
> much
> >>> have everything in place to do that. At a first step we would use
> >>> simulator+marvin jobs then improve tests coverage from there.
> >>
> >> +1
> >>
> >> We do need to realize what this means and be all fine with it.
> >>
> >> It means that if someone who is not RM directly commits to the release
> branch, the commit will be reverted.
> >> And that from the beginning of the branching…
> > I agree and we can even go as far as reverting fixes that are
> > cherry-picked in favour of merged forward.
> >
> >>
> >> IMHO, I think this would be a good step but I don’t think it goes far
> enough.
> > Agreed here as well but let's take the step while discussing further
> > steps and not implement to much process as well
> >
> >>
> >> This still uses a paradigm where a release is made from a release
> branch that was started from an unstable development branch.
> >> Hence you still need *extensive* QA.
> > The problem here is that there is no stable point to fork from at the
> > moment. We will get there and we shouldn't stop taking steps in that
> > direction.
> >
> >>
> >> If we truly want to release faster, we need to release from the same
> QA’d branch time after time….a release needs to be based on a previous
> release
> >>
> >> Basically, we need a rolling release cycle. That will have the added
> benefit to not leave releases behind and have to focus on backporting.
> >>
> >>>
> >>> Please comments :-)
> >>
> >
> >
> >
> > --
> > Daan
>
Re: [DISCUSS] 4.6 release management
Posted by Marcus <sh...@gmail.com>.
Well, would we just swap the last release branch with master? Master
is the dev branch, and the last release is really what we have as a
stable branch.
On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <da...@gmail.com> wrote:
> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>>
>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>>
>>> Today during the CloudStackdays we did a round table about Release
>>> management targeting the next 4.6 releases.
>>>
>>>
>>> Quick bullet point discussions:
>>>
>>> ideas to change release planning
>>>
>>> - Plugin contribution is complicated because often a new plugin involve
>>> change on the core:
>>> - ex: storage plugin involve changes on Hypervisor code
>>> - There is an idea of going on a 2 weeks release model which could
>>> introduce issue the database schema.
>>> - Database schema version should be different then the application
>>> version.
>>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>>> job on PullRequest.
>>> - Some people (I'm part of them) are concerned on our current way of
>>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>>> 4.5.x). But the current level of confidence against latest release is low,
>>> so that need to be improved.
>>>
>>>
>>> So, the main messages is that w'd like to improve the release velocity, and
>>> release branch stability. so we would like to propose few change in the
>>> way we would add code to the 4.6 branch as follow:
>>>
>>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>>> which would trigger a simulator job, ideally only if that pass the PR would
>>> be accepted and automatically merged. At this time, I think we pretty much
>>> have everything in place to do that. At a first step we would use
>>> simulator+marvin jobs then improve tests coverage from there.
>>
>> +1
>>
>> We do need to realize what this means and be all fine with it.
>>
>> It means that if someone who is not RM directly commits to the release branch, the commit will be reverted.
>> And that from the beginning of the branching…
> I agree and we can even go as far as reverting fixes that are
> cherry-picked in favour of merged forward.
>
>>
>> IMHO, I think this would be a good step but I don’t think it goes far enough.
> Agreed here as well but let's take the step while discussing further
> steps and not implement to much process as well
>
>>
>> This still uses a paradigm where a release is made from a release branch that was started from an unstable development branch.
>> Hence you still need *extensive* QA.
> The problem here is that there is no stable point to fork from at the
> moment. We will get there and we shouldn't stop taking steps in that
> direction.
>
>>
>> If we truly want to release faster, we need to release from the same QA’d branch time after time….a release needs to be based on a previous release
>>
>> Basically, we need a rolling release cycle. That will have the added benefit to not leave releases behind and have to focus on backporting.
>>
>>>
>>> Please comments :-)
>>
>
>
>
> --
> Daan
Re: [DISCUSS] 4.6 release management
Posted by Daan Hoogland <da...@gmail.com>.
On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>>
>> Today during the CloudStackdays we did a round table about Release
>> management targeting the next 4.6 releases.
>>
>>
>> Quick bullet point discussions:
>>
>> ideas to change release planning
>>
>> - Plugin contribution is complicated because often a new plugin involve
>> change on the core:
>> - ex: storage plugin involve changes on Hypervisor code
>> - There is an idea of going on a 2 weeks release model which could
>> introduce issue the database schema.
>> - Database schema version should be different then the application
>> version.
>> - There is a will to enforce git workflow in 4.6 and trigger simulator
>> job on PullRequest.
>> - Some people (I'm part of them) are concerned on our current way of
>> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
>> 4.5.x). But the current level of confidence against latest release is low,
>> so that need to be improved.
>>
>>
>> So, the main messages is that w'd like to improve the release velocity, and
>> release branch stability. so we would like to propose few change in the
>> way we would add code to the 4.6 branch as follow:
>>
>> - All new contribution to 4.6 would be thru Pull Request or merge request,
>> which would trigger a simulator job, ideally only if that pass the PR would
>> be accepted and automatically merged. At this time, I think we pretty much
>> have everything in place to do that. At a first step we would use
>> simulator+marvin jobs then improve tests coverage from there.
>
> +1
>
> We do need to realize what this means and be all fine with it.
>
> It means that if someone who is not RM directly commits to the release branch, the commit will be reverted.
> And that from the beginning of the branching…
I agree and we can even go as far as reverting fixes that are
cherry-picked in favour of merged forward.
>
> IMHO, I think this would be a good step but I don’t think it goes far enough.
Agreed here as well but let's take the step while discussing further
steps and not implement to much process as well
>
> This still uses a paradigm where a release is made from a release branch that was started from an unstable development branch.
> Hence you still need *extensive* QA.
The problem here is that there is no stable point to fork from at the
moment. We will get there and we shouldn't stop taking steps in that
direction.
>
> If we truly want to release faster, we need to release from the same QA’d branch time after time….a release needs to be based on a previous release
>
> Basically, we need a rolling release cycle. That will have the added benefit to not leave releases behind and have to focus on backporting.
>
>>
>> Please comments :-)
>
--
Daan
Re: [DISCUSS] 4.6 release management
Posted by Sebastien Goasguen <ru...@gmail.com>.
> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com> wrote:
>
> Today during the CloudStackdays we did a round table about Release
> management targeting the next 4.6 releases.
>
>
> Quick bullet point discussions:
>
> ideas to change release planning
>
> - Plugin contribution is complicated because often a new plugin involve
> change on the core:
> - ex: storage plugin involve changes on Hypervisor code
> - There is an idea of going on a 2 weeks release model which could
> introduce issue the database schema.
> - Database schema version should be different then the application
> version.
> - There is a will to enforce git workflow in 4.6 and trigger simulator
> job on PullRequest.
> - Some people (I'm part of them) are concerned on our current way of
> supporting and back porting fixes to multiple release (4.3.x, 4.4.x,
> 4.5.x). But the current level of confidence against latest release is low,
> so that need to be improved.
>
>
> So, the main messages is that w'd like to improve the release velocity, and
> release branch stability. so we would like to propose few change in the
> way we would add code to the 4.6 branch as follow:
>
> - All new contribution to 4.6 would be thru Pull Request or merge request,
> which would trigger a simulator job, ideally only if that pass the PR would
> be accepted and automatically merged. At this time, I think we pretty much
> have everything in place to do that. At a first step we would use
> simulator+marvin jobs then improve tests coverage from there.
+1
We do need to realize what this means and be all fine with it.
It means that if someone who is not RM directly commits to the release branch, the commit will be reverted.
And that from the beginning of the branching…
IMHO, I think this would be a good step but I don’t think it goes far enough.
This still uses a paradigm where a release is made from a release branch that was started from an unstable development branch.
Hence you still need *extensive* QA.
If we truly want to release faster, we need to release from the same QA’d branch time after time….a release needs to be based on a previous release
Basically, we need a rolling release cycle. That will have the added benefit to not leave releases behind and have to focus on backporting.
>
> Please comments :-)