cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3507) Proposal: separate cqlsh from CQL drivers
Date Tue, 03 Jan 2012 20:54:47 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13179010#comment-13179010
] 

paul cannon commented on CASSANDRA-3507:
----------------------------------------

(Jonathan)
bq. Really? It feels weird to have a PMC vote on artifacts for something they don't develop.

Should that be any more weird than having a vote on artifacts which _contain_ other artifacts
that the PMC doesn't develop? It seems to me like the C* PMC also puts its stamp of support+approval
on snakeyaml, Thrift, and all the rest, by including them in the voted sources and artifacts.

But whether it's weird or not, yeah, I couldn't find anything prohibiting it.

bq. (While there is overlap between the python cql driver and our PMC, it's not entirely the
same thing and it's likely to diverge further in the future, or at least that was the idea
of hosting drivers out of tree.)

I thought the idea of out-of-tree drivers was so that they could be released out of sync with
C* itself. But if the maintainer-sets for python-cql and c* do diverge in the future, the
PMC would still need to decide if it is going to "support" that driver or not. If so, no reason
not to ship it. If not, don't.

(Sylvain)
bq. But in a minor release, anything that require more than 'apt-get update' from the user
is a regression from his point of view.

Agreed. But that regression already occurred, in 1.0.6- I'm just suggesting we fix that regression
by shipping the missing component, rather than by backing out the change entirely. But either
way is good.

bq. I don't know. I mean that there has been a number of comments on that issue, and some
doubt on what we can and cannot do

I haven't seen any doubt expressed since my last proposal, except Jonathan's comment replied
to above.

bq. (it would be counter-productive to start doing this some way to change it in two release,
so we'd better make sure we're covered on that

Agreed.


                
> Proposal: separate cqlsh from CQL drivers
> -----------------------------------------
>
>                 Key: CASSANDRA-3507
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3507
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Packaging, Tools
>    Affects Versions: 1.0.3
>         Environment: Debian-based systems
>            Reporter: paul cannon
>            Assignee: paul cannon
>            Priority: Blocker
>              Labels: cql, cqlsh
>             Fix For: 1.0.7
>
>
> Whereas:
> * It has been shown to be very desirable to decouple the release cycles of Cassandra
from the various client CQL drivers, and
> * It is also desirable to include a good interactive CQL client with releases of Cassandra,
and
> * It is not desirable for Cassandra releases to depend on 3rd-party software which is
neither bundled with Cassandra nor readily available for every target platform, but
> * Any good interactive CQL client will require a CQL driver;
> Therefore, be it resolved that:
> * cqlsh will not use an official or supported CQL driver, but will include its own private
CQL driver, not intended for use by anything else, and
> * the Cassandra project will still recommend installing and using a proper CQL driver
for client software.
> To ease maintenance, the private CQL driver included with cqlsh may very well be created
by "copying the python CQL driver from one directory into another", but the user shouldn't
rely on this. Maybe we even ought to take some minor steps to discourage its use for other
purposes.
> Thoughts?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message