Thanks Jeremy. To come back to the original idea, for an LHF crew how
about as these:
- a weekly(?) list of LHF tickets sent to dev list
- sharing fliters of the above (can we put these on the how to contribute page?)
- adopt Jeff B.'s idea of tagging LHF your own self as part of our
culture/proces
It sounds like everyone is on the same page - there won’t be a rubber stamp.
It’s just to have a concerted effort to help these tickets move along as
they’re often the first experience that contributors have with the project.
I’m sure many of you know of the ‘lhf' tag that’s out there with an
I create a new jira to track this: CASSANDRA-12814, which is linked to
CASSANDRA-10414.
@Nate, agree. And it would be great if we can batch the reads from
different partitions but still on the same physical host as well, which
will be valuable for our existing and potential use cases.
Thanks
Dika
Tagging tickets as LHF is a great idea. There's plenty of people that
would love to set up a JIRA dashboard saved search / nightly email for LHF
tickets.
On Wed, Oct 19, 2016 at 1:34 PM Jeff Beck wrote:
> Would it make sense to allow people submitting the patch to flag things as
> LHF or small
I see a few slightly different things here (equally valuable) in
conjunction with CASSANDRA-10414:
- Wanting a small number of specific, non-sequential rows out of the
same partition (this is common, IME) and grouping those
- Extending batch semantics to reads with the same understanding with
mutat
Github user eprothro closed the pull request at:
https://github.com/apache/cassandra/pull/77
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
GitHub user eprothro opened a pull request:
https://github.com/apache/cassandra/pull/77
12804 3.x
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/eprothro/cassandra 12804-3.X
Alternatively you can review and apply these changes
Would it make sense to allow people submitting the patch to flag things as
LHF or small tasks? If it doesn't look like it is simple enough the team
could remove the label but it may help get feedback to patches more
quickly, even something saying accepted for review would be nice.
Personally if a
Github user deshpamit closed the pull request at:
https://github.com/apache/cassandra/pull/76
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
The null(zero) values of snapshot are useless for problem analysing, because it
is impossible to distinguishing case when there are no events from case when
events were dispatched too slow. I do not see any criminal to return 999-th
percentile as 3h when histogram configured with 3h max and any
Also no one has said anything to the effect of 'we want to rubber stamp
reviews' so that ...evil reason. Many of us are coders by trade and
understand why that is bad.
On Wednesday, October 19, 2016, Edward Capriolo
wrote:
> I realize that test passing a small tests and trivial reviews will not
I would suggest metrics should return null values instead of false values.
On Wed, Oct 19, 2016 at 12:21 PM, Владимир Бухтояров <
jseco...@mail.ru.invalid> wrote:
>
> Hi to all,
>
> I want to fix https://issues.apache.org/jira/browse/CASSANDRA-11063
> This issue is very ugly for me, because when
I realize that test passing a small tests and trivial reviews will not
catch all issues. I am not attempting to trivialize the review process.
Both deep and shallow bugs exist. The deep bugs, I am not convinced that
even an expert looking at the contribution for N days can account for a
majority
Github user jeffjirsa commented on the issue:
https://github.com/apache/cassandra/pull/76
@deshpamit - Thanks so much for your patch. Two points:
1) The project uses JIRA for patches and issue tracking, not github issues
/ pull requests. We'll try to get patches wherever they
Let’s not get too far in the theoretical weeds. The email thread really focused
on low hanging tickets – tickets that need review, but definitely not 8099
level reviews:
1) There’s a lot of low hanging tickets that would benefit from outside
contributors as their first-patch in Cassandra (like
Hi to all,
I want to fix https://issues.apache.org/jira/browse/CASSANDRA-11063
This issue is very ugly for me, because when something works slow then it is
impossible to capture metrics and save it to monitoring database for future
investigation. Moreover when one histogram throw exception the
And just to be clear, I think everyone would welcome more testing for both
regressions of new code correctness. I think everyone would appreciate the
time savings around more automation. That should give more time for a
thoughtful review - which is likely what new contributors really need to g
I specifically used the phrase "problems that the test would not" to show I
am talking about more than mechanical correctness. Even if the tests are
perfect (and as Jeremiah points out, how will you know that without reading
the code?), you can still pass tests with bad code. And is expecting
per
Unless the reviewer reviews the for content, then you don’t know if they do or
not.
-Jeremiah
> On Oct 19, 2016, at 10:52 AM, Jonathan Haddad wrote:
>
> Shouldn't the tests test the code for correctness?
>
> On Wed, Oct 19, 2016 at 8:34 AM Jonathan Ellis wrote:
>
>> On Wed, Oct 19, 2016 at
Shouldn't the tests test the code for correctness?
On Wed, Oct 19, 2016 at 8:34 AM Jonathan Ellis wrote:
> On Wed, Oct 19, 2016 at 8:27 AM, Benjamin Lerer <
> benjamin.le...@datastax.com
> > wrote:
>
> > Having the test passing does not mean that a patch is fine. Which is why
> we
> > have a rev
On Wed, Oct 19, 2016 at 8:27 AM, Benjamin Lerer wrote:
> Having the test passing does not mean that a patch is fine. Which is why we
> have a review check list.
> I never put a patch available without having the tests passing but most of
> my patches never pass on the first try. We always make mi
There's a similar ticket focusing on range reads and secondary index
queries, but the work for these could be done together:
https://issues.apache.org/jira/browse/CASSANDRA-10414
On Tue, Oct 18, 2016 at 5:59 PM, Dikang Gu wrote:
> Hi there,
>
> We have couple use cases that are doing fanout read
Having the test passing does not mean that a patch is fine. Which is why we
have a review check list.
I never put a patch available without having the tests passing but most of
my patches never pass on the first try. We always make mistakes no matter
how hard we try.
The reviewer job is to catch th
Yes. The LHFC crew should always pay it forward. Not many of us have a
super computer to run all the tests, but for things that are out there
marked patch_available apply it to see that it applies clean, if it
includes a test run that test (and possibly some related ones in the
file/folder etc for
On 19 October 2016 at 05:30, Nate McCall wrote:
> if you are offering up resources for review and test coverage,
> there is work out there. Most immediately in the department of reviews
> for "Patch Available."
>
We can certainly put some minds to this. There are a few of us with a very
good und
Ugh, just finally figured the "header" bit of my question out. Mega lame. :\
> On Oct 18, 2016, at 9:17 AM, Michael Kjellman
> wrote:
>
> I'm working on writing Birch for trunk and I noticed the following:
>
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/colu
26 matches
Mail list logo
