Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <04705B3C-49A9-46B3-8AA9-5673EFBDE544@yahoo-inc.com>
References: <516684F5-0052-4381-805D-760B61DECB16@yahoo-inc.com>
	<366A9E58-5BD7-497D-9AE1-229959ED4065@apache.org>
	<18C5C999-4680-4684-BC55-A430C40FD746@yahoo-inc.com>
	<AANLkTim+y7CBi8WeV9W+FVckn-1D1SAV2hSc6RnEebSn@mail.gmail.com>
	<F8414465-24F2-4F40-97F1-B13048820F24@yahoo-inc.com>
	<D7FA8ED2-D9C6-4B45-AC3B-9E965ADD9F5D@apache.org>
	<2A07F1E6-7096-493B-B92E-89938689DD50@yahoo-inc.com>
	<5CDDF962-5828-459F-87C3-5033EC21E9BF@mac.com>
	<075308A1-129B-4BF7-8924-C04EC6106D3E@yahoo-inc.com>
	<AANLkTimbXjRTTmEXiY1wweFfNGKmc5aWKw9D03J7gjBg@mail.gmail.com>
	<388582DF-FC85-49D1-A89C-1F36CE34A0E2@yahoo-inc.com>
	<AANLkTim=+8_WBNbxU43xwH50WT8UQwbac_mR8FQ+0jjz@mail.gmail.com>
	<04705B3C-49A9-46B3-8AA9-5673EFBDE544@yahoo-inc.com>
Date: Thu, 13 Jan 2011 17:35:13 -0800
Message-ID: <AANLkTinAk+8YNLHb580uFibMWtNc=oYdqq+sOdBc+=6U@mail.gmail.com>
Subject: Re: [DISCUSS] Hadoop Security Release off Yahoo! patchset
From: Eli Collins <eli@cloudera.com>
To: "general@hadoop.apache.org" <general@hadoop.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thursday, January 13, 2011, Arun C Murthy <acm@yahoo-inc.com> wrote:
>
> On Jan 13, 2011, at 3:34 PM, Todd Lipcon wrote:
>
>
> On Thu, Jan 13, 2011 at 3:05 PM, Arun C Murthy <acm@yahoo-inc.com> wrote:
>
>
> Since this could be applied as a linear set of patches instead of a big
>
> lump, would there be interest in using this as the 0.20.>100 Apache
> release?
> I can take the time to remove any patches that are cloudera specific or
> not
> yet applied upstream.
>
>
>
> Interesting discussion, thanks.
>
> I'm sure it took you a fair amount of work to squash patches (which I tri=
ed
> too, btw).
>
>
>
> Yep, I had a great summer ;-)
>
>
>
> That, plus the fact that we would need to do a similar amount of work for
> the 10 or so releases we have done after 0.20.100.3 scares me.
>
>
>
> Sorry, I actually meant 0.20.104.3. Have there been many releases since
> then? That's the last version available on the Yahoo github, and that's t=
he
> version we incorporated/linearized.
>
>
> Yep. I had a great summer! ;-)
>
>
>
> As we Nigel and I discussed here, the jumbo =A0patch and an up-to-date
> CHANGES.txt provides almost all of the benefits we seek and allows all of=
 us
> to get this done very quickly to focus on hadoop-0.22 and beyond.
>
>
>
> In my opinion here are the downsides to this plan:
>
>
>
> I agree there are downsides, I think I did point them out at the outset! =
:)
>
>
> - a mondo "merge" patch is a big pain when trying to do debugging. It may=
 be
> sufficient for a user to look at CHANGES.txt, but I find myself using
> blame/log/etc on individual files to understand code lineage on a daily
> basis. If all of the merge shows up as a big patch it will be very diffic=
ult
> (at least the way I work with code) to help users debug issues or underst=
and
> which JIRA a certain regression may have come from.
>
>
>
> Right, no question. Which is why I offered to do this as a background act=
ivity right after... this ensures that the source of truth is *always* a br=
anch in Apache subversion.
>
> I feel that we could get a usable release out of door quickly for our use=
rs. Also, please remember that almost every patch we have committed is avai=
lable on relevant jiras. I understand the devs have a problem and I feel we=
 can bear with it for a little while. Again, I agree this isn't an ideal so=
lution, I'm just trying to expedite the release for the users.
>
>
>
> To clarify my position a bit here - I definitely appreciate your
> volunteering to do the work, and wouldn't *block* the proposal as you've =
put
> it forth. I just think it will have limited utility for the community by
> being opaque (if contributed as a giant patch) and by not including the s=
ync
> feature which is critical for a large segment of users. Given those
> downsides I'd rather see the effort diverted towards making a killer 0.22
> release that we can all jump on.
>
>
>
> Thanks for understanding.
>
> Again, I completely agree this isn't an ideal situation, but I do hope it=
 has a bit more than *limited utility* for our end-users. Who knows, I mayb=
e hopelessly deluded! *smile*
>
> Also, I'm trying to do exactly what you suggested - spend very little tim=
e on this so that everyone, including me, can focus on the future.
>
> thanks,
> Arun
>

Given that Todd has already done the work to rebase the 0.20.104.3
patch set on 0.20.2, and in a way that doesn't require one big change,
and his patch set includes branch20-append which the HBase guys want
an Apache release of wouldn't it make sense to go this route?  What do
others think? Seems better to have one 0.20.100 release than multiple
ones for security and append.

Thanks,
Eli