cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [ACS 4.4] Cherry pick request
Date Fri, 18 Jul 2014 04:08:52 GMT
I see, Daan - thanks for the clarification.

This is probably another good reason why we should seriously consider
implementing the branching approach Sebastien recommended here:

http://nvie.com/posts/a-successful-git-branching-model/


On Thu, Jul 17, 2014 at 10:06 PM, Daan Hoogland <daan.hoogland@gmail.com>
wrote:

> That is not the confusion Mike. The problem is that some changes that
> don't go into 4.4 keep causing conflicts. I made the mistake of adding
> the conflicting lines this time. this 4.4-forward branch is not
> suitable for providing cherry-picks for an RM because of this. I thin
> people should just branch 4.4 for their changes and let me cherry-pick
> from there. Also the automation tests running on 4.4-forward instead
> of 4.4 is not very useful.
>
>
>
> On Fri, Jul 18, 2014 at 6:00 AM, Mike Tutkowski
> <mike.tutkowski@solidfire.com> wrote:
> > Perhaps there is some confusion again as to the nature of the 4.4-forward
> > branch.
> >
> > A while back, we agreed that changes put in here would not be cherry
> picked
> > to 4.4 unless requested so by the developer and agreed to by the RM.
> >
> > Changes in 4.4-forward that do not go into 4.4 will at least go into
> 4.4.1
> > (assuming such a release happens).
> >
> >
> > On Thu, Jul 17, 2014 at 9:48 PM, Daan Hoogland <daan.hoogland@gmail.com>
> > wrote:
> >
> >> They keep coming in with cherry-picks that include this file. I will
> >> remove them.
> >>
> >> On Fri, Jul 18, 2014 at 12:22 AM, Nitin Mehta <Nitin.Mehta@citrix.com>
> >> wrote:
> >> > Hi Daan - I am not sure I get your point here. These changes were put
> in
> >> > as I want them in 4.4.1, but were not critical enough to be put in
> 4.4.
> >> >
> >> > Thanks,
> >> > -Nitin
> >> >
> >> > On 17/07/14 2:58 PM, "Daan Hoogland" <daan.hoogland@gmail.com> wrote:
> >> >
> >> >>sure? I saw that the last few lines where not in the last version.
> >> >>
> >> >>I'm not confortable with this bit, it has been coming up a few time
> >> >>before already looks like some commit on 4.4-forward is trying to
> >> >>sneak it's way into the release:
> >> >>
> >> >>@@ -2439,4 +2474,16 @@
> >> >>   CONSTRAINT
> >> `fk_lb_healthcheck_policy_details__lb_healthcheck_policy_id`
> >> >>FOREIGN KEY
> >>
> >>
> >>`fk_lb_healthcheck_policy_details__lb_healthcheck_policy_id`(`lb_policy_id
> >> >>`)
> >> >>REFERENCES `load_balancer_healthcheck_policies`(`id`) ON DELETE
> >> >>CASCADE
> >> >> ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> >> >>
> >> >>+ALTER TABLE `cloud`.`snapshot_policy` ADD COLUMN `display` tinyint(1)
> >> >>NOT NULL DEFAULT '1' COMMENT 'True if the policy can be displayed to
> >> >>the end user';
> >> >>+
> >> >>+CREATE TABLE `cloud`.`snapshot_policy_details` (
> >> >>+  `id` bigint unsigned NOT NULL auto_increment,
> >> >>+  `policy_id` bigint unsigned NOT NULL COMMENT 'snapshot policy id',
> >> >>+  `name` varchar(255) NOT NULL,
> >> >>+  `value` varchar(1024) NOT NULL,
> >> >>+  `display` tinyint(1) NOT NULL DEFAULT '1' COMMENT 'True if the
> >> >>detail can be displayed to the end user',
> >> >>+  PRIMARY KEY (`id`),
> >> >>+  CONSTRAINT `fk_snapshot_policy_details__snapshot_policy_id` FOREIGN
> >> >>KEY `fk_snapshot_policy_details__snapshot_policy_id`(`policy_id`)
> >> >>REFERENCES `snapshot_policy`(`id`) ON DELETE CASCADE
> >> >>+) ENGINE=InnoDB DEFAULT CHARSET=utf8;
> >> >>+
> >> >> INSERT INTO `cloud`.`configuration`(category, instance, component,
> >> >>name, value, description, default_value) VALUES ('Advanced',
> >> >>'DEFAULT', 'management-server', 'vm.password.length', '6', 'Specifies
> >> >>the length of a randomly generated password', '6') ON DUPLICATE KEY
> >> >>UPDATE category='Advanced';
> >> >>
> >> >>On Thu, Jul 17, 2014 at 11:53 PM, Amogh Vasekar
> >> >><amogh.vasekar@citrix.com> wrote:
> >> >>> Seems good, looks like was an issue with a newline somewhere. But
> >> >>>deploydb
> >> >>> went fine on 4.4
> >> >>>
> >> >>> Thanks,
> >> >>> Amogh
> >> >>>
> >> >>> On 7/17/14 2:42 PM, "Daan Hoogland" <daan.hoogland@gmail.com>
> wrote:
> >> >>>
> >> >>>>Amogh, I couldn't help myself. please have a look at the resulting
> >> >>>>setup/db/db/schema-430to440.sql
> >> >>>>
> >> >>>>On Thu, Jul 17, 2014 at 11:35 PM, Daan Hoogland
> >> >>>><daan.hoogland@gmail.com>
> >> >>>>wrote:
> >> >>>>> On Thu, Jul 17, 2014 at 11:19 PM, Amogh Vasekar
> >> >>>>> <amogh.vasekar@citrix.com> wrote:
> >> >>>>>> c8ca15b95a57a3d79b71c76c913e295f6490f05d
> >> >>>>>
> >> >>>>> Amogh, it has conflicts. I will have a look at those in
the
> morning
> >> >>>>>
> >> >>>>> --
> >> >>>>> Daan
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>--
> >> >>>>Daan
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>Daan
> >> >
> >>
> >>
> >>
> >> --
> >> Daan
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*™*
>
>
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message