One comment below.

mathi.naic...@oracle.com wrote:
> Summary: log: saflogger to return EXIT_FAILURE when SaLogWriteLogCallbackT 
> fails - v2 [#884]
> Review request for Trac Ticket(s): #884
> Peer Reviewer(s): Lennart
> Pull request to: <<LIST THE PERSON WITH PUSH ACCESS HERE>>
> Affected branch(es): opensaf-4.3.x, 4.4.x, default
> Development branch: <<IF ANY GIVE THE REPO URL>>
>
> --------------------------------
> Impacted area       Impact y/n
> --------------------------------
>  Docs                    n
>  Build system            n
>  RPM/packaging           n
>  Configuration files     n
>  Startup scripts         n
>  SAF services            y
>  OpenSAF services        n
>  Core libraries          n
>  Samples                 n
>  Tests                   n
>  Other                   n
>
>
> Comments (indicate scope for each "y" above):
> ---------------------------------------------
> Note: I'm not sure if BAD_OPERATION is the most suited error code in 
> the case of an mismatching invocation Id, but still iam unable to think 
> of anything else either!
>   
Since saflogger is a tool, it could also print a message to stderr.
At least that could assist a human user.

/AndersBj
> changeset 278424c712d38bca6859e9682d777e1d654daf26
> Author:       Mathivanan N.P.<mathi.naic...@oracle.com>
> Date: Tue, 06 May 2014 18:33:45 -0400
>
>       log: saflogger to return EXIT_FAILURE when SaLogWriteLogCallbackT 
> fails- v2
>       [#884] saflogger is not returning appropriate exit code to the shell 
> when
>       SaLogWriteLogCallbackT fails either because of an error reported in the
>       callback or because of an invalid invocationId. The patch exits with
>       EXIT_FAILURE in these scenarios.
>
> changeset e5d39c2d858982f15dbd855828a36b3b688f492e
> Author:       Mathivanan N.P.<mathi.naic...@oracle.com>
> Date: Tue, 06 May 2014 18:33:52 -0400
>
>       log: saflogtest to return EXIT_FAILURE when SaLogWriteLogCallbackT 
> fails- v1
>       [#884] saflogtest is not returning appropriate exit code to the shell 
> when
>       SaLogWriteLogCallbackT fails either because of an error reported in the
>       callback or because of an invalid invocationId. The patch exits with
>       EXIT_FAILURE in these scenarios.
>
>
> Complete diffstat:
> ------------------
>  osaf/tools/saflog/saflogger/saf_logger.c |  4 ++--
>  tests/logsv/saflogtest.c                 |  4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
>
> Testing Commands:
> -----------------
> Load LOG server such that it returns TRY_AGAIN for writes continously.
> Run saflogger to write to an application stream.
>
> For saflogtest, it is a conceptual patch because saflogtest will
> continously try for TRY_AGAINs.
>
> Testing, Expected Results:
> --------------------------
> Load LOG server such that it returns TRY_AGAIN for writes continously.
> After trying for ten seconds, when the saflogger exits with
> TRY_AGAIN error. The shell exit code should be 1 for failure cases.
>
>
> Conditions of Submission:
> -------------------------
> Ack from Lennart.
>
> 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.
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Opensaf-devel mailing list
> Opensaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensaf-devel
>   


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to