Arun also mentioned that he has created a separate branch ( http://svn.apache.org/viewvc/hadoop/common/branches/branch-0.20-security-patches/ ) for the individual patches.. so he is doing both.. so everyone should be happy.
--I On Jan 25, 2011, at 2:05 AM, Eric Baldeschwieler wrote: > 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 >> >
