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 > >>>> > >>>> > >>> > >>> > >
