Scheduling for Amazon DynamoDB Project

[Lewis John Mcgibbney <le...@gmail.com>]

Hi Everyone,

W.r.t the ongoing project, we (Renato and myself) have been discussing
a couple of options for storage of the output code.

1) Branch trunk (GoraAmazon) and incrementally update this as the
project progresses over the summer. Once the project is finished merge
the branch with trunk and keep going with Trunk. This would require
Renato to have access to commit rights and the community would need to
agree to this.
2) Upload all patches to the Jira issue. I (and anyone interested) can
then review patches locally and commit them to trunk once the code is
deemed suitable.
3) Renato can fork our Gora Github mirror, sync his own mirror to the
Github one, then incrementally update his code as the project
progresses.

Personally, I see a combination of 2 and 3 being the best way to move
forward but it never does any damage to reach out and see what you
guys think.

All the best

Lewis

-- 
Lewis

Re: Scheduling for Amazon DynamoDB Project

[Lewis John Mcgibbney <le...@gmail.com>]

Thanks Enis

On Mon, Jun 11, 2012 at 7:26 PM, Enis Söztutar <en...@gmail.com> wrote:
> LGTM
>
> On Sat, Jun 9, 2012 at 5:54 AM, Lewis John Mcgibbney <
> lewis.mcgibbney@gmail.com> wrote:
>
>> Hi,
>>
>> Having spoken to Renato we've come to a solution/workaround which
>> looks like the following
>>
>> Use SVN and Jira.
>> 1) Branch trunk
>> 2) Patches uploaded and checked/evaluated in Jira.
>> 3) Mentor apply patches to branch
>> 4) Merge with Trunk when deemed suitable
>>
>> I'll progress with this just now and we can always revert if someone
>> has an objection.
>>
>> Thanks
>>
>> Lewis
>>
>> On Thu, Jun 7, 2012 at 6:43 PM, Lewis John Mcgibbney
>> <le...@gmail.com> wrote:
>> > Hi Everyone,
>> >
>> > W.r.t the ongoing project, we (Renato and myself) have been discussing
>> > a couple of options for storage of the output code.
>> >
>> > 1) Branch trunk (GoraAmazon) and incrementally update this as the
>> > project progresses over the summer. Once the project is finished merge
>> > the branch with trunk and keep going with Trunk. This would require
>> > Renato to have access to commit rights and the community would need to
>> > agree to this.
>> > 2) Upload all patches to the Jira issue. I (and anyone interested) can
>> > then review patches locally and commit them to trunk once the code is
>> > deemed suitable.
>> > 3) Renato can fork our Gora Github mirror, sync his own mirror to the
>> > Github one, then incrementally update his code as the project
>> > progresses.
>> >
>> > Personally, I see a combination of 2 and 3 being the best way to move
>> > forward but it never does any damage to reach out and see what you
>> > guys think.
>> >
>> > All the best
>> >
>> > Lewis
>> >
>> > --
>> > Lewis
>>
>>
>>
>> --
>> Lewis
>>



-- 
Lewis

Re: Scheduling for Amazon DynamoDB Project

[Enis Söztutar <en...@gmail.com>]

LGTM

On Sat, Jun 9, 2012 at 5:54 AM, Lewis John Mcgibbney <
lewis.mcgibbney@gmail.com> wrote:

> Hi,
>
> Having spoken to Renato we've come to a solution/workaround which
> looks like the following
>
> Use SVN and Jira.
> 1) Branch trunk
> 2) Patches uploaded and checked/evaluated in Jira.
> 3) Mentor apply patches to branch
> 4) Merge with Trunk when deemed suitable
>
> I'll progress with this just now and we can always revert if someone
> has an objection.
>
> Thanks
>
> Lewis
>
> On Thu, Jun 7, 2012 at 6:43 PM, Lewis John Mcgibbney
> <le...@gmail.com> wrote:
> > Hi Everyone,
> >
> > W.r.t the ongoing project, we (Renato and myself) have been discussing
> > a couple of options for storage of the output code.
> >
> > 1) Branch trunk (GoraAmazon) and incrementally update this as the
> > project progresses over the summer. Once the project is finished merge
> > the branch with trunk and keep going with Trunk. This would require
> > Renato to have access to commit rights and the community would need to
> > agree to this.
> > 2) Upload all patches to the Jira issue. I (and anyone interested) can
> > then review patches locally and commit them to trunk once the code is
> > deemed suitable.
> > 3) Renato can fork our Gora Github mirror, sync his own mirror to the
> > Github one, then incrementally update his code as the project
> > progresses.
> >
> > Personally, I see a combination of 2 and 3 being the best way to move
> > forward but it never does any damage to reach out and see what you
> > guys think.
> >
> > All the best
> >
> > Lewis
> >
> > --
> > Lewis
>
>
>
> --
> Lewis
>

Re: Scheduling for Amazon DynamoDB Project

[Lewis John Mcgibbney <le...@gmail.com>]

Hi,

Having spoken to Renato we've come to a solution/workaround which
looks like the following

Use SVN and Jira.
1) Branch trunk
2) Patches uploaded and checked/evaluated in Jira.
3) Mentor apply patches to branch
4) Merge with Trunk when deemed suitable

I'll progress with this just now and we can always revert if someone
has an objection.

Thanks

Lewis

On Thu, Jun 7, 2012 at 6:43 PM, Lewis John Mcgibbney
<le...@gmail.com> wrote:
> Hi Everyone,
>
> W.r.t the ongoing project, we (Renato and myself) have been discussing
> a couple of options for storage of the output code.
>
> 1) Branch trunk (GoraAmazon) and incrementally update this as the
> project progresses over the summer. Once the project is finished merge
> the branch with trunk and keep going with Trunk. This would require
> Renato to have access to commit rights and the community would need to
> agree to this.
> 2) Upload all patches to the Jira issue. I (and anyone interested) can
> then review patches locally and commit them to trunk once the code is
> deemed suitable.
> 3) Renato can fork our Gora Github mirror, sync his own mirror to the
> Github one, then incrementally update his code as the project
> progresses.
>
> Personally, I see a combination of 2 and 3 being the best way to move
> forward but it never does any damage to reach out and see what you
> guys think.
>
> All the best
>
> Lewis
>
> --
> Lewis



-- 
Lewis