On 10/6/15, 12:04 AM, "Christofer Dutz" <[email protected]> wrote:
> >Yes it would be a separate repo ... as you could run the "testsuite" >against falcon without wanting to have the sdk or vice versa and this >would destroy the circle (at least one of them). No objection here. What do others think? I thought it was a common practice to put tests in the same repo as the code, but I guess we’d just put these integration tests in another repo? > >I would do this, but I would do it thoroughly ... meaning I would also >cleanup the build itself. Starting with streamlined goal names (currently >the target names are a mess ... I'd streamline them similar to the phases >of a maven build: clean, compile, test, integration-test, package, >install, deploy, ...). Again no objection here. But my overall question remains: why is this a release blocker? It sounds like extensive work. Why can’t it wait? How will it help the vast majority of folks who just want to use the latest code? Create a branch and get going but let’s also get this release out now. IMO, there’s lots of good new code that we should officially release to our community ASAP. > >And one thing will be that I will only be doing this on the ASF Jenkins, >as this is - in my belief - the only true place for the build to be. Im >fine with other Jenkins instances (I have a Teamcity running for my >stuff), but there has to be one on the ASF machines. Well, good luck with that. I don’t think there is a policy or other mandate that builds have to be on ASF machines but I understand that it helps with Maven deployment. I’ve wasted too much time on the ASF builds already and will maintain my own set of builds as long as I can. Anyway, thanks for volunteering to do this. I will try to answer questions as quickly as possible but some of my answers will be guesses as I didn’t set up most of these scripts. -Alex
