Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig >> mail # dev >> pig 0.11 candidate 2 feedback: Several problems


Copy link to this message
-
Re: pig 0.11 candidate 2 feedback: Several problems
I agree -- this is a good release. The bugs Kai pointed out should be
fixed, but as they are not critical regressions, we can fix them in 0.11.1
(if someone wants to roll 0.11.1 the minute these fixes are committed, I
won't mind and will dutifully vote for the release).

I think the Hadoop 20.2 incompatibility is unfortunate but iirc this is
fixable by setting HADOOP_USER_CLASSPATH_FIRST=true (was that in 20.2?)

FWIW Twitter's running CDH3 and this release works in our environment.

At this point things that block a release are critical regressions in
performance or correctness.

D
On Wed, Feb 20, 2013 at 11:52 AM, Alan Gates <[EMAIL PROTECTED]> wrote:

> No.  Bugs like these are supposed to be found and fixed after we branch
> from trunk (which happened several months ago in the case of 0.11).  The
> point of RCs are to check that it's a good build, licenses are right, etc.
>  Any bugs found this late in the game have to be seen as failures of
> earlier testing.
>
> Alan.
>
> On Feb 20, 2013, at 11:33 AM, Russell Jurney wrote:
>
> > Isn't the point of an RC to find and fix bugs like these>
> >
> >
> > On Wed, Feb 20, 2013 at 11:31 AM, Bill Graham <[EMAIL PROTECTED]>
> wrote:
> >
> >> Regarding Pig 11 rc2, I propose we continue with the current vote as is
> >> (which closes today EOD). Patches for 0.20.2 issues can be rolled into a
> >> Pig 0.11.1 release whenever they're available and tested.
> >>
> >>
> >>
> >> On Wed, Feb 20, 2013 at 9:24 AM, Olga Natkovich <[EMAIL PROTECTED]
> >>> wrote:
> >>
> >>> I agree that supporting as much as we can is a good goal. The issue is
> >> who
> >>> is going to be testing against all these versions? We found the issues
> >>> under discussion because of a customer report, not because we
> >> consistently
> >>> test against all versions. Perhaps when we decide which versions to
> >> support
> >>> for next release we need also to agree who is going to be testing and
> >>> maintaining compatibility with a particular version.
> >>>
> >>> For instance since Hadoop 23 compatibility is important for us at Yahoo
> >> we
> >>> have been maintaining compatibility with this version for 0.9, 0.10 and
> >>> will do the same for 0.11 and going forward. I think we would need
> others
> >>> to step in and claim the versions of their interest.
> >>>
> >>> Olga
> >>>
> >>>
> >>> ________________________________
> >>> From: Kai Londenberg <[EMAIL PROTECTED]>
> >>> To: [EMAIL PROTECTED]
> >>> Sent: Wednesday, February 20, 2013 1:51 AM
> >>> Subject: Re: pig 0.11 candidate 2 feedback: Several problems
> >>>
> >>> Hi,
> >>>
> >>> I stronly agree with Jonathan here. If there are good reasons why you
> >>> can't support an older version of Hadoop any more, that's one thing.
> >>> But having to change 2 lines of code doesn't really qualify as such in
> >>> my point of view ;)
> >>>
> >>> At least for me, pig support for 0.20.2 is essential - without it, I
> >>> can't use it. If it doesn't support it, I'll have to branch pig and
> >>> hack it myself, or stop using it.
> >>>
> >>> I guess, there are a lot of people still running 0.20.2 Clusters. If
> >>> you really have lots of data stored on HDFS and a continuously busy
> >>> cluster, an upgrade is nothing you do "just because".
> >>>
> >>>
> >>> 2013/2/20 Jonathan Coveney <[EMAIL PROTECTED]>:
> >>>> I agree that we shouldn't have to support old versions forever. That
> >>> said,
> >>>> I also don't think we should be too blase about supporting older
> >> versions
> >>>> where it is not odious to do so. We have a lot of competition in the
> >>>> language space and the broader the versions we can support, the better
> >>>> (assuming it isn't too odious to do so). In this case, I don't think
> it
> >>>> should be too hard to change ObjectSerializer so that the
> commons-codec
> >>>> code used is compatible with both versions...we could just in-line
> some
> >>> of
> >>>> the Base64 code, and comment accordingly.
> >>>>
> >>>> That said, we also should be clear about what versions we support, but
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB