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 them based on
resources.

I will create a JIRA for this with some initial thoughts. However, the list
would have to come from folks who are currently familiar with parts of ZK
code.

Thanks.
-Vishal

On Fri, Oct 15, 2010 at 2:14 PM, Mahadev Konar <maha...@yahoo-inc.com>wrote:

> 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.
>
> Thanks
> mahadev
>
> 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-835that
> >> can
> >> individually be discussed, reviewed and tested.
> >>
> >> Have a nice weekend after Hadoop World!
> >>
> >> Thomas Koch, http://www.koch.ro
> >>
> >
>
>

Reply via email to