accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: remove wikisearch from 1.4.x development?
Date Thu, 21 Nov 2013 21:12:11 GMT
I'll just wade in hereā€¦ :/

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 <ctubbsii@apache.org> 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 <mberman@sqrrl.com>
> wrote:
> >>
> >> Imagine 1.4.4 WS is compatible 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
> >
> >
> > 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 <ctubbsii@apache.org>
> 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 <ctubbsii@apache.org>
> >> 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 the
> >> 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 numbers
> >> 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 compatible
> >> 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 in
> >> the future.
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
>



-- 
| - - -
| Bill Havanki
| Solutions Architect, Cloudera Government Solutions
| - - -

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message