You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2012/02/11 06:56:36 UTC

Code review release 2.2.1 - dedicated to Fred Oliver

Lets dedicate this release to Fred Oliver, please dive in and review recent code changes and ask questions, make sure the javadoc makes sense.  Let's make it the best release we can.

I plan to release on April 9, exactly one year after Fred's passing, giving us less than 2 months to prepare the release.

Peter.

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Tom Hobbs <tv...@googlemail.com>.
I'm hoping to tidy up my Scala and easystart work and get that into
the release as well.  All that code is outside the src directory.
It's in a src-extra directory and has an Ant task to build it
separately, so it doesn't require quite the same level of scrutiny as
your changes.  I don't know if I'm going to have time to sort it our
before the release.

Having said that, I understand the emotive reason to go for the 9th,
so if my stuff doesn't make it in, it's no big deal.

(80 hour weeks are bad for you Peter, chill out fella.)

Tom


On Sun, Feb 12, 2012 at 1:53 PM, Peter <ji...@zeus.net.au> wrote:
> I'm going to be a little busy, worked over 80 hours last week, doesn't look much better this week, should have a brief interlude next week.  Will attempt a merge again then.  Hopefully it'll go a little better next time.
>
> Cheers,
>
> Peter.
>
> ----- Original message -----
>> Simon IJskes - QCG wrote:
>> > On 11-02-12 12:08, Peter wrote:
>> > >
>> > > ----- Original message -----
>> > > > On 11-02-12 06:56, Peter wrote:
>> > > > > Lets dedicate this release to Fred Oliver, please dive in and
>> > > > > review recent
>> > > > > code changes and ask questions, make sure the javadoc makes sense.
>> > > > > Let's make
>> > > > > it the best release we can.
>> > > > >
>> > > > > I plan to release on April 9, exactly one year after Fred's
>> > > > > passing, giving us
>> > > > > less than 2 months to prepare the release.
>> > > > >
>> > > > > Peter.
>> > > >
>> > > > Your merge did not go ok, you reverted changes, and merged files that
>> > > > did not change, thereby (potentially) changing the historic path of
>> > > > that
>> > > > file. Are you going to repair this before release.
>> > >
>> > > I'm glad you were watching Sim, I wasn't even aware it went awry.
>> > >
>> > > Sounds like I need to back out the changes&  try again.
>> >
>> > There are a few methods of backing out, i would prefer branching the
>> > last correct revision number in trunk, moving the trunk, and moving
>> > this branch in place of the trunk. I can do this if you want.
>>
>> Thanks Mate, I'd appreciate that.
>> >
>> > > Got any advice?
>> >
>> > The next time you merge, and the branch you merge from is old compared
>> > to the trunk, you could make patch file, or diff and manually accept
>> > line changes in Netbeans for instance by using the visual diff, under
>> > the menu option 'Diff to'.
>> >
>> > There are different approaches to checking in, but i have no problem
>> > with a partial commit, followed by many other partial commits, that
>> > allow you to check each step. Those partial commits do not have to
>> > compile in my view, as long as the result of these multiple commits is
>> > a stable build in the end. (others have a more 'only commit compilable
>> > steps' approach, unworkable in my view).
>> >
>>
>> Thanks, I agree, that sounds like the best approach when dealing with a
>> lot of changes.  I can commit package by package, and inspect as I go.
>>
>> Regards,
>>
>> Peter.
>>
>

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Peter <ji...@zeus.net.au>.
I'm going to be a little busy, worked over 80 hours last week, doesn't look much better this week, should have a brief interlude next week.  Will attempt a merge again then.  Hopefully it'll go a little better next time.

Cheers,

Peter.

----- Original message -----
> Simon IJskes - QCG wrote:
> > On 11-02-12 12:08, Peter wrote:
> > >
> > > ----- Original message -----
> > > > On 11-02-12 06:56, Peter wrote:
> > > > > Lets dedicate this release to Fred Oliver, please dive in and
> > > > > review recent
> > > > > code changes and ask questions, make sure the javadoc makes sense. 
> > > > > Let's make
> > > > > it the best release we can.
> > > > >
> > > > > I plan to release on April 9, exactly one year after Fred's
> > > > > passing, giving us
> > > > > less than 2 months to prepare the release.
> > > > >
> > > > > Peter.
> > > >
> > > > Your merge did not go ok, you reverted changes, and merged files that
> > > > did not change, thereby (potentially) changing the historic path of
> > > > that
> > > > file. Are you going to repair this before release.
> > >
> > > I'm glad you were watching Sim, I wasn't even aware it went awry.
> > >
> > > Sounds like I need to back out the changes&  try again.
> >
> > There are a few methods of backing out, i would prefer branching the
> > last correct revision number in trunk, moving the trunk, and moving
> > this branch in place of the trunk. I can do this if you want.
>
> Thanks Mate, I'd appreciate that.
> >
> > > Got any advice?
> >
> > The next time you merge, and the branch you merge from is old compared
> > to the trunk, you could make patch file, or diff and manually accept
> > line changes in Netbeans for instance by using the visual diff, under
> > the menu option 'Diff to'.
> >
> > There are different approaches to checking in, but i have no problem
> > with a partial commit, followed by many other partial commits, that
> > allow you to check each step. Those partial commits do not have to
> > compile in my view, as long as the result of these multiple commits is
> > a stable build in the end. (others have a more 'only commit compilable
> > steps' approach, unworkable in my view).
> >
>
> Thanks, I agree, that sounds like the best approach when dealing with a
> lot of changes.  I can commit package by package, and inspect as I go.
>
> Regards,
>
> Peter.
>


Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 11-02-12 12:08, Peter wrote:
>>
>> ----- Original message -----
>>> On 11-02-12 06:56, Peter wrote:
>>>> Lets dedicate this release to Fred Oliver, please dive in and 
>>>> review recent
>>>> code changes and ask questions, make sure the javadoc makes sense.  
>>>> Let's make
>>>> it the best release we can.
>>>>
>>>> I plan to release on April 9, exactly one year after Fred's 
>>>> passing, giving us
>>>> less than 2 months to prepare the release.
>>>>
>>>> Peter.
>>>
>>> Your merge did not go ok, you reverted changes, and merged files that
>>> did not change, thereby (potentially) changing the historic path of 
>>> that
>>> file. Are you going to repair this before release.
>>
>> I'm glad you were watching Sim, I wasn't even aware it went awry.
>>
>> Sounds like I need to back out the changes&  try again.
>
> There are a few methods of backing out, i would prefer branching the 
> last correct revision number in trunk, moving the trunk, and moving 
> this branch in place of the trunk. I can do this if you want.

Thanks Mate, I'd appreciate that.
>
>> Got any advice?
>
> The next time you merge, and the branch you merge from is old compared 
> to the trunk, you could make patch file, or diff and manually accept 
> line changes in Netbeans for instance by using the visual diff, under 
> the menu option 'Diff to'.
>
> There are different approaches to checking in, but i have no problem 
> with a partial commit, followed by many other partial commits, that 
> allow you to check each step. Those partial commits do not have to 
> compile in my view, as long as the result of these multiple commits is 
> a stable build in the end. (others have a more 'only commit compilable 
> steps' approach, unworkable in my view).
>

Thanks, I agree, that sounds like the best approach when dealing with a 
lot of changes.  I can commit package by package, and inspect as I go.

Regards,

Peter.


Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-02-12 12:08, Peter wrote:
>
> ----- Original message -----
>> On 11-02-12 06:56, Peter wrote:
>>> Lets dedicate this release to Fred Oliver, please dive in and review recent
>>> code changes and ask questions, make sure the javadoc makes sense.  Let's make
>>> it the best release we can.
>>>
>>> I plan to release on April 9, exactly one year after Fred's passing, giving us
>>> less than 2 months to prepare the release.
>>>
>>> Peter.
>>
>> Your merge did not go ok, you reverted changes, and merged files that
>> did not change, thereby (potentially) changing the historic path of that
>> file. Are you going to repair this before release.
>
> I'm glad you were watching Sim, I wasn't even aware it went awry.
>
> Sounds like I need to back out the changes&  try again.

There are a few methods of backing out, i would prefer branching the 
last correct revision number in trunk, moving the trunk, and moving this 
branch in place of the trunk. I can do this if you want.

> Got any advice?

The next time you merge, and the branch you merge from is old compared 
to the trunk, you could make patch file, or diff and manually accept 
line changes in Netbeans for instance by using the visual diff, under 
the menu option 'Diff to'.

There are different approaches to checking in, but i have no problem 
with a partial commit, followed by many other partial commits, that 
allow you to check each step. Those partial commits do not have to 
compile in my view, as long as the result of these multiple commits is a 
stable build in the end. (others have a more 'only commit compilable 
steps' approach, unworkable in my view).

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Peter Firmstone <ji...@zeus.net.au>.
Simon IJskes - QCG wrote:
> On 11-02-12 12:08, Peter wrote:
>
>> I'm glad you were watching Sim, I wasn't even aware it went awry.
>
> Did you see the emails jenkins sent?
>
> Gr. Simon
>
Yeah, those were just new junit tests that were testing some 
functionality I hadn't yet implemented, I figured I could comment them 
out later.

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-02-12 12:08, Peter wrote:

> I'm glad you were watching Sim, I wasn't even aware it went awry.

Did you see the emails jenkins sent?

Gr. Simon

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Peter <ji...@zeus.net.au>.
----- Original message -----
> On 11-02-12 06:56, Peter wrote:
> > Lets dedicate this release to Fred Oliver, please dive in and review recent
> > code changes and ask questions, make sure the javadoc makes sense.  Let's make
> > it the best release we can.
> >
> > I plan to release on April 9, exactly one year after Fred's passing, giving us
> > less than 2 months to prepare the release.
> >
> > Peter.
>
> Your merge did not go ok, you reverted changes, and merged files that
> did not change, thereby (potentially) changing the historic path of that
> file. Are you going to repair this before release.

I'm glad you were watching Sim, I wasn't even aware it went awry.

Sounds like I need to back out the changes & try again.

Got any advice?

Peter.

Re: Code review release 2.2.1 - dedicated to Fred Oliver

Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 11-02-12 06:56, Peter wrote:
> Lets dedicate this release to Fred Oliver, please dive in and review recent code changes and ask questions, make sure the javadoc makes sense.  Let's make it the best release we can.
>
> I plan to release on April 9, exactly one year after Fred's passing, giving us less than 2 months to prepare the release.
>
> Peter.

Your merge did not go ok, you reverted changes, and merged files that 
did not change, thereby (potentially) changing the historic path of that 
file. Are you going to repair this before release?

Gr. Simon

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397