Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> Re: [VOTE] - Release 2.0.5-beta

Copy link to this message
Re: [VOTE] - Release 2.0.5-beta
On 15 May 2013 23:19, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:

> Guys,
> I guess what you're missing is that Bigtop isn't a testing framework for
> Hadoop. It is stack framework that verifies that components are dealing
> with
> each other nicely.

which to me means "Some form of integration test"
> Every single stack is different: Bigtop 0.5.0 differs from
> 0.6.0, and so on. Bigtop - as any other ASF project - has its releases that
> might or might not be aligned with particular version of Hadoop. Hence, an
> ethalon stack needs to be defined first and foremost.
> Before we even start talking about running it nightly (another question is
> on
> what hardware, let's not get there for now) let's understand who will can
> help
> with triage'ing test failures? Downstreams, Hadoop or Bigtop?

> Judging by a number of other emails there's a number of people on this list
> who care plenty about integration issues. Any volunteers to help with
> integration testing in the open?
As I said at the HUG, I want to get the non-swift-FS specific tests that do
things like run Pig jobs against any FS in, though I also need a home for
some very swift-specific partitioned file tests.

> Is this a previously solved problem?
> Yes. The problem is solved by separating actively developed (aka unstable)
> release from more mature and less volatile ones.
not in filesystems. If you look how long it took ext4 to be implemented and
then adopted, you can see that nobody put data they cared about on it until
they were happy that what you put on write() came back on a read() [and
stat() returned the amount of data, [seek(X);read()] returned the byte at
offset X and other little details that those of us writing tests for the
filesystem APIs care about]