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 definitely work towards a plan. You should go ahead and
create a jira for the QA plan. We should all pitch in with what all should
be tested.


On 10/15/10 7:32 AM, "Vishal K" <vishalm...@gmail.com> wrote:

> 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 have ran into issues in ZK that I believe should have caught by
> some basic testing before the release. I will be honest in saying that,
> unfortunately, these bugs have resulted in questions being raised by several
> people in our organization about our choice of using ZooKeeper.
> Nevertheless, our product group really thinks that ZK is a cool technology,
> but we need to focus on making it robust before adding major new features to
> it.
> I would suggest to:
> 1. Look at current bugs and see why existing test did not uncover these bugs
> and improve those tests.
> 2. Look at places that need more tests and broadcast it to the community.
> Follow-up with test development.
> 3. Have a crisp release QA strategy for each release.
> 4. Improve API documentation as well as code documentation so that the API
> usage is clear and debugging is made easier.
> Comments?
> Thanks.
> -Vishal
> On Fri, Oct 15, 2010 at 9:44 AM, Thomas Koch <tho...@koch.ro> wrote:
>> 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 out
>>> for these things when patches get submitted or when new things go in.
>> 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 the
>> new
>> code from the FindBugs checks.
>>> i think this is inline with what pat was saying. just to expand a bit.
>>> in my opinion clean up refactorings have the following problems:
>>> 1) you risk breaking things in production for a potential future
>>> maintenance advantage.
>> If your code is already in such a bad shape, that every change includes
>> considerable risk to break something, then you already are in trouble. With
>> every new feature (or bugfix!) you also risk to break something.
>> If you don't have the attitude of permanent refactoring to improve the code
>> quality, you will inevitably lower the maintainability of your code with
>> every
>> new feature. New features will build on the dirty concepts already in the
>> code
>> and therfor make it more expensive to ever clean things up.
>>> 2) there is always subjectivity: quality code for one code quality
>>> zealot is often seen as a bad design by another code quality zealot.
>>> unless there is an objective reason to do it, don't.
>> I don't agree. IMHO, the area of subjectivism in code quality is actually
>> very
>> small compared to hard established standards of quality metrics and best
>> practices. I believe that my list given in the first mail of this thread
>> gives
>> examples of rather objective guidelines.
>>> 3) you may cleanup the wrong way. you may restructure to make the
>>> current code clean and then end up rewriting and refactoring again to
>>> change the logic.
>> Yes. Refactoring isn't easy, but necessary. Only over time you better
>> understand your domain and find better structures. Over time you introduce
>> features that let code grow so that it should better be split up in smaller
>> units that the human brain can still handle.
>>> i think we can mitigate 1) by only doing it when necessary. as a
>>> corollary we can mitigate 2) and 3) by only doing refactoring/cleanups
>>> when motivated by some new change: fix a bug, increased performance, new
>>> feature, etc.
>> I agree that refactoring should be carefully planned and done in small
>> steps.
>> Therefor I collected each refactoring item for the java client in a small
>> separate bug in https://issues.apache.org/jira/browse/ZOOKEEPER-835 that
>> can
>> individually be discussed, reviewed and tested.
>> Have a nice weekend after Hadoop World!
>> Thomas Koch, http://www.koch.ro

Reply via email to