Re: New strategy for Netty (ZOOKEEPER-823) was: What's the QA strategy of ZooKeeper?

[Mahadev Konar]

This sounds great.
Thanks
mahadev


On 10/16/10 1:56 AM, "Thomas Koch"  wrote:

> Benjamin Reed:
>>   actually, the other way of doing the netty patch (since i'm scared of
>> merges) would be to do a refactor cleanup patch with an eye toward
>> netty, and then another patch to actually add netty. [...]
> Hi Benjamin,
> 
> I've had exactly the same thought last evening. Instead of trying to find the
> bug(s) in the current patch, I'd like to start it over again and do small
> incremental changes from the current trunk towards the current ZOOKEEPER-823
> patch.
> Maybe I could do this in ZOOKEEPER-823 patch, this would mean to revert the
> already applied ZOOKEEPER-823 patch.
> Then I want to test each incremental step at least 5 times to find the step(s)
> that breaks ZK.
> This approach should take me another two weeks, I believe, mostly because each
> Test run takes ~15-25 minutes.
> 
> Cheers,
> 
> Thomas Koch, http://www.koch.ro
> 

Re: New strategy for Netty (ZOOKEEPER-823) was: What's the QA strategy of ZooKeeper?

[Patrick Hunt]

On Sat, Oct 16, 2010 at 1:56 AM, Thomas Koch  wrote:

> Benjamin Reed:
> >   actually, the other way of doing the netty patch (since i'm scared of
> > merges) would be to do a refactor cleanup patch with an eye toward
> > netty, and then another patch to actually add netty. [...]
>

Ben you really need to give git a try and stop fearing the branch/merge. ;-)

Seriously though, having a branch is not a big deal. In the end you an
create one or more patches if you like and apply them, but this is
essentially just a merge.

My main concern personally is that a branch not go on for too long or get
too big, ie incorporate too many changes, not focused. I believe that's not
the case here though. Thomas would focus on 1) refactoring the client code
to enable netty integration, 2) integrate netty changes. He'd also be adding
3) significant tests (potentially refactoring some code to better allow
"design for test") to ensure that the code changes (incl refactoring) don't
break anything.

For the record I'll add that this is pretty much what I did when creating
this patch in the first place. Because it was not done on a svn branch, and
it's just a big "patch ball" you can't see that. Also my goals were a bit
different from Thomas's (which I'm fine with in principal).


> I've had exactly the same thought last evening. Instead of trying to find
> the
> bug(s) in the current patch, I'd like to start it over again and do small
> incremental changes from the current trunk towards the current
> ZOOKEEPER-823
> patch.
> Maybe I could do this in ZOOKEEPER-823 patch, this would mean to revert the
> already applied ZOOKEEPER-823 patch.
>

Thomas, did you mean to say "do this in ZOOKEEPER-823 *branch*"?


> Then I want to test each incremental step at least 5 times to find the
> step(s)
> that breaks ZK.
> This approach should take me another two weeks, I believe, mostly because
> each
> Test run takes ~15-25 minutes.
>

This sounds like a reasonable plan to me if you want to try your hand at it.
I also appreciate you stepping up on this effort.

Unfortunately only committers can commit to apache SVN. Which means that one
of us (ben/f/m/h/myself) will have to apply your change to the branch.
You'll have to bug one of us when you're ready to apply a new patch to the
branch. If you can create a new patch (rather than changing the original)
that would be a good idea (easier for us to apply). Shouldn't be much of an
issue I assume if you're using git personally. Notice that I've already
setup a hudson job that pulls from the branch.
https://hudson.apache.org/hudson/view/ZooKeeper/job/ZooKeeper_branch_823/

Regards,

Patrick

New strategy for Netty (ZOOKEEPER-823) was: What's the QA strategy of ZooKeeper?

[Thomas Koch]

Benjamin Reed:
>   actually, the other way of doing the netty patch (since i'm scared of
> merges) would be to do a refactor cleanup patch with an eye toward
> netty, and then another patch to actually add netty. [...]
Hi Benjamin,

I've had exactly the same thought last evening. Instead of trying to find the 
bug(s) in the current patch, I'd like to start it over again and do small 
incremental changes from the current trunk towards the current ZOOKEEPER-823 
patch.
Maybe I could do this in ZOOKEEPER-823 patch, this would mean to revert the 
already applied ZOOKEEPER-823 patch.
Then I want to test each incremental step at least 5 times to find the step(s) 
that breaks ZK.
This approach should take me another two weeks, I believe, mostly because each 
Test run takes ~15-25 minutes.

Cheers,

Thomas Koch, http://www.koch.ro