Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
  b=kADa6ANAiBzlp5ATJi/uh2XoN8teaBcJTPQ57wM7Hfam5P8rfhM+BT8nnJFV9Zyyp3VksA+94PXP3vCxeexzVY6RsoAqrF7rRl9lEb7uWwRXNB5cfrEezLct+07O8868loAP/gt0Qz7bAfahZg5GhANfzdhwh3dKz0cXcCO7/A0=;
References: 
 <CAKtuutGg4kv8aZDz0awb-0N1Z0c7sbOcgFY2MP1MaKYu00TStQ@mail.gmail.com>
 <CA+z3+9EW_Jj2LV0_anEhAwZraLXZHvXnQj9bKQpbJZcqbbE4wg@mail.gmail.com>
 <CAKtuutGc1VKovv_JpRCjC7xx989G-N=0JdSSTd2XxD==Y1Kshg@mail.gmail.com>
 <CA+z3+9EFgvEXH+0xNBTL_TK40+FZAtG+SaZ0GMj+=JsBRUf7=A@mail.gmail.com>
 <CAKtuutHO_P0cesJNednhPwNK=_zeYkB2xa3MyoU3X3=Fztdeng@mail.gmail.com>
 <CA+z3+9H1uw_C-=dWmcEk_p6Yi6S8oqorKHa+F1Wg0W40ReF_pg@mail.gmail.com>
 <CAKtuutG=86QL11dPySFwFd=XU_hE6dxJZ0a0SuZS=-t9ZwPKPw@mail.gmail.com>
 <CA+z3+9FXB2rxs+q2JTERVBiuUPHdvdGcSqJVYSqVif+Qq1GvxA@mail.gmail.com>
 <CAKtuutHdE1xOLOGGC0mz_aoKvhpf1oPwn8Lmc9M-9NhbOkmhBg@mail.gmail.com>
 <CA+z3+9GuGn+wb7yoCNL7P8urNNz0C6piadfHw2RuN=fB8X5ORQ@mail.gmail.com>
 <20130325201742.GG1612@linspire.com>
 <CA+RK=_DrcT9b+DF3bQm2KTe5Xk_C3JWxcXjGa4wDn1Oj2bPhNQ@mail.gmail.com>
 <CAKtuutHu85n6apebT4SxW2Tjyu_nvSjS2cAWCR_k1SJynC8G_g@mail.gmail.com>
Message-ID: <1364255892.64725.YahooMailNeo@web125704.mail.ne1.yahoo.com>
Date: Mon, 25 Mar 2013 16:58:12 -0700 (PDT)
From: Tsz Wo Sze <szetszwo@yahoo.com>
Reply-To: Tsz Wo Sze <szetszwo@yahoo.com>
Subject: Re: [Vote] Merge branch-trunk-win to trunk
To: "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
  "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
  "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
  "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
In-Reply-To: 
 <CAKtuutHu85n6apebT4SxW2Tjyu_nvSjS2cAWCR_k1SJynC8G_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="-1903230837-249893468-1364255892=:64725"

---1903230837-249893468-1364255892=:64725
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Konstantin S,=0A=0AI accidentally merged some windows bug fixes to branc=
h-2.=A0 However, branch-2 did not compile -- it showed that the windows cha=
nges were missing in branch-2.=A0 The ones causing compilation problems wer=
e already reverted (Thanks Sid and Suresh.)=A0 Sorry for the inconvenience.=
=A0 =0A=0A=0ATsz-Wo=0A=0A=0A=0A=0A________________________________=0A From:=
 Konstantin Shvachko <shv.hadoop@gmail.com>=0ATo: mapreduce-dev@hadoop.apac=
he.org; hdfs-dev@hadoop.apache.org; common-dev@hadoop.apache.org; yarn-dev@=
hadoop.apache.org =0ASent: Tuesday, March 26, 2013 5:25 AM=0ASubject: Re: [=
Vote] Merge branch-trunk-win to trunk=0A =0AAndrew, this used to be on all =
-dev lists. Let's keep it that way.=0A=0ATo the point.=0ADoes this mean tha=
t people are silently porting windows changes to branch-2?=0ANew features o=
n a branch should be voted first, no?=0A=0AThanks,=0A--Konstantin=0A=0A=0AO=
n Mon, Mar 25, 2013 at 1:36 PM, Andrew Purtell <apurtell@apache.org> wrote:=
=0A> Noticed this too. Simply a 'public' modifier is missing, but it's uncl=
ear=0A> how this could not have been caught prior to check-in.=0A>=0A>=0A> =
On Mon, Mar 25, 2013 at 9:17 PM, Konstantin Boudnik <cos@apache.org> wrote:=
=0A>=0A>> It doesn't look like any progress has been done on the ticket bel=
ow in the=0A>> last 3 weeks. And now branch-2 can't be compiled because of=
=0A>>=0A>>=0A>> hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/ha=
doop/hdfs/TestDFSShell.java:[895,15]=0A>> WINDOWS is not public in org.apac=
he.hadoop.fs.Path; cannot be accessed from=0A>> outside package=0A>>=0A>> T=
hat's exactly why I was -1'ing this...=0A>>=A0  Cos=0A>>=0A>> On Mon, Mar 0=
4, 2013 at 05:41PM, Matt Foley wrote:=0A>> > Thanks, gentlemen.=A0 I've ope=
ned and taken responsibility for=0A>> > https://issues.apache.org/jira/brow=
se/HADOOP-9359.=A0 Giri Kesavan has=0A>> agreed=0A>> > to help with the par=
ts that require Jenkins admin access.=0A>> >=0A>> > Thanks,=0A>> > --Matt=
=0A>> >=0A>> >=0A>> >=0A>> > On Mon, Mar 4, 2013 at 5:00 PM, Konstantin Shv=
achko <=0A>> shv.hadoop@gmail.com>wrote:=0A>> >=0A>> > > +1 on the merge.=
=0A>> > >=0A>> > > I am glad we agreed.=0A>> > > Having Jira to track the C=
I effort is a good idea.=0A>> > >=0A>> > > Thanks,=0A>> > > --Konstantin=0A=
>> > >=0A>> > > On Mon, Mar 4, 2013 at 3:29 PM, Matt Foley <mfoley@hortonwo=
rks.com>=0A>> wrote:=0A>> > > > Thanks.=A0 I agree Windows -1's in test-pat=
ch should not block commits.=0A>> > > >=0A>> > > > --Matt=0A>> > > >=0A>> >=
 > >=0A>> > > >=0A>> > > > On Mon, Mar 4, 2013 at 2:30 PM, Konstantin Shvac=
hko <=0A>> > > shv.hadoop@gmail.com>=0A>> > > > wrote:=0A>> > > >>=0A>> > >=
 >> On Mon, Mar 4, 2013 at 12:22 PM, Matt Foley <mfoley@hortonworks.com=0A>=
> >=0A>> > > >> wrote:=0A>> > > >> > Konstantine, you have voted -1, and st=
ated some requirements=0A>> before=0A>> > > >> > you'll=0A>> > > >> > withd=
raw that -1.=A0 As I plan to do work to fulfill those=0A>> > > requirements=
, I=0A>> > > >> > want to make sure that what I'm proposing will, in fact, =
satisfy=0A>> you.=0A>> > > >> > That's why I'm asking, if we implement full=
 "test-patch"=0A>> integration=0A>> > > for=0A>> > > >> > Windows, does it =
seem to you that that would provide adequate=0A>> support?=0A>> > > >>=0A>>=
 > > >> Yes.=0A>> > > >>=0A>> > > >> > I have learned not to presume that m=
y interpretation is correct.=0A>>=A0 My=0A>> > > >> > interpretation of ite=
m #1 is that test-patch provides pre-commit=0A>> > > build,=0A>> > > >> > s=
o=0A>> > > >> > it would satisfy item #1.=A0 But rather than assuming that =
I am=0A>> > > >> > interpreting=0A>> > > >> > it correctly, I simply want y=
our agreement that it would, or if=0A>> not,=0A>> > > >> > clarification wh=
y it won't.=0A>> > > >>=0A>> > > >> I agree it will satisfy my item #1.=0A>=
> > > >> I did not agree in my previous email, but I changed my mind based =
on=0A>> > > >> the latest discussion. I have to explain why now.=0A>> > > >=
> I was proposing nightly build because I did not want pre-commit=0A>> buil=
d=0A>> > > >> for Windows block commits to Linux. But if people are fine ju=
st=0A>> ignoring=0A>> > > >> -1s for the Windows part of the build it shoul=
d be good.=0A>> > > >>=0A>> > > >> > Regarding item #2, it is also my inter=
pretation that test-patch=0A>> > > provides=0A>> > > >> > an=0A>> > > >> > =
on-demand (perhaps 20-minutes deferred) Jenkins build and unit=0A>> test,=
=0A>> > > >> > with=0A>> > > >> > logs available to the developer, so it wo=
uld satisfy item #2.=A0 But=0A>> > > >> > rather=0A>> > > >> > than assumin=
g that I am interpreting it correctly, I simply want=0A>> your=0A>> > > >> =
> agreement that it would, or if not, clarification why it won't.=0A>> > > =
>>=0A>> > > >> It will satisfy my item #2 in the following way:=0A>> > > >>=
 I can duplicate your pre-commit build for Windows and add an input=0A>> > =
> >> parameter, which would let people run the build on their patches=0A>> =
> > >> chosen from local machine rather than attaching them to Jiras.=0A>> =
> > >>=0A>> > > >> Thanks,=0A>> > > >> --Konstantin=0A>> > > >>=0A>> > > >>=
 > In agile terms, you are the Owner of these requirements.=A0 Please=0A>> =
give=0A>> > > me=0A>> > > >> > owner feedback as to whether my proposed wor=
k sounds like it will=0A>> > > >> > satisfy=0A>> > > >> > the requirements.=
=0A>> > > >> >=0A>> > > >> > Thank you,=0A>> > > >> > --Matt=0A>> > > >> >=
=0A>> > > >> >=0A>> > > >> > On Sun, Mar 3, 2013 at 12:16 PM, Konstantin Sh=
vachko=0A>> > > >> > <shv.hadoop@gmail.com>=0A>> > > >> > wrote:=0A>> > > >=
> >>=0A>> > > >> >> Didn't I explain in details what I am asking for?=0A>> =
> > >> >>=0A>> > > >> >> Thanks,=0A>> > > >> >> --Konst=0A>> > > >> >>=0A>>=
 > > >> >> On Sun, Mar 3, 2013 at 11:08 AM, Matt Foley <=0A>> mfoley@horton=
works.com>=0A>> > > >> >> wrote:=0A>> > > >> >> > Hi Konstantin,=0A>> > > >=
> >> > I'd like to point out two things:=0A>> > > >> >> > First, I already =
committed in this thread (email of Thu, Feb=0A>> 28,=0A>> > > 2013=0A>> > >=
 >> >> > at=0A>> > > >> >> > 6:01 PM) to providing CI for Windows builds.=
=A0 So please stop=0A>> acting=0A>> > > >> >> > like=0A>> > > >> >> > I'm=
=0A>> > > >> >> > resisting this idea or something.=0A>> > > >> >> > Second=
, you didn't answer my question, you just kvetched about=0A>> the=0A>> > > =
>> >> > phrasing.=0A>> > > >> >> > So I ask again:=0A>> > > >> >> >=0A>> > =
> >> >> > Will providing full "test-patch" integration (pre-commit build=0A=
>> and=0A>> > > >> >> > unit=0A>> > > >> >> > test=0A>> > > >> >> > trigger=
ed by Jira "Patch Available" state) satisfy your=0A>> request for=0A>> > > =
>> >> > functionality #1 and #2?=A0 Yes or no, please.=0A>> > > >> >> >=0A>=
> > > >> >> > Thanks,=0A>> > > >> >> > --Matt=0A>> > > >> >> >=0A>> > > >> =
>> >=0A>> > > >> >> > On Sat, Mar 2, 2013 at 7:32 PM, Konstantin Shvachko=
=0A>> > > >> >> > <shv.hadoop@gmail.com>=0A>> > > >> >> > wrote:=0A>> > > >=
> >> >>=0A>> > > >> >> >> Hi Matt,=0A>> > > >> >> >>=0A>> > > >> >> >> On S=
at, Mar 2, 2013 at 12:32 PM, Matt Foley <=0A>> > > mfoley@hortonworks.com>=
=0A>> > > >> >> >> wrote:=0A>> > > >> >> >> > Konstantin,=0A>> > > >> >> >>=
 > I would like to explore what it would take to remove this=0A>> > > >> >>=
 >> > perceived=0A>> > > >> >> >> > impediment --=0A>> > > >> >> >>=0A>> > =
> >> >> >> Glad you decided to explore. Thank you.=0A>> > > >> >> >>=0A>> >=
 > >> >> >> > although I reserve the right to argue that this is not=0A>> >=
 > >> >> >> > pre-requisite to merging the cross-platform support patch.=0A=
>> > > >> >> >>=0A>> > > >> >> >> It's your right indeed. So as mine to que=
stion what the=0A>> platform=0A>> > > >> >> >> support means for you, which=
 I believe remained unclear.=0A>> > > >> >> >> I do not impede the change a=
s you should have noticed. My=0A>> > > >> >> >> requirement=0A>> > > >> >> =
>> comes from my perception of the support, which means to me=0A>> exactly=
=0A>> > > >> >> >> two=0A>> > > >> >> >> things:=0A>> > > >> >> >> 1. The a=
bility to recognise the code is broken for the=0A>> platform=0A>> > > >> >>=
 >> 2. The ability to test new patches on the platform=0A>> > > >> >> >> Th=
e latter is problematic, as many noticed in this thread, for=0A>> > > those=
=0A>> > > >> >> >> whose customary environment does not include Windows.=0A=
>> > > >> >> >>=0A>> > > >> >> >> > If we implemented full "test-patch" sup=
port for Windows on=0A>> > > trunk,=0A>> > > >> >> >> > would=0A>> > > >> >=
> >> > that=0A>> > > >> >> >> > fulfill both your items #1 and #2?=A0 Pleas=
e note that:=0A>> > > >> >> >> > a) Pushing the "Patch Available" button in=
 Jira shall cause=0A>> a=0A>> > > >> >> >> > pre-commit=0A>> > > >> >> >> >=
 build to start within, I believe, 20 minutes.=0A>> > > >> >> >> > b) That =
build keeps logs for both java build and unit tests=0A>> for=0A>> > > >> >>=
 >> > several=0A>> > > >> >> >> > days, that are accessible to all viewers.=
=0A>> > > >> >> >>=0A>> > > >> >> >> In item #1 I mostly asking for the nig=
htly build, which is=0A>> simpler=0A>> > > >> >> >> than "test-patch". The =
latter would be ideal from the platform=0A>> > > >> >> >> support=0A>> > > =
>> >> >> viewpoint, but it is for the community to decide if we want=0A>> t=
o add=0A>> > > >> >> >> extra +3 hours to the build.=0A>> > > >> >> >> Nigh=
tly build in my understanding is triggered by the timer=0A>> rather=0A>> > =
> >> >> >> than by Jira's "submit patch" button.=A0 On Jenkins build=0A>> >=
 > >> >> >> configuration=0A>> > > >> >> >> you can specify it under "Build=
 periodically".=0A>> > > >> >> >>=0A>> > > >> >> >> > So, does this provide=
 sufficient on-demand support that we=0A>> don't=0A>> > > >> >> >> > have=
=0A>> > > >> >> >> > to=0A>> > > >> >> >> > implement a whole new on-demand=
 VM support structure of some=0A>> > > sort=0A>> > > >> >> >> > for=0A>> > =
> >> >> >> > #2=0A>> > > >> >> >> > (which would be an extraordinary and im=
practical demand)?=0A>> > > >> >> >>=0A>> > > >> >> >> I did not mention VM=
s. Item #2 means a build, which runs=0A>> > > >> >> >> "test-patch"=0A>> > =
> >> >> >> target with the file specified by a user (instead of a jira=0A>>=
 > > >> >> >> attachment).=0A>> > > >> >> >> When user clicks "Build Now" l=
ink a box is displayed where the=0A>> > > user=0A>> > > >> >> >> can enter =
the file path containing the patch. This can be=0A>> > > specified=0A>> > >=
 >> >> >> in=0A>> > > >> >> >> the Build Configuration under "This build is=
 parameterized" by=0A>> > > >> >> >> choosing AddParameter / FileParameter.=
 The build can run on=0A>> the=0A>> > > same=0A>> > > >> >> >> Windows mach=
ine as the nightly build.=0A>> > > >> >> >> Such build will let people test=
 their patches for Windows on=0A>> > > Jenkins=0A>> > > >> >> >> if they do=
n't posses a license for the right version of=0A>> Windows.=0A>> > > >> >> =
>> I hope this will not turn into extraordinary or impractical=0A>> > > eff=
ort.=0A>> > > >> >> >>=0A>> > > >> >> >> Thanks,=0A>> > > >> >> >> --Konst=
=0A>> > > >> >> >>=0A>> > > >> >> >> > Thanks,=0A>> > > >> >> >> > --Matt=
=0A>> > > >> >> >> >=0A>> > > >> >> >> >=0A>> > > >> >> >> > On Fri, Mar 1,=
 2013 at 12:18 PM, Konstantin Shvachko=0A>> > > >> >> >> > <shv.hadoop@gmai=
l.com>=0A>> > > >> >> >> > wrote:=0A>> > > >> >> >> >>=0A>> > > >> >> >> >>=
 -1=0A>> > > >> >> >> >> We should have a CI infrastructure in place before=
 we can=0A>> > > commit=0A>> > > >> >> >> >> to=0A>> > > >> >> >> >> suppor=
ting Windows platform.=0A>> > > >> >> >> >>=0A>> > > >> >> >> >> Eric is ri=
ght Win/Cygwin was supported since day one.=0A>> > > >> >> >> >> I had a Wi=
ndows box under my desk running nightly builds=0A>> back=0A>> > > in=0A>> >=
 > >> >> >> >> 2006-07.=0A>> > > >> >> >> >> People were irritated but I wa=
s filing windows bugs until=0A>> 0.22=0A>> > > >> >> >> >> release.=0A>> > =
> >> >> >> >> Times changing and I am glad to see wider support for Win=0A>=
> > > >> >> >> >> platform.=0A>> > > >> >> >> >>=0A>> > > >> >> >> >> But i=
n order to make it work you guys need to put the CI=0A>> > > process=0A>> >=
 > >> >> >> >> in=0A>> > > >> >> >> >> place=0A>> > > >> >> >> >>=0A>> > > =
>> >> >> >> 1. windows jenkins build: could be nightly or PreCommit.=0A>> >=
 > >> >> >> >> - Nightly would mean that changes can be committed to trunk=
=0A>> > > based=0A>> > > >> >> >> >> on=0A>> > > >> >> >> >> linux PreCommi=
t build. And people will file bugs if the=0A>> change=0A>> > > >> >> >> >> =
broke=0A>> > > >> >> >> >> Windows nightly build.=0A>> > > >> >> >> >> - Pr=
eCommit-win build will mean automatic reporting failed=0A>> > > tests=0A>> =
> > >> >> >> >> to=0A>> > > >> >> >> >> respective jira blocking commits th=
e same way as it is now=0A>> with=0A>> > > >> >> >> >> linux=0A>> > > >> >>=
 >> >> PreCommit builds.=0A>> > > >> >> >> >> We should discuss which way i=
s more efficient for=0A>> developers.=0A>> > > >> >> >> >>=0A>> > > >> >> >=
> >> 2. On-demand-windows Jenkins build.=0A>> > > >> >> >> >> I see it as a=
 build to which I can attach my patch and the=0A>> > > build=0A>> > > >> >>=
 >> >> will=0A>> > > >> >> >> >> run my changes on a dedicated windows box.=
=0A>> > > >> >> >> >> That way people can test their changes without having=
=0A>> personal=0A>> > > >> >> >> >> windows=0A>> > > >> >> >> >> nodes.=0A>=
> > > >> >> >> >>=0A>> > > >> >> >> >> I think this is the minimal set of r=
equirement for us to be=0A>> > > able=0A>> > > >> >> >> >> to=0A>> > > >> >=
> >> >> commit to the new platform.=0A>> > > >> >> >> >> Right now I see on=
ly one windows related build=0A>> > > >> >> >> >> https://builds.apache.org=
/view/Hadoop/job/Hadoop-1-win/=0A>> > > >> >> >> >> Which was failing since=
 Sept 8, 2012 and did not run in the=0A>> > > last=0A>> > > >> >> >> >> mon=
th.=0A>> > > >> >> >> >>=0A>> > > >> >> >> >> Thanks,=0A>> > > >> >> >> >> =
--Konst=0A>> > > >> >> >> >>=0A>> > > >> >> >> >> On Thu, Feb 28, 2013 at 8=
:47 PM, Eric Baldeschwieler=0A>> > > >> >> >> >> <eric14@hortonworks.com> w=
rote:=0A>> > > >> >> >> >> > +1 (non-binding)=0A>> > > >> >> >> >> >=0A>> >=
 > >> >> >> >> > A few of observations:=0A>> > > >> >> >> >> >=0A>> > > >> =
>> >> >> > - Windows has actually been a supported platform for=0A>> Hadoop=
=0A>> > > >> >> >> >> > since=0A>> > > >> >> >> >> > 0.1=0A>> > > >> >> >> =
>> > .=0A>> > > >> >> >> >> > Doug championed supporting windows then and w=
e've=0A>> continued=0A>> > > to=0A>> > > >> >> >> >> > do=0A>> > > >> >> >>=
 >> > it=0A>> > > >> >> >> >> > with=0A>> > > >> >> >> >> > varying vigor o=
ver time.=A0 To my knowledge we've never=0A>> made a=0A>> > > >> >> >> >> >=
 decision=0A>> > > >> >> >> >> > to=0A>> > > >> >> >> >> > drop windows sup=
port.=A0 The change here is improving our=0A>> > > support=0A>> > > >> >> >=
> >> > and=0A>> > > >> >> >> >> > dropping=0A>> > > >> >> >> >> > the requi=
rement of cigwin.=A0 We had Nutch windows users=0A>> on the=0A>> > > >> >> =
>> >> > list=0A>> > > >> >> >> >> > in=0A>> > > >> >> >> >> > 2006=0A>> > >=
 >> >> >> >> > and we've been supporting windows FS requirements since=0A>>=
 > > >> >> >> >> > inception.=0A>> > > >> >> >> >> >=0A>> > > >> >> >> >> >=
 - A little pragmatism will go a long way.=A0 As a community=0A>> > > we've=
=0A>> > > >> >> >> >> > got=0A>> > > >> >> >> >> > to=0A>> > > >> >> >> >> =
> stay committed to keeping hadoop simple (so it does work=0A>> on=0A>> > >=
 >> >> >> >> > many=0A>> > > >> >> >> >> > platforms)=0A>> > > >> >> >> >> =
> and extending it to take advantage of key emerging=0A>> > > OS/hardware=
=0A>> > > >> >> >> >> > features,=0A>> > > >> >> >> >> > such as containers=
, new FSs, virtualization, flash ...=0A>>=A0 We=0A>> > > >> >> >> >> > shou=
ld=0A>> > > >> >> >> >> > all=0A>> > > >> >> >> >> > plan=0A>> > > >> >> >>=
 >> > to let new features & optimizations emerge that don't=0A>> work=0A>> =
> > >> >> >> >> > everywhere, if=0A>> > > >> >> >> >> > they are compelling=
 and central to hadoop's mission of=0A>> being=0A>> > > >> >> >> >> > THE=
=0A>> > > >> >> >> >> > best=0A>> > > >> >> >> >> > fabric=0A>> > > >> >> >=
> >> > for storing and processing big data.=0A>> > > >> >> >> >> >=0A>> > >=
 >> >> >> >> > - A UI project like KDE has to deal with the MANY=0A>> diffe=
rences=0A>> > > >> >> >> >> > between=0A>> > > >> >> >> >> > windows and li=
nux UI APIs.=A0 Hadoop faces no such complex=0A>> > > >> >> >> >> > challen=
ge=0A>> > > >> >> >> >> > and hence=0A>> > > >> >> >> >> > can be maintaine=
d from a single codeline IMO.=A0 It is=0A>> mostly=0A>> > > >> >> >> >> > a=
bstracted from=0A>> > > >> >> >> >> > the OS APIs via Java and our design c=
hoices.=A0 Where it=0A>> is not=0A>> > > >> >> >> >> > we=0A>> > > >> >> >>=
 >> > can=0A>> > > >> >> >> >> > continue to add plugable abstractions.=0A>=
> > > >> >> >> >> >=0A>> > > >> >> >> >=0A>> > > >> >> >> >=0A>> > > >> >> =
>=0A>> > > >> >> >=0A>> > > >> >=0A>> > > >> >=0A>> > > >=0A>> > > >=0A>> >=
 >=0A>>=0A>=0A>=0A>=0A> --=0A> Best regards,=0A>=0A>=A0 =A0 - Andy=0A>=0A> =
Problems worthy of attack prove their worth by hitting back. - Piet Hein=0A=
> (via Tom White)
---1903230837-249893468-1364255892=:64725--