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

Switch to Threaded View
Pig >> mail # dev >> Pig 0.11

Copy link to this message
Re: Pig 0.11
No blog posts, but a long and tortured email thread on incubator general:  http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CCAOFYJNY%3DEjVHrWVvAedR3OKwCv-BkTaCbEu0ufp7OZR_gpCTiA%40mail.gmail.com%3E

In a nutshell the logic is:

1) Apache's legal constituting documents require this, I think mostly for reason 2 below.

2) PMC members can't examine binaries.  If I generate a binary and give it to you to vote on, how do you know I haven't nefariously hidden a virus in the binary?  With source you can personally check everything and make sure nothing evil has been done.  The same applies to end users who pick up the code.

3) Many Apache projects are repackaged by OS vendors, etc. (Redhat, and so on).  They prefer source releases because they want to reconfigure the layout in their own way anyway.


On Oct 26, 2012, at 11:36 AM, Jonathan Coveney wrote:

> Alan,
> Are there any blog posts or whatnot explaining the logic behind this?
> Just curious
> Jon
> 2012/10/25 Alan Gates <[EMAIL PROTECTED]>
>> There's one other issue I believe we should resolve before we release
>> 0.11.  As part of my work with the Incubator I've learned that official
>> Apache releases aren't supposed to have any binary code (including any
>> jars) in them.  Due to some recent issues with projects in the incubator
>> this has become a hot topic and some Apache members/officers have become
>> keen on making sure projects are in compliance.  Obviously Pig has been in
>> violation of this for a while now (oops).  We are still free to provide
>> "convenience packages" that contain the binaries, but they cannot be what
>> we vote on or what we sign and release.
>> What this practically means for us is we need a new ant target that just
>> tars up the source and we need to change the release procedures slightly to
>> sign and checksum the resulting tarball.  We would then post both the
>> source release and the "convenience package" which would be the same
>> release we have always done.
>> All the changes for this can be done in build.xml and the build procedures
>> wiki and are thus quite low risk.  I volunteer to do it.  I believe we
>> should do this for this release to avoid any issues with Apache.
>> Alan.
>> On Oct 22, 2012, at 1:14 PM, Olga Natkovich wrote:
>>> There are still 76 unresolved JIRAs more than half unassigned. Lets
>> clean this up by theend of this week. I propose we do the following:
>>> (1) Unlink all JIRAs for new features since we already branched so we
>> should not be taken on new work. If people feel strongly that some new
>> features still need to go in please bring it up.
>>> (2) For bug fixes, if people fill strongly that some of the unassigned
>> issues need to be addressed please take ownership. If you are unable to
>> solve them but still feel they are important, please, bring them up.
>>> (3) Owners of unresolved issues, please, take a look if you will have
>> time to solve them in the next 2 weeks. If not, lets move them to 12. If
>> you can't address them but feel they are important, please, bring it up.
>>> Lets make sure that all JIRAs that require changes to the documentation
>> have appropriate information in the release notes section so that we can
>> quickly compile release documentation.
>>> Thanks for you help!
>>> Olga
>>> ________________________________
>>> From: Alan Gates <[EMAIL PROTECTED]>
>>> Sent: Monday, October 15, 2012 11:55 AM
>>> Subject: Re: Pig 0.11
>>> At this point no one has taken on release documentation for 0.11.
>>> Alan.
>>> On Oct 15, 2012, at 11:49 AM, Olga Natkovich wrote:
>>>> Thanks!
>>>> Are you talking about items 15 and 16 on the How To Release.Publish
>> page?
>>>> Also, who is doing release documentation these days? I can help with
>> that as well. I would also be happy to roll the release if you guys need
>> help with that.