river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Code review release 2.2.1 - dedicated to Fred Oliver
Date Sun, 12 Feb 2012 18:07:04 GMT
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 <jini@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.
>>
>

Mime
View raw message