Since this affects users APIs definitively more time is needed. We have not looked into this internally yet. /Hans
> -----Original Message----- > From: A V Mahesh [mailto:mahesh.va...@oracle.com] > Sent: den 19 december 2013 09:58 > To: Hans Feldt > Cc: opensaf-devel@lists.sourceforge.net; sirisha.a...@oracle.com; > mathi.naic...@oracle.com > Subject: Re: [PATCH 0 of 1] Review Request for cpsv: standardize arrival > callback API(s) with SAF syntax [#561] > > Hi, > I shall be pushing this patch next week. > I have already attached samples(for reference) to the ticket, will send > that separately for review after updating the samples. > > Thanks, > AVM. > > On 12/19/2013 2:07 PM, Hans Feldt wrote: > > I will not have time to review this until after new year. And I really > > would like to. > > Still missing a resend of the review with the comments we currently > > have and the sample programs included (under samples/ckpt I guess). > > /Hans > > > > On 12/19/2013 07:53 AM, mahesh.va...@oracle.com wrote: > >> Summary: cpsv: standardize arrival callback API(s) with SAF syntax > >> [#561] > >> Review request for Trac Ticket(s): #561 > >> Peer Reviewer(s): Hans/Mathi/Sirisha > >> Pull request to: <<LIST THE PERSON WITH PUSH ACCESS HERE>> > >> Affected branch(es): default > >> Development branch: default > >> > >> -------------------------------- > >> Impacted area Impact y/n > >> -------------------------------- > >> Docs n > >> Build system n > >> RPM/packaging n > >> Configuration files n > >> Startup scripts n > >> SAF services n > >> OpenSAF services y > >> Core libraries n > >> Samples n > >> Tests n > >> Other n > >> > >> > >> Comments (indicate scope for each "y" above): > >> --------------------------------------------- > >> > >> Republisheing the patch by addressed following review comment : > >> > >> 1) Doxygen comments in the saCkpt header file (for future doc > >> generation) > >> 2) Sample code using this feature, preferably two small > >> programs, one writing and one using callbacks > >> (uploaded to to #ticket 561) > >> 3) Those functions I asked about before should have TODO > >> comments or something similar > >> 4) If saCkptInitialize_2 is invoked with wrong version, version > >> parameter is not being filled up according to the standard initialize > >> API definitions. > >> 5) If TrackCallback is provided as NULL during initialization > >> and saCkptTrack() is invoked on the handle, SA_AIS_ERR_INIT would be > >> the closest > >> error value that needs to be returned. I have taken > >> SynchronizeAsync() API definition as the reference. > >> 6) If saCkptTrack() API is invoked on the handle for which > >> tracking has not been started or the tracking has been stopped, > >> SA_AIS_ERR_NOT_EXIST needs to be returned by saCkptTrack() > >> API. Please refer to saClmClusterTrackStop() API in the CLM > >> specification. > >> > >> changeset bbe09c2380cfca0f46f50352cf32592ea0845e44 > >> Author: A V Mahesh <mahesh.va...@oracle.com> > >> Date: Thu, 19 Dec 2013 12:16:35 +0530 > >> > >> cpsv: standardize arrival callback API(s) with SAF syntax [#561] > >> > >> > >> Added Files: > >> ------------ > >> osaf/libs/saf/include/saCkpt_B_02_03.h > >> > >> > >> Complete diffstat: > >> ------------------ > >> opensaf.spec.in | 1 + > >> osaf/libs/agents/saf/cpa/cpa_api.c | 547 > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++- > >> osaf/libs/agents/saf/cpa/cpa_proc.c | 6 +- > >> osaf/libs/common/cpsv/cpsv_edu.c | 22 ++++- > >> osaf/libs/common/cpsv/include/cpa_cb.h | 4 +- > >> osaf/libs/common/cpsv/include/cpa_def.h | 2 +- > >> osaf/libs/common/cpsv/include/cpa_proc.h | 2 +- > >> osaf/libs/common/cpsv/include/cpsv.h | 7 + > >> osaf/libs/common/cpsv/include/cpsv_evt.h | 8 +- > >> osaf/libs/saf/include/Makefile.am | 1 + > >> osaf/libs/saf/include/saCkpt_B_02_03.h | 152 > >> +++++++++++++++++++++++++++++ > >> osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 39 +++++++- > >> 12 files changed, 775 insertions(+), 16 deletions(-) > >> > >> > >> Testing Commands: > >> ----------------- > >> <<LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES>> > >> > >> > >> Testing, Expected Results: > >> -------------------------- > >> <<PASTE COMMAND OUTPUTS / TEST RESULTS>> > >> > >> > >> Conditions of Submission: > >> ------------------------- > >> <<HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC>> > >> > >> > >> Arch Built Started Linux distro > >> ------------------------------------------- > >> mips n n > >> mips64 n n > >> x86 n n > >> x86_64 y y > >> powerpc n n > >> powerpc64 n n > >> > >> > >> Reviewer Checklist: > >> ------------------- > >> [Submitters: make sure that your review doesn't trigger any checkmarks!] > >> > >> > >> Your checkin has not passed review because (see checked entries): > >> > >> ___ Your RR template is generally incomplete; it has too many blank > >> entries > >> that need proper data filled in. > >> > >> ___ You have failed to nominate the proper persons for review and push. > >> > >> ___ Your patches do not have proper short+long header > >> > >> ___ You have grammar/spelling in your header that is unacceptable. > >> > >> ___ You have exceeded a sensible line length in your > >> headers/comments/text. > >> > >> ___ You have failed to put in a proper Trac Ticket # into your commits. > >> > >> ___ You have incorrectly put/left internal data in your comments/files > >> (i.e. internal bug tracking tool IDs, product names etc) > >> > >> ___ You have not given any evidence of testing beyond basic build tests. > >> Demonstrate some level of runtime or other sanity testing. > >> > >> ___ You have ^M present in some of your files. These have to be removed. > >> > >> ___ You have needlessly changed whitespace or added whitespace crimes > >> like trailing spaces, or spaces before tabs. > >> > >> ___ You have mixed real technical changes with whitespace and other > >> cosmetic code cleanup changes. These have to be separate commits. > >> > >> ___ You need to refactor your submission into logical chunks; there is > >> too much content into a single commit. > >> > >> ___ You have extraneous garbage in your review (merge commits etc) > >> > >> ___ You have giant attachments which should never have been sent; > >> Instead you should place your content in a public tree to be > >> pulled. > >> > >> ___ You have too many commits attached to an e-mail; resend as threaded > >> commits, or place in a public tree for a pull. > >> > >> ___ You have resent this content multiple times without a clear > >> indication > >> of what has changed between each re-send. > >> > >> ___ You have failed to adequately and individually address all of the > >> comments and change requests that were proposed in the initial > >> review. > >> > >> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) > >> > >> ___ Your computer have a badly configured date and time; confusing the > >> the threaded patch review. > >> > >> ___ Your changes affect IPC mechanism, and you don't present any results > >> for in-service upgradability test. > >> > >> ___ Your changes affect user manual and documentation, your patch series > >> do not contain the patch that updates the Doxygen manual. > >> > >> > >> ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
