Mailing-List: contact bigtop-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bigtop-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of shaposhnik@gmail.com
 designates 209.85.214.47 as permitted sender)
MIME-Version: 1.0
Sender: shaposhnik@gmail.com
In-Reply-To: <4ECC323B.6010809@apache.org>
References: 
 <CA+ULb+sMBCFHBmDdw9KE=uxDb2dew6xEi6_ufLXzxJHnvozpcA@mail.gmail.com>
	<4ECC323B.6010809@apache.org>
Date: Tue, 22 Nov 2011 15:49:59 -0800
Message-ID: 
 <CA+ULb+uRWp9oQf3v=Zo-281=o47WS_V7rkGO47p48sp=uwcgNA@mail.gmail.com>
Subject: Re: BIgtop 0.3.0 (was: [VOTE] Bigtop 0.3.0: target release date,
 supported platforms, bill of materials)
From: Roman Shaposhnik <rvs@apache.org>
To: bigtop-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 3:37 PM, Bruno Mah=E9 <bmahe@apache.org> wrote:
>>> 1/ Latest openSUSE and Fedora are respectively 12.1 and 16
>> You're absolutely correct. I specifically didn't say "latest" versions,
>> but stuck with the current ones. Is there any reason you feel
>> so strongly about bumping the versions of these OSes?
>
> I do all my work on latest Fedora/Mageia. So I will not test Fedora 15
> at all. So you get support for Fedora 16 for free.

Good point. As long as you're willing to support the neccessary
infrastructure on bigtop Jenkins -- I have no objections to bumping
Fedora version.

> Hence my suggestion to have a stable branch for releases based on the
> 0.20.20X generation and having trunk based on the next gen Hadoop.

We had this discussion a couple of month ago and you, yourself, made
a point that trunk should be reserved to changes which are stable.
E.g. putting versions of unreleased Apache projects in trunk is a no-no.

Any reason you're reversing your position now?

> The stable branch being there for people wishing to use a stable
> distribution and the coming releases of Bigtop to be used as a solid
> base for helping projects improving their compatibility with Hadoop
> 0.23.

Sure and last time we discussed it, we had a consensus that it is called
trunk.

>This will also have the added benefit on helping putting Hadoop
> 0.23 in more people's hands and improve Bigtop's Hadoop 23 support.

I don't follow. There's absolutely no difference checking out trunk
or checking out a branch and building the stack.  And it is THE only
wait to get Bigtop built for .23. Or you can pull packages from our
Jenkins job -- either way, I don't see how you can make it *easier*
to get .23. Care to elaborate?

> I wouldn't mind at all having a release of Bigtop with just Hadoop 0.23
> + HBase + other compatible projects, and reactivating these projects one
> by one as they get compatible with Hadoop 0.23.

I would strongly -1 that decision. And I'm most certainly would not my name
to be associated with such a release. Dropping components willy-nilly
is the biggest threat to Bigtop's credibility as an Apache Bigtdata
distribution.

> So we don't have to wait mid 2012 to have a release of Bigtop based on
> Hadoop 0.23.

>From my stand point -- we absolutely *have* to. Otherwise it will not be
Bigtop we're talking about.

> I am rather in favour of "release early and often" and therefore the
> later option :)

Now I'm totally confused -- with that motto, why do you NOT want to
release 0.3.0?

Thanks,
Roman.