On Tue, 26 Feb 2019 at 12:53, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > sebb> We have no idea what you have tested > > I would never make an elaborate list of things I've done.
I did not ask for an exhaustive list, but some clue as to what you have run so others can repeat the tests on diferent hosts. > sebb> We don't know if you have covered all the requirements > > Everybody can see what I have published. I have not yet claimed that > Gradle build script is production ready. So what is ready for testing? Are you using the following Github repo & branch: https://github.com/vlsi/jmeter/tree/gradle > sebb>I do disagree with bundling it together with the development of the > sebb>Gradle scripts. > > Ok, however please note that your "disagreement" is not enough to veto > such a change. See below for further technical reasons. > On the other hand, splitting the work in two steps would make > development and review harder. Just the reverse. The more variables you change at once, the harder it is to debug failures. For example: If a test fails, is it because the build script is faulty? Or because a source file was changed? Or because files are in different places? Or because the Gradle test environment is different from the Ant test environment? Or because a dependency is missing or misplaced or the wrong version? If Gradle were introduced with the existing layout, this would eliminate a lot of variables. > It would break everybody's workflows twice. I agree that people would need to get used to two changes (Gradle instead of Ant, and new layout), but these are two separate changes. I don't think it matters much whether these are done together or separately. I do think it matters that changing both layout and build tool at the same time is going to make reviewing the commit mails harder, and debugging is likely to be harder. > So if you want to implement "Gradle with current layout" and then > "update layout" steps, you are welcome. I think you are going to find it harder to fix the test failures unless you proceed step by step. > Just wave a hand and do that. > > 2) Moving files around in SVN might be a pain. This is theoretical (as > I don't significant experience in advanced SVN renames/merges), SVN moves work fine; we moved from /jakarta/jmeter to /jmeter when we went TLP and that did not cause any major issues as I recall. And svnmucc is used to move files from dist/dev to dist/release when publishing a release. > Vladimir
