You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pig.apache.org by Mark Grover <gr...@gmail.com> on 2013/03/30 01:41:29 UTC

Apache Pig 0.11.1 release candidate

Hi all,
I am a contributor to Apache Bigtop <http://bigtop.apache.org> and have a
question for you.
Bigtop is a TLP responsible for performing packaging and interoperability
testing of various projects in the Hadoop ecosystem, including Apache Pig.

We are planning to include Pig 0.11 in our soon to be released Bigtop 0.6
distribution. However, while upgrading Pig from 0.10 to 0.11, I wasn't able
to compile Pig 0.11.1 on RPM based
systems<http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/313/label=centos6/console>.
There doesn't seem to be anything Bigtop specific here, I would expect this
issue to impact all Pig users. It seems like Pig's contrib sub-project uses
the system's default encoding for compiling code; however on RPM based
systems, the default encoding is not suitable and breaks the build. I
created PIG-3262 <https://issues.apache.org/jira/browse/PIG-3262> to track
this and Cheolsoo graciously committed this to Pig trunk. The essence of
Bigtop is exactly to find integration issues like this.

Now, I do realize that Bill and the community has done some excellent work
in putting together 0.11.1. Perhaps, I am a little too late to ask this
question but I thought I'd ask it anyway. Is there a possibility that the
Pig community can release a new release candidate for 0.11.1 with the fix
in PIG-3262?

The pros:
1. It would allow Pig users to compile Pig contrib on RPM machines
(RHEL/CentOS 5, 6, SLES 11, Fedora, etc.) which doesn't seem to be possible
as of now.
2. It would enable Apache Bigtop 0.6 to include a Pig version that builds
on all OS variants.

The cons:
1. There is a cost of cutting out another release candidate to the Pig
community. I completely understand and appreciate the cost involved;
however, I would anticipate the cost to be minimal since a) the
change<https://issues.apache.org/jira/secure/attachment/12575962/PIG-3262.2.patch>is
quite trivial; b) the change only affects the contrib functionality
and
not the "core" functionality, per se.

If we do decide to release another release candidate, I would be more than
happy to perform integration testing on it by means of Apache Bigtop.

I do realize the unfortunate timing of this email, it would have been ideal
if we were having this conversation a week ago while the vote was still
going on. I will try to change that in future so please do accept my
apologies in advance.

Regards,
Mark

Re: Apache Pig 0.11.1 release candidate

Posted by Mark Grover <gr...@gmail.com>.
Hi Bill and Dmitriy,
Thanks for responding. I appreciate the time you spent in looking into this.

I am fine with your suggestion of moving forward with 0.11.1 release. If
there is a 0.11.2, I would really appreciate if you could include the patch
on PIG-3262 in it.

Moving forward, let's work out how Apache Bigtop can work with Apache Pig
to find and help fix integration issues in time.

Also, FWIW, Bruno Mahé from Bigtop separately mentioned the following
workaround before the build:
export LC_ALL=en_US.UTF-8

I've posted the same on PIG-3262, in case anyone runs into the same issue.

Thanks, once again!

Mark


On Mon, Apr 1, 2013 at 9:07 AM, Dmitriy Ryaboy <dv...@gmail.com> wrote:

> Roman and Mark,
> Joining Bill here in thanking you for BigTop and all the integration work
> you guys do.
>
> Since this issue came up so late (after the vote), and, while it does
> affect people trying to build an rpm, does not affect people just using Pig
> jars, etc, I'd move to release 0.11.1 and consider the changes for 0.11.2.
> I suspect we'll have a .2 release -- 0.12 has a lot of new stuff, so people
> will likely stay on 11 for a while waiting for 12 to stabilize, and we'll
> see more bugfix patches.
>
> Using BigTop to validate an RC automatically would be great, let us know
> what we can do to make that happen.
>
> Best,
> -D
>
>
> On Sun, Mar 31, 2013 at 8:11 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> > Hi Bill!
> >
> > Thanks a million for chiming in!
> >
> > On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com>
> > wrote:
> > > Thanks for the work you're doing to support Pig in BigTop. Starting
> with
> > > Pig 0.12, our release process will be simplified to not include rpm/deb
> > > packages, thanks to BigTop.
> >
> > On a related note -- we're trying to work on a model where Bigtop
> > could be utilized as RC (and pre-RC) integration validation framework.
> > The gist of the idea is pretty simple -- we're planning to use the
> > last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
> > single component (lets say Pig) following the trunk/branch development.
> > Hopefully that way all the integration problems could be uncovered
> > earlier in the game.
> >
> > Drop us a note if you guys would be interested. This is, obviously,
> > a two way street -- Bigtop can provide the framework, but we
> > need your expertise in triaging problems as they arise.
> >
> > > I've built Pig on a multiple RHEL versions so this issue might not be
> as
> > > broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were
> > both
> > > built on rhel5 instances from ec2 (ami-2d8e4c44).
> >
> > Here's the map of affected Linux platforms:
> >
> >
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/
> >
> > Feel free to see the build logs. Also, if you, interested, I can give
> > you karma to poke around Bigtop's Jenkins.
> >
> > The AMIs are all stock AMIs produced either by the corresponding
> > Linux vendor (Fedora, OpenSUSE) or RightScale.
> >
> > As such, it seems that chance of unsuspecting users running into
> > this issue with the build are pretty high.
> >
> > > That said, if the Pig community feels strongly that we should cancel
> the
> > > release and re-issue a new one, I'm fine with shepherding that process.
> >
> > It would be extremely appreciated if you guys could go through the
> trouble
> > of spinning up a new RC. This is, of course, your decision but we'd be
> > willing
> > to help to the extent we can.
> >
> > As Mark mentioned -- the risk of the respin is pretty small -- the
> affected
> > changes are all build files and they are localized to contrib. Of course,
> > any RC is quite a bit of work.
> >
> > Thanks,
> > Roman.
> >
>

Re: Apache Pig 0.11.1 release candidate

Posted by Mark Grover <gr...@gmail.com>.
Hi Bill and Dmitriy,
Thanks for responding. I appreciate the time you spent in looking into this.

I am fine with your suggestion of moving forward with 0.11.1 release. If
there is a 0.11.2, I would really appreciate if you could include the patch
on PIG-3262 in it.

Moving forward, let's work out how Apache Bigtop can work with Apache Pig
to find and help fix integration issues in time.

Also, FWIW, Bruno Mahé from Bigtop separately mentioned the following
workaround before the build:
export LC_ALL=en_US.UTF-8

I've posted the same on PIG-3262, in case anyone runs into the same issue.

Thanks, once again!

Mark


On Mon, Apr 1, 2013 at 9:07 AM, Dmitriy Ryaboy <dv...@gmail.com> wrote:

> Roman and Mark,
> Joining Bill here in thanking you for BigTop and all the integration work
> you guys do.
>
> Since this issue came up so late (after the vote), and, while it does
> affect people trying to build an rpm, does not affect people just using Pig
> jars, etc, I'd move to release 0.11.1 and consider the changes for 0.11.2.
> I suspect we'll have a .2 release -- 0.12 has a lot of new stuff, so people
> will likely stay on 11 for a while waiting for 12 to stabilize, and we'll
> see more bugfix patches.
>
> Using BigTop to validate an RC automatically would be great, let us know
> what we can do to make that happen.
>
> Best,
> -D
>
>
> On Sun, Mar 31, 2013 at 8:11 PM, Roman Shaposhnik <rv...@apache.org> wrote:
>
> > Hi Bill!
> >
> > Thanks a million for chiming in!
> >
> > On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com>
> > wrote:
> > > Thanks for the work you're doing to support Pig in BigTop. Starting
> with
> > > Pig 0.12, our release process will be simplified to not include rpm/deb
> > > packages, thanks to BigTop.
> >
> > On a related note -- we're trying to work on a model where Bigtop
> > could be utilized as RC (and pre-RC) integration validation framework.
> > The gist of the idea is pretty simple -- we're planning to use the
> > last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
> > single component (lets say Pig) following the trunk/branch development.
> > Hopefully that way all the integration problems could be uncovered
> > earlier in the game.
> >
> > Drop us a note if you guys would be interested. This is, obviously,
> > a two way street -- Bigtop can provide the framework, but we
> > need your expertise in triaging problems as they arise.
> >
> > > I've built Pig on a multiple RHEL versions so this issue might not be
> as
> > > broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were
> > both
> > > built on rhel5 instances from ec2 (ami-2d8e4c44).
> >
> > Here's the map of affected Linux platforms:
> >
> >
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/
> >
> > Feel free to see the build logs. Also, if you, interested, I can give
> > you karma to poke around Bigtop's Jenkins.
> >
> > The AMIs are all stock AMIs produced either by the corresponding
> > Linux vendor (Fedora, OpenSUSE) or RightScale.
> >
> > As such, it seems that chance of unsuspecting users running into
> > this issue with the build are pretty high.
> >
> > > That said, if the Pig community feels strongly that we should cancel
> the
> > > release and re-issue a new one, I'm fine with shepherding that process.
> >
> > It would be extremely appreciated if you guys could go through the
> trouble
> > of spinning up a new RC. This is, of course, your decision but we'd be
> > willing
> > to help to the extent we can.
> >
> > As Mark mentioned -- the risk of the respin is pretty small -- the
> affected
> > changes are all build files and they are localized to contrib. Of course,
> > any RC is quite a bit of work.
> >
> > Thanks,
> > Roman.
> >
>

Re: Apache Pig 0.11.1 release candidate

Posted by Dmitriy Ryaboy <dv...@gmail.com>.
Roman and Mark,
Joining Bill here in thanking you for BigTop and all the integration work
you guys do.

Since this issue came up so late (after the vote), and, while it does
affect people trying to build an rpm, does not affect people just using Pig
jars, etc, I'd move to release 0.11.1 and consider the changes for 0.11.2.
I suspect we'll have a .2 release -- 0.12 has a lot of new stuff, so people
will likely stay on 11 for a while waiting for 12 to stabilize, and we'll
see more bugfix patches.

Using BigTop to validate an RC automatically would be great, let us know
what we can do to make that happen.

Best,
-D


On Sun, Mar 31, 2013 at 8:11 PM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi Bill!
>
> Thanks a million for chiming in!
>
> On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com>
> wrote:
> > Thanks for the work you're doing to support Pig in BigTop. Starting with
> > Pig 0.12, our release process will be simplified to not include rpm/deb
> > packages, thanks to BigTop.
>
> On a related note -- we're trying to work on a model where Bigtop
> could be utilized as RC (and pre-RC) integration validation framework.
> The gist of the idea is pretty simple -- we're planning to use the
> last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
> single component (lets say Pig) following the trunk/branch development.
> Hopefully that way all the integration problems could be uncovered
> earlier in the game.
>
> Drop us a note if you guys would be interested. This is, obviously,
> a two way street -- Bigtop can provide the framework, but we
> need your expertise in triaging problems as they arise.
>
> > I've built Pig on a multiple RHEL versions so this issue might not be as
> > broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were
> both
> > built on rhel5 instances from ec2 (ami-2d8e4c44).
>
> Here's the map of affected Linux platforms:
>
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/
>
> Feel free to see the build logs. Also, if you, interested, I can give
> you karma to poke around Bigtop's Jenkins.
>
> The AMIs are all stock AMIs produced either by the corresponding
> Linux vendor (Fedora, OpenSUSE) or RightScale.
>
> As such, it seems that chance of unsuspecting users running into
> this issue with the build are pretty high.
>
> > That said, if the Pig community feels strongly that we should cancel the
> > release and re-issue a new one, I'm fine with shepherding that process.
>
> It would be extremely appreciated if you guys could go through the trouble
> of spinning up a new RC. This is, of course, your decision but we'd be
> willing
> to help to the extent we can.
>
> As Mark mentioned -- the risk of the respin is pretty small -- the affected
> changes are all build files and they are localized to contrib. Of course,
> any RC is quite a bit of work.
>
> Thanks,
> Roman.
>

Re: Apache Pig 0.11.1 release candidate

Posted by Dmitriy Ryaboy <dv...@gmail.com>.
Roman and Mark,
Joining Bill here in thanking you for BigTop and all the integration work
you guys do.

Since this issue came up so late (after the vote), and, while it does
affect people trying to build an rpm, does not affect people just using Pig
jars, etc, I'd move to release 0.11.1 and consider the changes for 0.11.2.
I suspect we'll have a .2 release -- 0.12 has a lot of new stuff, so people
will likely stay on 11 for a while waiting for 12 to stabilize, and we'll
see more bugfix patches.

Using BigTop to validate an RC automatically would be great, let us know
what we can do to make that happen.

Best,
-D


On Sun, Mar 31, 2013 at 8:11 PM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi Bill!
>
> Thanks a million for chiming in!
>
> On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com>
> wrote:
> > Thanks for the work you're doing to support Pig in BigTop. Starting with
> > Pig 0.12, our release process will be simplified to not include rpm/deb
> > packages, thanks to BigTop.
>
> On a related note -- we're trying to work on a model where Bigtop
> could be utilized as RC (and pre-RC) integration validation framework.
> The gist of the idea is pretty simple -- we're planning to use the
> last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
> single component (lets say Pig) following the trunk/branch development.
> Hopefully that way all the integration problems could be uncovered
> earlier in the game.
>
> Drop us a note if you guys would be interested. This is, obviously,
> a two way street -- Bigtop can provide the framework, but we
> need your expertise in triaging problems as they arise.
>
> > I've built Pig on a multiple RHEL versions so this issue might not be as
> > broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were
> both
> > built on rhel5 instances from ec2 (ami-2d8e4c44).
>
> Here's the map of affected Linux platforms:
>
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/
>
> Feel free to see the build logs. Also, if you, interested, I can give
> you karma to poke around Bigtop's Jenkins.
>
> The AMIs are all stock AMIs produced either by the corresponding
> Linux vendor (Fedora, OpenSUSE) or RightScale.
>
> As such, it seems that chance of unsuspecting users running into
> this issue with the build are pretty high.
>
> > That said, if the Pig community feels strongly that we should cancel the
> > release and re-issue a new one, I'm fine with shepherding that process.
>
> It would be extremely appreciated if you guys could go through the trouble
> of spinning up a new RC. This is, of course, your decision but we'd be
> willing
> to help to the extent we can.
>
> As Mark mentioned -- the risk of the respin is pretty small -- the affected
> changes are all build files and they are localized to contrib. Of course,
> any RC is quite a bit of work.
>
> Thanks,
> Roman.
>

Re: Apache Pig 0.11.1 release candidate

Posted by Roman Shaposhnik <rv...@apache.org>.
Hi Bill!

Thanks a million for chiming in!

On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com> wrote:
> Thanks for the work you're doing to support Pig in BigTop. Starting with
> Pig 0.12, our release process will be simplified to not include rpm/deb
> packages, thanks to BigTop.

On a related note -- we're trying to work on a model where Bigtop
could be utilized as RC (and pre-RC) integration validation framework.
The gist of the idea is pretty simple -- we're planning to use the
last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
single component (lets say Pig) following the trunk/branch development.
Hopefully that way all the integration problems could be uncovered
earlier in the game.

Drop us a note if you guys would be interested. This is, obviously,
a two way street -- Bigtop can provide the framework, but we
need your expertise in triaging problems as they arise.

> I've built Pig on a multiple RHEL versions so this issue might not be as
> broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were both
> built on rhel5 instances from ec2 (ami-2d8e4c44).

Here's the map of affected Linux platforms:
    http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/

Feel free to see the build logs. Also, if you, interested, I can give
you karma to poke around Bigtop's Jenkins.

The AMIs are all stock AMIs produced either by the corresponding
Linux vendor (Fedora, OpenSUSE) or RightScale.

As such, it seems that chance of unsuspecting users running into
this issue with the build are pretty high.

> That said, if the Pig community feels strongly that we should cancel the
> release and re-issue a new one, I'm fine with shepherding that process.

It would be extremely appreciated if you guys could go through the trouble
of spinning up a new RC. This is, of course, your decision but we'd be willing
to help to the extent we can.

As Mark mentioned -- the risk of the respin is pretty small -- the affected
changes are all build files and they are localized to contrib. Of course,
any RC is quite a bit of work.

Thanks,
Roman.

Re: Apache Pig 0.11.1 release candidate

Posted by Roman Shaposhnik <rv...@apache.org>.
Hi Bill!

Thanks a million for chiming in!

On Sun, Mar 31, 2013 at 11:42 AM, Bill Graham <bi...@gmail.com> wrote:
> Thanks for the work you're doing to support Pig in BigTop. Starting with
> Pig 0.12, our release process will be simplified to not include rpm/deb
> packages, thanks to BigTop.

On a related note -- we're trying to work on a model where Bigtop
could be utilized as RC (and pre-RC) integration validation framework.
The gist of the idea is pretty simple -- we're planning to use the
last stable build of Bigtop (e.g. 0.6.0) and keep revving up one
single component (lets say Pig) following the trunk/branch development.
Hopefully that way all the integration problems could be uncovered
earlier in the game.

Drop us a note if you guys would be interested. This is, obviously,
a two way street -- Bigtop can provide the framework, but we
need your expertise in triaging problems as they arise.

> I've built Pig on a multiple RHEL versions so this issue might not be as
> broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were both
> built on rhel5 instances from ec2 (ami-2d8e4c44).

Here's the map of affected Linux platforms:
    http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/

Feel free to see the build logs. Also, if you, interested, I can give
you karma to poke around Bigtop's Jenkins.

The AMIs are all stock AMIs produced either by the corresponding
Linux vendor (Fedora, OpenSUSE) or RightScale.

As such, it seems that chance of unsuspecting users running into
this issue with the build are pretty high.

> That said, if the Pig community feels strongly that we should cancel the
> release and re-issue a new one, I'm fine with shepherding that process.

It would be extremely appreciated if you guys could go through the trouble
of spinning up a new RC. This is, of course, your decision but we'd be willing
to help to the extent we can.

As Mark mentioned -- the risk of the respin is pretty small -- the affected
changes are all build files and they are localized to contrib. Of course,
any RC is quite a bit of work.

Thanks,
Roman.

Re: Apache Pig 0.11.1 release candidate

Posted by Bill Graham <bi...@gmail.com>.
Hi Mark,

Thanks for the work you're doing to support Pig in BigTop. Starting with
Pig 0.12, our release process will be simplified to not include rpm/deb
packages, thanks to BigTop.

I've built Pig on a multiple RHEL versions so this issue might not be as
broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were both
built on rhel5 instances from ec2 (ami-2d8e4c44).

While I don't mind putting together another release, I think we should
proceed to release 0.11.1rc0 for the following reasons:

- since the vote passed and to respect the time people put in
testing/validating this release
- 0.11.1 contains support for Hadoop 0.20.2 and other critical bug fixes,
which people are anxious for. For fairness to those stakeholders, these
fixes were not put into a 0.11.0 RC when discovered late in that release
process.
- Pig 0.11.1 will contain an RPM as part of it's release artifacts.

That said, if the Pig community feels strongly that we should cancel the
release and re-issue a new one, I'm fine with shepherding that process.


As an alternative is it possible for you to build by setting the default
encoding externally? Or could you apply this patch to the pig 0.11.1 distro?

thanks,
Bill

On Fri, Mar 29, 2013 at 5:41 PM, Mark Grover <gr...@gmail.com>wrote:

> Hi all,
> I am a contributor to Apache Bigtop <http://bigtop.apache.org> and have a
> question for you.
> Bigtop is a TLP responsible for performing packaging and interoperability
> testing of various projects in the Hadoop ecosystem, including Apache Pig.
>
> We are planning to include Pig 0.11 in our soon to be released Bigtop 0.6
> distribution. However, while upgrading Pig from 0.10 to 0.11, I wasn't able
> to compile Pig 0.11.1 on RPM based
> systems<
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/313/label=centos6/console
> >.
> There doesn't seem to be anything Bigtop specific here, I would expect this
> issue to impact all Pig users. It seems like Pig's contrib sub-project uses
> the system's default encoding for compiling code; however on RPM based
> systems, the default encoding is not suitable and breaks the build. I
> created PIG-3262 <https://issues.apache.org/jira/browse/PIG-3262> to track
> this and Cheolsoo graciously committed this to Pig trunk. The essence of
> Bigtop is exactly to find integration issues like this.
>
> Now, I do realize that Bill and the community has done some excellent work
> in putting together 0.11.1. Perhaps, I am a little too late to ask this
> question but I thought I'd ask it anyway. Is there a possibility that the
> Pig community can release a new release candidate for 0.11.1 with the fix
> in PIG-3262?
>
> The pros:
> 1. It would allow Pig users to compile Pig contrib on RPM machines
> (RHEL/CentOS 5, 6, SLES 11, Fedora, etc.) which doesn't seem to be possible
> as of now.
> 2. It would enable Apache Bigtop 0.6 to include a Pig version that builds
> on all OS variants.
>
> The cons:
> 1. There is a cost of cutting out another release candidate to the Pig
> community. I completely understand and appreciate the cost involved;
> however, I would anticipate the cost to be minimal since a) the
> change<
> https://issues.apache.org/jira/secure/attachment/12575962/PIG-3262.2.patch
> >is
> quite trivial; b) the change only affects the contrib functionality
> and
> not the "core" functionality, per se.
>
> If we do decide to release another release candidate, I would be more than
> happy to perform integration testing on it by means of Apache Bigtop.
>
> I do realize the unfortunate timing of this email, it would have been ideal
> if we were having this conversation a week ago while the vote was still
> going on. I will try to change that in future so please do accept my
> apologies in advance.
>
> Regards,
> Mark
>



-- 
*Note that I'm no longer using my Yahoo! email address. Please email me at
billgraham@gmail.com going forward.*

Re: Apache Pig 0.11.1 release candidate

Posted by Bill Graham <bi...@gmail.com>.
Hi Mark,

Thanks for the work you're doing to support Pig in BigTop. Starting with
Pig 0.12, our release process will be simplified to not include rpm/deb
packages, thanks to BigTop.

I've built Pig on a multiple RHEL versions so this issue might not be as
broadly spanning as you describe. The RPMs for 0.11.0 and 0.11.1 were both
built on rhel5 instances from ec2 (ami-2d8e4c44).

While I don't mind putting together another release, I think we should
proceed to release 0.11.1rc0 for the following reasons:

- since the vote passed and to respect the time people put in
testing/validating this release
- 0.11.1 contains support for Hadoop 0.20.2 and other critical bug fixes,
which people are anxious for. For fairness to those stakeholders, these
fixes were not put into a 0.11.0 RC when discovered late in that release
process.
- Pig 0.11.1 will contain an RPM as part of it's release artifacts.

That said, if the Pig community feels strongly that we should cancel the
release and re-issue a new one, I'm fine with shepherding that process.


As an alternative is it possible for you to build by setting the default
encoding externally? Or could you apply this patch to the pig 0.11.1 distro?

thanks,
Bill

On Fri, Mar 29, 2013 at 5:41 PM, Mark Grover <gr...@gmail.com>wrote:

> Hi all,
> I am a contributor to Apache Bigtop <http://bigtop.apache.org> and have a
> question for you.
> Bigtop is a TLP responsible for performing packaging and interoperability
> testing of various projects in the Hadoop ecosystem, including Apache Pig.
>
> We are planning to include Pig 0.11 in our soon to be released Bigtop 0.6
> distribution. However, while upgrading Pig from 0.10 to 0.11, I wasn't able
> to compile Pig 0.11.1 on RPM based
> systems<
> http://bigtop01.cloudera.org:8080/view/Bigtop-trunk/job/Bigtop-trunk-Pig/313/label=centos6/console
> >.
> There doesn't seem to be anything Bigtop specific here, I would expect this
> issue to impact all Pig users. It seems like Pig's contrib sub-project uses
> the system's default encoding for compiling code; however on RPM based
> systems, the default encoding is not suitable and breaks the build. I
> created PIG-3262 <https://issues.apache.org/jira/browse/PIG-3262> to track
> this and Cheolsoo graciously committed this to Pig trunk. The essence of
> Bigtop is exactly to find integration issues like this.
>
> Now, I do realize that Bill and the community has done some excellent work
> in putting together 0.11.1. Perhaps, I am a little too late to ask this
> question but I thought I'd ask it anyway. Is there a possibility that the
> Pig community can release a new release candidate for 0.11.1 with the fix
> in PIG-3262?
>
> The pros:
> 1. It would allow Pig users to compile Pig contrib on RPM machines
> (RHEL/CentOS 5, 6, SLES 11, Fedora, etc.) which doesn't seem to be possible
> as of now.
> 2. It would enable Apache Bigtop 0.6 to include a Pig version that builds
> on all OS variants.
>
> The cons:
> 1. There is a cost of cutting out another release candidate to the Pig
> community. I completely understand and appreciate the cost involved;
> however, I would anticipate the cost to be minimal since a) the
> change<
> https://issues.apache.org/jira/secure/attachment/12575962/PIG-3262.2.patch
> >is
> quite trivial; b) the change only affects the contrib functionality
> and
> not the "core" functionality, per se.
>
> If we do decide to release another release candidate, I would be more than
> happy to perform integration testing on it by means of Apache Bigtop.
>
> I do realize the unfortunate timing of this email, it would have been ideal
> if we were having this conversation a week ago while the vote was still
> going on. I will try to change that in future so please do accept my
> apologies in advance.
>
> Regards,
> Mark
>



-- 
*Note that I'm no longer using my Yahoo! email address. Please email me at
billgraham@gmail.com going forward.*