Re: Proposal: github pull requests for all code changes

[Jeff Jirsa]

Inline

-- 
Jeff Jirsa


> On Dec 20, 2017, at 8:38 PM, kurt greaves  wrote:
> 
> It would definitely be nice if PR's were made against the actual repo.
> Makes commenting/reviewing code a lot easier. I'd say as long as PR's are
> kept permanently (after closing) so we can go back and look over
> comments/patches would be a big plus. Not a fan of going through JIRA
> tickets and finding the linked branches have been deleted.

Same 

> 
> However not sure about having different identifiers/labels everywhere.
> Considering we'll still be creating JIRA tickets it makes sense to me to
> use JIRA for labelling/categorisation, and github simply for reviewing
> code. Don't really want to go assigning JIRA tickets then have to repeat
> the proceduce for github and make sure all labels align.
> 
> Also, if we're adding "closes #123" to commit messages that implies we'll
> have "patch by y, reviewed by x for CASSANDRA- closes #123"?

Yes, and we’re already doing that 
https://github.com/apache/cassandra/commit/db81f6bffef1a8215fec28bb0522dc9684870627

> I don't
> know if there is a way to do it (doubtful), but it'd certainly be nice if
> JIRA ticket numbers aligned with PR numbers.

Not possible as far as I know 


> 
>> On 21 December 2017 at 02:56, mck  wrote:
>> 
>> 
>>> There's also no way for us to label, assign or otherwise use PR related
>>> features, so I'm really wondering why it would make sense to more
>>> heavily using them.
>> 
>> 
>> Apache does now offer the GitBox service. This makes the github repository
>> writable. The asf and github repos are kept in sync, rather than one being
>> a mirror of the other.
>> 
>> I'm not entirely sure this would be the right move for C*, given that
>> patches and branches are merged in a manner that GitHub pull requests don't
>> do (unless you're only committing to trunk). But it would mean PRs can be
>> closed otherwise by any of the committers, and to use the reviewers,
>> assignees, labels, projects and milestone fields.
>> 
>> Mick.
>> 
>> 
>> ref:
>> - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-
>> Gitbox-td18273.html
>> - https://s3.amazonaws.com/files-dist/AnnualReports/
>> FY2017-ASF-AnnualReport-FINAL.pdf
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 

Re: Proposal: github pull requests for all code changes

[kurt greaves]

It would definitely be nice if PR's were made against the actual repo.
Makes commenting/reviewing code a lot easier. I'd say as long as PR's are
kept permanently (after closing) so we can go back and look over
comments/patches would be a big plus. Not a fan of going through JIRA
tickets and finding the linked branches have been deleted.

However not sure about having different identifiers/labels everywhere.
Considering we'll still be creating JIRA tickets it makes sense to me to
use JIRA for labelling/categorisation, and github simply for reviewing
code. Don't really want to go assigning JIRA tickets then have to repeat
the proceduce for github and make sure all labels align.

Also, if we're adding "closes #123" to commit messages that implies we'll
have "patch by y, reviewed by x for CASSANDRA- closes #123"? I don't
know if there is a way to do it (doubtful), but it'd certainly be nice if
JIRA ticket numbers aligned with PR numbers.

On 21 December 2017 at 02:56, mck  wrote:

>
> > There's also no way for us to label, assign or otherwise use PR related
> > features, so I'm really wondering why it would make sense to more
> > heavily using them.
>
>
> Apache does now offer the GitBox service. This makes the github repository
> writable. The asf and github repos are kept in sync, rather than one being
> a mirror of the other.
>
> I'm not entirely sure this would be the right move for C*, given that
> patches and branches are merged in a manner that GitHub pull requests don't
> do (unless you're only committing to trunk). But it would mean PRs can be
> closed otherwise by any of the committers, and to use the reviewers,
> assignees, labels, projects and milestone fields.
>
> Mick.
>
>
> ref:
>  - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-
> Gitbox-td18273.html
>  - https://s3.amazonaws.com/files-dist/AnnualReports/
> FY2017-ASF-AnnualReport-FINAL.pdf
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposal: github pull requests for all code changes

[mck]

> There's also no way for us to label, assign or otherwise use PR related
> features, so I'm really wondering why it would make sense to more
> heavily using them.


Apache does now offer the GitBox service. This makes the github repository 
writable. The asf and github repos are kept in sync, rather than one being a 
mirror of the other.

I'm not entirely sure this would be the right move for C*, given that patches 
and branches are merged in a manner that GitHub pull requests don't do (unless 
you're only committing to trunk). But it would mean PRs can be closed otherwise 
by any of the committers, and to use the reviewers, assignees, labels, projects 
and milestone fields.

Mick.


ref:
 - http://apache-nifi.1125220.n5.nabble.com/DISCUSS-Apache-Gitbox-td18273.html
 - 
https://s3.amazonaws.com/files-dist/AnnualReports/FY2017-ASF-AnnualReport-FINAL.pdf
 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: How to fetch replication factor of a given keyspace

[kurt greaves]

Did you look at how status fetches and initialises the keyspace? Have a
look at org.apache.cassandra.service.StorageService#effectiveOwnership. It
uses a keyspace and its RF to measure ownership. The same method should
work for any nodetool command that needs a keyspace. Note that depending on
what you are using it for you may need to handle each strategy differently
(and also handle LocalStrategy).

On 21 December 2017 at 01:02, Tyagi, Preetika 
wrote:

> Hi,
>
> If I need to get the replication factor of a given keyspace in nodetool
> commands (e.g. status), how can I do that? I'm trying to figure it out for
> a JIRA item I'm working on.
>
> I tried using the below:
> Keyspace keyspace = Keyspace.open(keyspaceName);
> Int rf = keyspace.getReplicationStrategy().getReplicationFactor()
>
> However, it runs into some issues since internally something doesn't get
> initialized while looking up keyspaces/metatadata.
>
> Any ideas on how I can approach it differently?
>
> Thanks,
> Preetika
>
>

Re: How to fetch replication factor of a given keyspace

[Nate McCall]

I think you want:
Schema.instance.getKeyspaceMetadata

There is a ReplicationParams nested under there which should have
everything you need fully populated.

On Thu, Dec 21, 2017 at 2:02 PM, Tyagi, Preetika
 wrote:
> Hi,
>
> If I need to get the replication factor of a given keyspace in nodetool 
> commands (e.g. status), how can I do that? I'm trying to figure it out for a 
> JIRA item I'm working on.
>
> I tried using the below:
> Keyspace keyspace = Keyspace.open(keyspaceName);
> Int rf = keyspace.getReplicationStrategy().getReplicationFactor()
>
> However, it runs into some issues since internally something doesn't get 
> initialized while looking up keyspaces/metatadata.
>
> Any ideas on how I can approach it differently?
>
> Thanks,
> Preetika
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

How to fetch replication factor of a given keyspace

[Tyagi, Preetika]

Hi,

If I need to get the replication factor of a given keyspace in nodetool 
commands (e.g. status), how can I do that? I'm trying to figure it out for a 
JIRA item I'm working on.

I tried using the below:
Keyspace keyspace = Keyspace.open(keyspaceName);
Int rf = keyspace.getReplicationStrategy().getReplicationFactor()

However, it runs into some issues since internally something doesn't get 
initialized while looking up keyspaces/metatadata.

Any ideas on how I can approach it differently?

Thanks,
Preetika

Reviewer for CASSANDRA-14055

[Oleksandr Petrov]

Hi everyone,

I still couldn't find enough time to review the
https://issues.apache.org/jira/browse/CASSANDRA-14055 for which I'm deeply
sorry.

It's a SASI issue related to index redistribution.
Unfortunately, this week doesn't look very promising in terms of time as
well, so I'm making a call for reviewer if anyone has capacity to take it.

If there are any takers, please feel free to assign yourself as reviewer.

Thank you

Best regards,
Alex Petrov