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

Switch to Threaded View
Hadoop, mail # general - [DISCUSS] Hadoop Security Release off Yahoo! patchset


Copy link to this message
-
Re: [DISCUSS] Hadoop Security Release off Yahoo! patchset
Eric Baldeschwieler 2011-01-25, 10:05
Hi Ian,

No votes have been called for at the moment.  Right now all arun's done is create a branch and ask for feedback from folks who want to try it.  Most of the forward ports are already either committed or in a patch available state, as arun mentioned.  We'll work through the others as individual JIRAs to allow everyone to kick the tires.  That should avoid issues with 0.22.  

I don't anticipate votes etc, unless folks do want to try it and do provide feedback.  This is what runs at yahoo at the moment.  I hope people think it is worth trying.

Thanks,

E14

On Jan 22, 2011, at 6:22 AM, Ian Holsman wrote:

>
> On Jan 19, 2011, at 1:12 PM, Konstantin Shvachko wrote:
>
>> On Tue, Jan 18, 2011 at 11:49 PM, Ian Holsman <[EMAIL PROTECTED]> wrote:
>>
>>> I think Roy's suggestion of applying the commits individually to the branch
>>> from your current working branch would help with this.
>>>
>>
>> I am sure this is not what Roy suggested. Ian. I think the idea is simple.
>
> to Quote Roy:
> b) create a branch off of some prior Apache release point in svn
>   and replay the internal Y! commits on that branch until the branch
>   source code is identical to what you have tested locally.  Then
>   RM a tarball based on that branch and start a release vote.
>   Since the history is now in svn, others could do the RM bit if
>   you don't have time.
>
>
> Arun has chosen option (c), that Roy also mentioned as a valid way of doing it.
>
>> If you decide to donate to a non-profit organization you are free to choose
>> the form of your donation.
>
>
> I think you are confusing a non-profit for a dumping ground.
> Any organization (non-profit or for-profit) has responsibilities, and their is always a tradeoff between features and risk. Any organization can choose to not accept a donation. It comes down to give-and-take
>
>
> As Roy also mentioned, option (c) will be harder for others to test, and get consensus about weather it is release worthy, let alone merge into 0.22.
>
>
>>
>> Thanks,
>> --Konstantin
>