Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39AD810BA3 for ; Thu, 21 Nov 2013 21:17:08 +0000 (UTC) Received: (qmail 74978 invoked by uid 500); 21 Nov 2013 21:17:08 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 74944 invoked by uid 500); 21 Nov 2013 21:17:08 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 74936 invoked by uid 99); 21 Nov 2013 21:17:08 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Nov 2013 21:17:08 +0000 Received: from localhost (HELO mail-lb0-f181.google.com) (127.0.0.1) (smtp-auth username ctubbsii, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Nov 2013 21:17:07 +0000 Received: by mail-lb0-f181.google.com with SMTP id q8so269329lbi.12 for ; Thu, 21 Nov 2013 13:17:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=BdHoOLUt8xX1luZfbAMrkW3f0uAwEQWDzgTw/ypbQKI=; b=A0PnYgtRaVYQcdZsszkc7Qm1lolxYa+64QHKMs4QhDupjR21ZFlPguoSeRL7v3CsPY 8U8KU/un5uy78iyfCSSpq9T5WSPMHNrgjngCij5sW71W0HxSVe8i16oGjvEbBVmvMR/4 wgTLrOLYYko6rk8qJEA0jhXcEeHF7a1HfuftiFWK/1Ccvm27cVs8gqW6thZO/SMksRhi Egli2t6G9K/MongI+forlviOmYGL46DoVRk8OgEzBM6BK1qjQgTluCLNTowLsUZtiQei cfJ1MyU3DsR1nnekGIQrYa3PgY3wEUOYRRV8fHEfV8WjOBwLEVVvYR+IdP1v/iMceWrl GiaA== MIME-Version: 1.0 X-Received: by 10.112.55.212 with SMTP id u20mr6223134lbp.4.1385068625769; Thu, 21 Nov 2013 13:17:05 -0800 (PST) Received: by 10.114.177.231 with HTTP; Thu, 21 Nov 2013 13:17:05 -0800 (PST) In-Reply-To: References: <5265BA45.4010505@gmail.com> <5265C995.1060001@gmail.com> Date: Thu, 21 Nov 2013 16:17:05 -0500 Message-ID: Subject: Re: remove wikisearch from 1.4.x development? From: Christopher To: Accumulo Dev List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I favor #2 (because it hasn't actually been removed from 1.4.x, so there isn't any "putting back" necessary), but #1 is fine with me, too, as long as we release a version of this example that will work against 1.4.5 Accumulo. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, Nov 21, 2013 at 4:12 PM, Bill Havanki w= rote: > I'll just wade in here=E2=80=A6 :/ > > The contrib wikisearch relies on MapFileIterator, which was introduced in > Accumulo 1.5.0. It used to use MyMapFile, which was purged way back in > ACCUMULO-288, early 2012. (This predates the split of wikisearch into a > contrib.) > > So, the contrib wikisearch won't even compile against 1.4.x, and a trail = of > commits have been made since the split. We have options, then: > > 1. Create a branch in the contrib and get it working for 1.4.x. > 2. Put the 1.4.x non-contrib copy back, and "do stuff" (Sean's > techno-jargon) to get it to work for Hadoop 2. Leave the contrib for 1.5.= 0+. > 3. Backport MapFileIterator (et al.?) to 1.4.x so the contrib works as is > (hopefully). > 4. Other? > > I lean toward #1. > > Bill > > > On Thu, Nov 21, 2013 at 3:42 PM, Christopher wrote: > >> Are you suggesting skipping a version number, if necessary, or that we >> can wait to push out a 1.4.6 WS until 1.4.6 ACC? >> >> If the latter, I'm not sure we can assume there will be a 1.4.6 ACC. >> To both options, it seems that 1.4.4 WS won't work on 1.4.5 ACC >> without changes to support Hadoop 2, so it seems that some newer >> release of WS is warranted. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Tue, Nov 19, 2013 at 11:15 PM, Michael Berman >> wrote: >> >> >> >> Imagine 1.4.4 WS is compatible with 1.4.5 ACC, but then 1.4.6 introdu= ces >> >> a change that causes us to bump WS... now 1.4.5 WS is needed for 1.4.= 6 >> >> ACC, but won't work on 1.4.5 ACC >> > >> > >> > Small point...in this situation, I don't see any reason 1.4.5 WS needs= to >> > exist at all. 1.4.6 WS could be the minimum version for 1.4.6 ACC. >> > >> > >> > On Tue, Nov 19, 2013 at 5:19 PM, Christopher >> wrote: >> > >> >> On Tue, Nov 19, 2013 at 9:59 AM, Sean Busbey < >> busbey+ml@clouderagovt.com> >> >> wrote: >> >> > On Tue, Nov 19, 2013 at 8:05 AM, Christopher >> >> wrote: >> >> [snip] >> >> > We would expressly not being claiming that wikisearch is a part of = our >> >> > public API, correct? >> >> >> >> I don't understand this question. >> >> >> >> > What kind of testing would be involved for doing a release of the >> >> > wikisearch contrib? Just unit tests as is done with it as part of t= he >> >> 1.4.x >> >> > branch? >> >> >> >> Usually, when we do a release, we test that all the examples work >> >> according to the relevant README, not just verify unit tests pass in >> >> the build. >> >> >> >> > Would the releases from the contrib repo need to have version numbe= rs >> >> that >> >> > match the 1.4.x line, or would a compatibility statement for each >> release >> >> > be sufficient? >> >> >> >> Well, Wikisearch has already been released as 1.4.0, 1.4.1, 1.4.2, >> >> 1.4.3, and 1.4.4. Now that it's a sub-project, we don't need to >> >> continue versioning together if it will work with multiple versions, >> >> but it could be confusing if it didn't. Imagine 1.4.4 WS is compatibl= e >> >> with 1.4.5 ACC, but then 1.4.6 introduces a change that causes us to >> >> bump WS... now 1.4.5 WS is needed for 1.4.6 ACC, but won't work on >> >> 1.4.5 ACC. That's very confusing to users, even with a compatibility >> >> statement. >> >> >> >> Since you indicated that changes to Wikisearch 1.4.4 would be needed >> >> to make it compatible with Hadoop 2 in Accumulo 1.4.5, it seems to >> >> make sense to bump it also. Whether we should continue doing this or >> >> not, is a discussion we can have at another time... I can see merits >> >> in both options... but I wouldn't want to change the convention on a >> >> bugfix/minor release even if we do agree to separate the versioning i= n >> >> the future. >> >> >> >> -- >> >> Christopher L Tubbs II >> >> http://gravatar.com/ctubbsii >> >> >> > > > > -- > | - - - > | Bill Havanki > | Solutions Architect, Cloudera Government Solutions > | - - -