Re: Somewhat Weekly Cassandra Dev Wrapup

[kurt greaves <ku...@instaclustr.com>]

It's usually pretty clear what is a fix in the changes log but they
definitely require checking. However I'd say putting more boilerplate in
the changes log isn't really necessary and would be hard to enforce. If we
could generate a report with this information from JIRA with desired
information would be better (e.g all ticket names, type, maybe even
labels). I'd hope JIRA has this functionality...​

Re: Somewhat Weekly Cassandra Dev Wrapup

[Malcolm Taylor <ma...@semmle.com>]

Glad to hear you are finding lgtm.com useful. I work for Semmle, the
company behind lgtm.com.

I see you are interested in checking regularly for new and fixed  alerts on
lgtm.com. This can be achieved through our Github integration described in
https://lgtm.com/docs/lgtm/using-lgtm-analysis-continuous-integration , and
is a great way to get more value from the analysis.

Regarding the hashCode violations, I think the relevant query is
https://lgtm.com/projects/g/apache/cassandra/alerts/?mode=tree&severity=error&rule=6770060
which identifies a number of classes that implement equals() without
overriding hashCode(). That would be a good place to find some further
straightforward fixes.

Thanks for the feedback regarding the Range class. I shall pass that on to
our Java team to see what they think. lgtm uses a deep analysis based on a
powerful query language (QL) which runs against a database representing all
of the source code. We are generally able to keep the number of false
positives low, but there are inevitably some that creep through, so we
appreciate the feedback. One of the strengths of our approach is that it is
often quite easy to tweak a query to make it more precise, and thus
eliminate some false positives. It is also possible to suppress individual
alerts if desired.

QL has also proved highly effective at identifying important security flaws
in various systems, including some of the apache projects. There are lots
of examples of the use of QL in our blog section at https://lgtm.com/blog

- Malcolm


On 1 November 2017 at 01:09, Jeff Beck <be...@gmail.com> wrote:

> On the hashCode violations they are all on
> https://github.com/apache/cassandra/blob/trunk/src/java/
> org/apache/cassandra/dht/Range.java
> which
> does seem to get the correct hashcode impl from
> https://github.com/apache/cassandra/blob/trunk/src/java/
> org/apache/cassandra/dht/AbstractBounds.java
>
> Jeff
>
>
>

Re: Somewhat Weekly Cassandra Dev Wrapup

[Jeff Beck <be...@gmail.com>]

On the hashCode violations they are all on
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/Range.java
which
does seem to get the correct hashcode impl from
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/dht/AbstractBounds.java

Jeff

On Tue, Oct 31, 2017 at 7:42 PM kurt greaves <ku...@instaclustr.com> wrote:

> Looks like that solves that problem. Probably wouldn't be a bad idea to
> include that list in the release posts as well as link to changes.txt? At
> the very least it will make us a bit more careful about assigning fix
> versions (maybe).
>
> On 1 November 2017 at 00:36, Michael Shuler <mi...@pbandjelly.org>
> wrote:
>
> > On 10/31/2017 07:17 PM, kurt greaves wrote:
> > > It's usually pretty clear what is a fix in the changes log but they
> > > definitely require checking. However I'd say putting more boilerplate
> in
> > > the changes log isn't really necessary and would be hard to enforce. If
> > we
> > > could generate a report with this information from JIRA with desired
> > > information would be better (e.g all ticket names, type, maybe even
> > > labels). I'd hope JIRA has this functionality...​
> > >
> >
> > It does have release notes that is split up by issue type:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > projectId=12310865&version=12336842
> >
> > --
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>

Re: Somewhat Weekly Cassandra Dev Wrapup

[kurt greaves <ku...@instaclustr.com>]

Looks like that solves that problem. Probably wouldn't be a bad idea to
include that list in the release posts as well as link to changes.txt? At
the very least it will make us a bit more careful about assigning fix
versions (maybe).

On 1 November 2017 at 00:36, Michael Shuler <mi...@pbandjelly.org> wrote:

> On 10/31/2017 07:17 PM, kurt greaves wrote:
> > It's usually pretty clear what is a fix in the changes log but they
> > definitely require checking. However I'd say putting more boilerplate in
> > the changes log isn't really necessary and would be hard to enforce. If
> we
> > could generate a report with this information from JIRA with desired
> > information would be better (e.g all ticket names, type, maybe even
> > labels). I'd hope JIRA has this functionality...​
> >
>
> It does have release notes that is split up by issue type:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12310865&version=12336842
>
> --
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>

Re: Somewhat Weekly Cassandra Dev Wrapup

[Michael Shuler <mi...@pbandjelly.org>]

On 10/31/2017 07:17 PM, kurt greaves wrote:
> It's usually pretty clear what is a fix in the changes log but they
> definitely require checking. However I'd say putting more boilerplate in
> the changes log isn't really necessary and would be hard to enforce. If we
> could generate a report with this information from JIRA with desired
> information would be better (e.g all ticket names, type, maybe even
> labels). I'd hope JIRA has this functionality...​
> 

It does have release notes that is split up by issue type:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310865&version=12336842

-- 
Michael

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