Your copy&paste comments from yetus have a very bad signal/noise ratio [1].

Let's see for https://issues.apache.org/jira/browse/OFBIZ-10001:

===

+1 overall


 ____                              _
/ ___| _   _  ___ ___ ___  ___ ___| |
\___ \| | | |/ __/ __/ _ \/ __/ __| |
 ___) | |_| | (_| (_|  __/\__ \__ \_|
|____/ \__,_|\___\___\___||___/___(_)



| Vote |      Subsystem |Runtime    | Comment
============================================================================
|   0  |        reexec  |   0m 47s   | Docker mode activated.
+---------------------------------------------------------------------------
|      |                |            | Prechecks
+---------------------------------------------------------------------------
|  +1  |       dupname  |   0m  0s   | Nocase  conflicting files found.
|  +1  |       @author  |   0m  1s   | The patch does not contain any @author
|      |                |            | tags.
+---------------------------------------------------------------------------
|      |                |            | trunk Compile Tests
+---------------------------------------------------------------------------
+---------------------------------------------------------------------------
|      |                |            | Patch Compile Tests
+---------------------------------------------------------------------------
|  +1  |    whitespace  |   0m  0s   | The patch has no whitespace issues.
|  +1  |           xml  |   0m  3s   | The patch has no ill-formed XML file.
+---------------------------------------------------------------------------
|      |                |            | Other Tests
+---------------------------------------------------------------------------
|   0  |    asflicense  |   1m  2s   | ASF License check generated no output?
|      |                |  27m 43s   |




|| Subsystem || Report/Notes ||
============================================================================
| Docker | Client=18.09.2 Server=18.09.2 base: 
/Users/nl04748/dev/test/yetus/ofbiz/OFBIZ-10001/Dockerfile |
| JIRA Issue | OFBIZ-10001 |
| JIRA Patch URL | https://issues.apache.org/jira/secure/attachment/12911530/OFBIZ-10001_org.apache.ofbiz.product.category.CategoryContentServices_convert.patch |

===

22/44 lines of the output have no value at all while the other lines IMO have little value.

- What's the use of the information that there is no ill-formed xml when the patch does not contain any xml at all?

- What does it provide to the reader that the ASF license check does not generated output while the patch contains the ASF license header?

- it was also mentioned before that the current patch will be reworked so the information was outdated while generated


If you provide such information in this format for every patch attached in a Jira, it will become literally unreadable.

Can you explain where you see the value for the mentioned audience? I doubt that they even read it.

By the way, the same bad signal/noise ratio applies to your signature.

Michael


[1] https://en.wikipedia.org/wiki/Signal-to-noise_ratio



Am 19.02.20 um 16:35 schrieb Pierre Smits:
What you find cluttering, I regards as helpful to:

    - fellow contributors
    - our (potential) adopters
    - anyone else working on an OFBiz implementation


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<https://ofbiz.apache.org/>, since 2008

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Wed, Feb 19, 2020 at 3:54 PM Michael Brohl <[email protected]>
wrote:

No, I did not say or mean anything like that. Not sure where you get
that from.

Please read again, thanks,

Michael

Am 19.02.20 um 15:51 schrieb Pierre Smits:
Michael,

You mean like:

     - *stop* posting comments to tickets to help fellow contributors and
the
     adopters of our product looking to these contributions to help them
decide
     whether or not to invest in an adoption/implementation of (or
looking for
     guidance on issues they experience with their implementation of) the
     product?
     - *stop* posting to mail threads to provide insight and such,?
     - *stop* providing reactions to comments posted to pages in our wiki?
     - *stop* taking the initiative?

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor* (but unfortunately without privileges)* of* Apache
OFBiz <https://ofbiz.apache.org/>, since 2008

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Wed, Feb 19, 2020 at 3:05 PM Michael Brohl <[email protected]>
wrote:

+1 Gil

Pierre, can you please stop cluttering the issues with the copy/pasted
yetus artifacts from your local environment?

At least until we decided to use it and have a setup on the official
infrastructure.

Thanks,

Michael


Am 14.02.20 um 16:34 schrieb Gil Portenseigne:
Hello Pierre,

It is interesting but i guess that will be the next step.

Thanks

On Fri, Feb 14, 2020 at 09:04:49AM +0100, Pierre Smits wrote:
It seems many projects (including those Apache projects in the Hadoop
sphere) use the works of the Apache Yetus (see [1]) project to do
pre-commit checks (including IIUC checkstyle, in an automate way) on
patch
files attached to JIRA tickets and Pull Requests in Github against the
latest commit in the branch. This may be helpful to lessen the burden
on
the contributor. When configured correctly, the test results appear in
the
ticket. Apache HBASE is such a project using Yetus, See as an example
[2]
where test results are included through comments of 'Hadoop QA'.

Maybe we should consider this for our project?


[1] https://yetus.apache.org
[2]

https://issues.apache.org/jira/browse/HBASE-14498?jql=project%20%3D%20HBASE%20AND%20status%20%3D%20%22Patch%20Available%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
Best regards,

Pierre Smits
*Proud* *contributor* (but without privileges)* of* Apache OFBiz
<https://ofbiz.apache.org/>, since 2008

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
Apache Steve <https://steve.apache.org>, committer


On Thu, Feb 13, 2020 at 9:13 PM Gil Portenseigne <
[email protected]> wrote:

Hello Michael,

Adapting checkstyle configuration is less impacting to our codebase
but
make us stay different from the java standard.
That is the easier path, that will not affect code history.

But about getting nearer from the java standard is IMO a nice to
have,
to
make pure java developer feel better discovering OFBiz.
I'm kinda prefer the "opposite approach", but we need to discuss if
this
improvement is worth the history lost.

In the example you chose, i see no issue capitalizing module,
resource and other. Updating the rule offer the ability to write a
constant like : MoDuLe  :-).

Lots of errors are about line that are 120+ length, missing or
uneeded
space etc.

So that will lead to loads of unrisky modifications. With the usage
of
IDE with checkstyle plugin this can be done nicely.
I check that over the near thousand of java file concerned more than
80%
have less than 50 issue... So we can focus our effort onto the big
files
using a branch to test the idea and ease the issue.

And like Daniel said, it is a good subject for a community week
effort.
I'd really like to be able to efficiently use this feature, in one
way
or the other, so thank you for starting this discussion.

Regards,

Gil


On Thu, Feb 13, 2020 at 05:44:40PM +0100, Michael Brohl wrote:
Hi *,

checkstyle currently reports a huge amount of errors. We currently
have
an
error count setup in the configuration to prevent the build from
failing
because of the present errors.

Some thoughts/questions to the community:

* should we take an approach to fine-tune the  configuration so that
it
better fits the project style?

As an example, constants are currently not allowed to be named
"module",
"resource" etc. which is a common pattern in our code. Changing from
^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to
^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$
would allow the common naming.

The opposite approach would be to rename those to fit the default
settings.
* should we start an initiative to remove the valid errors like we
did
with
the FindBugs initiative some time ago?


Thanks for your feedback,

Michael Brohl

ecomify GmbH - www.ecomify.de




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to