Hi, Everyone,

We are getting close to cut a new RC for 0.7 release. Before we do that, I
want to ask people's opinion about those not well maintained non-java
clients. Currently, at least Ruby and Closure are not well maintained
(little or no activities). I am thinking about deleting those clients from
our svn for now. If those clients exist in github, we can probably leave a
forward pointer in a README in our Apache repository (is this ok with
Apache?). What do people think?

Thanks,

Jun

Alternately if anyone is willing to act as maintainer for those that would
be even better.

-Jay

On Tue, Oct 25, 2011 at 9:41 AM, Jun Rao <[EMAIL PROTECTED]> wrote:

> Hi, Everyone,
>
> We are getting close to cut a new RC for 0.7 release. Before we do that, I
> want to ask people's opinion about those not well maintained non-java
> clients. Currently, at least Ruby and Closure are not well maintained
> (little or no activities). I am thinking about deleting those clients from
> our svn for now. If those clients exist in github, we can probably leave a
> forward pointer in a README in our Apache repository (is this ok with
> Apache?). What do people think?
>
> Thanks,
>
> Jun
>

On 10/25/2011 12:41 PM, Jun Rao wrote:
> We are getting close to cut a new RC for 0.7 release. Before we do that, I
> want to ask people's opinion about those not well maintained non-java
> clients. Currently, at least Ruby and Closure are not well maintained
> (little or no activities). I am thinking about deleting those clients from

A general point.  The Clojure client doesn't seem to use the java/scala
api.  If someone wanted to, it would probably be possible to write a
clojure client as a thin wrapper instead of re-implementation (and thus
get access to the high level consumer, etc.)

> our svn for now. If those clients exist in github, we can probably leave a
> forward pointer in a README in our Apache repository (is this ok with
> Apache?).

Sounds good to me.

OK, how about we remove the closure client for now, since it is not a thin
wrapper and is not being maintained. Any objections?

Thanks,

On Wed, Oct 26, 2011 at 5:58 PM, Chris Burroughs
<[EMAIL PROTECTED]>wrote:

> On 10/25/2011 12:41 PM, Jun Rao wrote:
> > We are getting close to cut a new RC for 0.7 release. Before we do that,
> I
> > want to ask people's opinion about those not well maintained non-java
> > clients. Currently, at least Ruby and Closure are not well maintained
> > (little or no activities). I am thinking about deleting those clients
> from
>
> A general point.  The Clojure client doesn't seem to use the java/scala
> api.  If someone wanted to, it would probably be possible to write a
> clojure client as a thin wrapper instead of re-implementation (and thus
> get access to the high level consumer, etc.)
>
> > our svn for now. If those clients exist in github, we can probably leave
> a
> > forward pointer in a README in our Apache repository (is this ok with
> > Apache?).
>
> Sounds good to me.
>

Fine with me.

On 10/27/2011 12:43 AM, Jun Rao wrote:
> OK, how about we remove the closure client for now, since it is not a thin
> wrapper and is not being maintained. Any objections?
>
> Thanks,
>
> Jun
>
> On Wed, Oct 26, 2011 at 5:58 PM, Chris Burroughs
> <[EMAIL PROTECTED]>wrote:
>
>> On 10/25/2011 12:41 PM, Jun Rao wrote:
>>> We are getting close to cut a new RC for 0.7 release. Before we do that,
>> I
>>> want to ask people's opinion about those not well maintained non-java
>>> clients. Currently, at least Ruby and Closure are not well maintained
>>> (little or no activities). I am thinking about deleting those clients
>> from
>>
>> A general point.  The Clojure client doesn't seem to use the java/scala
>> api.  If someone wanted to, it would probably be possible to write a
>> clojure client as a thin wrapper instead of re-implementation (and thus
>> get access to the high level consumer, etc.)
>>
>>> our svn for now. If those clients exist in github, we can probably leave
>> a
>>> forward pointer in a README in our Apache repository (is this ok with
>>> Apache?).
>>
>> Sounds good to me.
>>
>