-x removes ignored stuff, which is the relevant problem here. If we add more targeted entries to .gitignore in each branch, then -df is sufficient.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jun 17, 2014 at 3:43 PM, Billie Rinaldi <[email protected]> wrote: > Also, is there a reason clean -xdf is recommended instead of -df? I think > the latter is sufficient to get rid of the offending target directories. > > > On Tue, Jun 17, 2014 at 12:37 PM, Sean Busbey <[email protected]> wrote: > > > I don't know that this will help much. > > > > We already have a *lot* for new contributors to keep track of. If they > miss > > the step of running maven clean, they end up exactly where we are now. > > > > The output from the Rat plugin doesn't make it easy to figure out how > they > > got into that state, nor how to back out of it. They're likely at a point > > where they can't easily go back to the branch that could do the clean, so > > they're back to "add your files and use git clean." Which we already know > > isn't going great for people. > > > > > > On Tue, Jun 17, 2014 at 3:31 PM, Billie Rinaldi < > [email protected]> > > wrote: > > > > > How about recommending a mvn clean before checking out a new branch? > > > > > > > > > On Tue, Jun 17, 2014 at 12:19 PM, Sean Busbey <[email protected]> > > wrote: > > > > > > > My concern with a default-on profile is the same one I have with > > > > Christopher's suggestion that we recommend -Drat.ignoreErrors=true. > > > > > > > > It's going to make the "easy" path one where things aren't checked. > > > That's > > > > going to necessitate we check things periodically and during release. > > > > > > > > We can just as easily do those checks by activating the profile, e.g. > > in > > > a > > > > jenkins build and in the release script. > > > > > > > > > > > > On Tue, Jun 17, 2014 at 3:09 PM, Billie Rinaldi < > > > [email protected]> > > > > 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 <[email protected] > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sean > > > > > > > > > > > > > > > -- > > Sean > > >
