[
https://issues.apache.org/jira/browse/YETUS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200445#comment-16200445
]
Allen Wittenauer commented on YETUS-556:
----------------------------------------
Let me put my question with a bit more context:
Should
{code}
asflicense.sh: echo "There appear to be ${numpatch} ASF License warnings after
applying the patch."
author.sh: echo "Skipping @author checks as ${appname} has been patched."
perlcritic.sh: echo "Running perlcritic against identified perl
scripts/modules."
test4tests.sh: echo "Patch does not appear to need new or modified tests."
{code}
also be yetus_info?
bq. I guess there's an implicit "this is normal" to just echoing to stderr
provided we don't signal an error?
I'd go as far as say the current "contract" is that precommit only writes to
stderr for actual errors and debug statements. (I'd go as far as to describe it
as "the UNIX way" as opposed to "the Java/log4j way".) So I guess the real
questions are:
Should we be avoiding raw echo statements? If so, what does that API look
like? When are raw echo statements appropriate (e.g., big_console?)?
On one hand, using something like yetus_info does open the door to do some
interesting things with function redefinition, better defines what we expect to
go where, etc, .... . But on the flip side... uh, isn't this overkill for a
clearly informational message that really shouldn't be redirected away when
separating stderr from stdout?
> add INFO level log message for precommit plugins
> ------------------------------------------------
>
> Key: YETUS-556
> URL: https://issues.apache.org/jira/browse/YETUS-556
> Project: Yetus
> Issue Type: Improvement
> Components: Test Patch
> Affects Versions: 0.6.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Priority: Critical
> Fix For: 0.6.0
>
> Attachments: YETUS-556.0.patch
>
>
> Realized while working on a personality change on HBase earlier this week
> that Yetus doesn't already ship a "yetus_info" function to go along with
> "yetus_debug" and "yetus_error".
> Complicating matters, YETUS-543 already references said function on some
> code paths. :(
> we should either add a method for info messages (my preference) or switch the
> use in hadoop's personality to yetus_error
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
