Given that no objections have come forward, I assume lazy consensus and will move forward with this.
Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) *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 Sat, Feb 22, 2020 at 9:50 AM Pierre Smits <pierresm...@apache.org> wrote: > Hi all, > > Currently we have Git (and GitHub) in full play for the master branch and > the 2 active release branches. The transition to this methodology of > distributed version control and collaboration has been adopted by our > fellow contributors without any major impediments and/or destructions. At > least none have been reported. It seems that everybody participating in > this project and submitting code changes has an experience with Git and/or > Github prior to the project’s move. > > In the past (during the svn era) the only option for fellow contributors > to deliver code improvements for bug fixes and other enhancements was to > deliver a file to a ticket in our Jira. > Nowadays, the contributor can -besides still using that upload option- use > the option to submit a Pull Request from his private clone or public fork > to one of our official repositories on Github. > In that past, and still to date, any code contribution uploaded to a Jira > ticket needed to be downloaded by a committer and applied by him to a test > branch (based on either the master or the active release branches) in order > to vet the code changes and test the code changes whether these would break > (or integrate with) the codebase. This vetting and testing was and is an > arduous and time consuming task, especially when the handed code changes > span multiple components, languages and/or files. The committer must vet > the changes with in his mind: > > - does it have unnecessary whitespacing > - does it comply with checkstyle > - is the code change to the point > - is the code compliant to our coding and other best practices > - does the code change pass system integration tests > - etc., etc. > > Vetting and testing these manually and on the development machine, takes > te committer away from enhancing our codebase himself. And when a vetted > and tested code change doesn’t pass muster, the testing committer needs to > update the ticket (but also when the change pases muster). > > Maybe, all of this is one of the reasons why contributors and/or committer > lose interest and the project doesn’t get done much? > > However, this should not be. With code enhancements coming in via patch > files in tickets and via Pull Request, we should adopt a method that will > help our committers (and fellow contributors too) by offering an automated > vetting and testing process that will deliver a report about the code and > its compliance to technical requirements. > > This automated vetting and testing process can be done on arrival of a > Pull Request in the project’s public repository on Github, as well on newly > added patch files to a ticket. And such a report would , after the process > has completed, be incorporated in the Pull Request or the ticket. This way > the submitter, the potential committer and anyone else participating in > this project and interested in the issue at hand and the solution would be > informed in a consistent way. With such an automated process, where a > contributor can rework the code of an initially submitted set of change(s) > and submit again, and the vetting and testing can be done over and over > without any burden on a committer.Currently such automated vetting and > testing can include: > > - ASF license checks > - checkstyle > - whitespace checks > - bug hangs (via findbugs or spotbugs) > - javadoc compliance > - java compilation testing > - script validation > - groovy compilation testing > - system integration tests > - etc. > > I have some questions for you: > > - What are your thoughts on this? > - Should we adopt this for our project? > - Before adopting this for our project, should we define a PoC and > execute it if acceptable? > > 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 >