I agree that instructing users to use this option to modify the build isn't acceptable and I wouldn't recommend this as a response to users... I was only stating this as a fact, to point out that a special profile on by default with an option to disable isn't needed, since that's the current behavior.
I'm more interested in the targeted .gitignore with the recommended "git clean -df" option without -x. This helps contributors understand build tools, makes them aware of the differences between branches, and doesn't hide problems introduced by switching branches in an obscure error, all without blowing away their IDE build files. (though switching branches often warrants blowing these IDE files away anyway, since different modules in different branches will be problematic for most IDEs). -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jun 17, 2014 at 4:47 PM, Alex Moundalexis <al...@clouderagovt.com> wrote: > This kind of response is hardly conducive to prospective contributors. > > We should consider ourselves lucky whenever a contributor provides a patch, > let alone runs a build. Expecting a new contributor be fully aware of the > Apache licensing details isn't realistic, much less being aware of the > arguments concerning Rat; if the ignoreErrors argument is TheWay, it ought > to be mentioned prominently in the source documentation [1], but I don't > think that's correct either... > > I don't want to encourage contributors to skip the build. I want > contributors to be aware of the licensing requirements, but not at the > expense of providing otherwise-viable patches. I'd recommend relaxing the > Rat checks for contributors, and making it a required part of the profile > for automated Jenkins builds and during the release process. > > The onus should be on the committers to ensure that all of the licensing is > in place before the release, but preferably long before that point by > guiding the contributor to make the necessary license additions before the > commit. > > I've been told to correct whitespace at the end of a line before and to > re-submit a patch, seems trivial to address missing licensing files in the > same way. > > [1] https://accumulo.apache.org/source.html > > On Tue, Jun 17, 2014 at 3:15 PM, Christopher <ctubb...@apache.org> wrote: > > > There's already a way to skip it for those who don't understand why its > > failing and are incapable/unwilling to troubleshoot: > > -Drat.ignoreErrors=true > > > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Tue, Jun 17, 2014 at 3:09 PM, Billie Rinaldi < > billie.rina...@gmail.com> > > wrote: > > > > > I'm not thrilled about turning it off by default. How about putting it > > in > > > a profile that would be enabled by default, but could be disabled with > a > > > flag for those who don't understand why it's failing? > > > > > > > > > On Tue, Jun 17, 2014 at 11:44 AM, Sean Busbey <bus...@cloudera.com> > > wrote: > > > > > > > I've had a few different new-to-Accumulo contributors recently run > into > > > the > > > > issue of Rat failing the build after changing branches. > > > > > > > > I know we already have a warning about this[1], but AFAICT it's over > > the > > > > threshold for consumable information. > > > > > > > > Even after pointing people to the warning, the existing workaround > > > tripped > > > > up atleast one of them. Despite the warning about using "git clean," > > the > > > > destruction of their local IDE changes were surprising. > > > > > > > > For contributions to Accumulo that aren't coming from committers, the > > Rat > > > > plugin seems much more likely to give a false positive than to catch > an > > > > error. Additionally, whatever committer is reviewing the contribution > > > > should be checking for license compliance anyways. > > > > > > > > In the interests of reducing the surprise for new contributors, I'd > > like > > > to > > > > move our use of Rat to a profile that is only default enabled during > a > > > > release run. > > > > > > > > The profile would still let those who want rat to run on every build > to > > > > enable it and we could update the guide for handling new > contributions > > to > > > > say committers should enable the rat profile to help guard against > > > errors. > > > > > > > > Any objections? > > > > > > > > [1]: http://accumulo.apache.org/source.html#running-a-build > > > > > > > > -- > > > > Sean > > > > > > > > > >
