Hi; I've identified a few sleep/wait related stuff, at the end it should cut the start/stop time in half. I am waiting a little to see if it can be generalized or not and I will publish them.
There are also possible improvements in the test themselves, small bug fixes stuff, but it should buy a few minutes as well. If I do things in a pure & clean way, that's gonna create a big big bunch of very very small JIRAs. Is that ok, or do you prefer medium sized ones? Then I will have a look at the profiler results. Who knows :-) The next task could be defining the strategy for the split. I tend to believe that we can categorize the tests between: - core unit tests: with a contract: should be run before submitting a patch, should not take too long, should not be flaky, should cover most of HBase - long running tests: long or flaky, not on the core of HBase, or testing specific cases (like timeout) However, a failure of a test should break the central build, whatever the category. I have not made my mind at all, just that this seems an easy way to make progress. Cheers, On Tue, Oct 18, 2011 at 2:49 PM, N Keywal <nkey...@gmail.com> wrote: > Yes, putting then in a different phase. Actually , it could be done by > renaming them, as surefire allows to launch a set of tests selected by a > pattern (not tested :-). > > Tests like replication could fall into this approach, as it takes a lot of > time, depends on the underlying cluster, and should not be impacted by most > of the changes in HBase. > > Nicolas > > > > On Tue, Oct 18, 2011 at 1:15 PM, Stack <st...@duboce.net> wrote: > >> On Mon, Oct 17, 2011 at 8:20 PM, N Keywal <nkey...@gmail.com> wrote: >> > I was also thinking about splitting the test 'as they are' between the >> long >> > running ones & and the others, without changing them. >> >> How you thinking of splitting them Nicolas? You mean put them into a >> separate phase or name them differently? >> >> Good stuff, >> St.Ack >> > >
