Yeah, was thinking that after I clicked send.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Jun 17, 2014 at 6:07 PM, Josh Elser <[email protected]> wrote: > I think that depends on the type of thing being patched. A patch that > fixes a bug makes sense to go against a previously-released version. A > patch for some new feature does not. > > > On 6/17/14, 2:38 PM, Christopher wrote: > >> Personally, I think that contributors should be patching against the last >> released version, not master. Early on Josh argued that we should keep the >> master HEAD identical to the latest release, and develop in a development >> branch. I didn't fully understand his reasonings back then, but if we were >> making that decision now, I'd go for that. >> >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Tue, Jun 17, 2014 at 3:46 PM, Mike Drob <[email protected]> wrote: >> >> This problem is exasperated by our development model. We tell people to >>> clone our repo, which puts them on master by default. Then we tell them >>> to >>> work against the oldest branch that has the bug, which is almost always >>> going to be 1.6 and sometimes even 1.5. After switching branches, they'll >>> have the extra modules laying around, and unless they know to look for >>> them >>> are going to get bit by the RAT check. This is something that happens for >>> almost every single new contributor, and we saw it come up several times >>> during the hackathon. >>> >>> >>> On Tue, Jun 17, 2014 at 2: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 >>>> >>>> >>> >>
