This sounds great.
Thanks
mahadev
On 10/16/10 1:56 AM, Thomas Koch tho...@koch.ro 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
On Sat, Oct 16, 2010 at 1:56 AM, Thomas Koch tho...@koch.ro 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
Hi Vishal, thanks for the list. As you can see when we do find issues we do
our best to address them and increase testing in that area. Unfortunately
our testing regime, while extensive is not exhaustive. You can see the
clover coverage reports here btw:
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
Hi Benjamin,
thank you for your response. Please find some comments inline.
Benjamin Reed:
code quality is important, and there are things we should keep in
mind, but in general i really don't like the idea of risking code
breakage because of a gratuitous code cleanup. we should be watching
Hi,
I would like to add my few cents here.
I would suggest to stay away from code cleanup unless it is absolutely
necessary.
I would also like to extend this discussion to understand the amount of
testing/QA to be performed before a release. How do we currently qualify a
release?
Recently, we
Well said Vishal.
I really like the points you put forth!!!
Agree on all the points, but again, all the point you mention require
commitment from folks like you. Its a pretty hard task to test all the
corner cases of ZooKeeper. I'd expect everyone to pitch in for testing a
release. We should
Recently, we have ran into issues in ZK that I believe should have caught
by some basic testing before the release
Vishal, can you be more specific, point out specific JIRAs that you entered
would be very valuable. Don't worry about hurting our feelings or anything,
without this type of feedback
i think we have a very different perspective on the quality issue:
I didn't want to say it that clear, but especially the new Netty code, both on
client and server side is IMHO an example of new code in very bad shape. The
client code patch even changes the FindBugs configuration to exclude
Hi Mahadev,
Yes this will require effort from the community. In a related note how many
of the contributors do you think are dedicated (either partially or fully to
ZK development/testing)? This will help to in understanding how much effort
will be required for tasks and how we can prioritize
Hi Patrick,
On Fri, Oct 15, 2010 at 2:22 PM, Patrick Hunt ph...@apache.org wrote:
Recently, we have ran into issues in ZK that I believe should have caught
by some basic testing before the release
Vishal, can you be more specific, point out specific JIRAs that you entered
would be very
I broadly agree with Ben - all meaningful code changes carry a risk of
destabilization (otherwise software development would be very easy) so we
should guard against improving cleanliness only for its own sake. At the
point where bad code gets in the way of fixing bugs or adding features, I
think
On Fri, Oct 15, 2010 at 12:11 PM, Henry Robinson he...@cloudera.com wrote:
The netty patch is a good test case for this approach. If we feel that
reworking the structure of the existing server cnxn code will make it
significantly easier to add a second implementation that adheres to the
same
On Fri, Oct 15, 2010 at 12:11 PM, Henry Robinson he...@cloudera.com wrote:
The netty patch is a good test case for this approach. If we feel that
reworking the structure of the existing server cnxn code will make it
significantly easier to add a second implementation that adheres to the
same
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. that would have
been nice because the first patch would allow us to more easily make
sure that NIO
code quality is important, and there are things we should keep in
mind, but in general i really don't like the idea of risking code
breakage because of a gratuitous code cleanup. we should be watching out
for these things when patches get submitted or when new things go in.
i think this is
Hi,
after filling 13 refactoring issues against the Java Client code[1], I started
to dig into the server site code to understand the last issues with the Netty
stuff.
I feel bad. It's this feeling of I don't wanna hurt you, but ZooKeeper
is quite an important piece of the Hadoop ecosystem
17 matches
Mail list logo
