Josh - You are 100% correct on that - I appreciate you calling it out.
In re-reading this, I think that came out sideways and significantly
harsher from what I intended. My apologies to Benedict and Aleksey.
My (poorly made) point was that collaboration is the lifeblood of any
open source project.
>
> a couple of people (even if I know them personally,
> consider them friends and are both among the best engineers i've ever
> met) going off in a room and producing something in isolation is more
> or less a giant "f*k you" to the open source process and our community
> as a whole.
Two enginee
As someone who has been here a (very) long time and worked on C* in
production envs. back to version 0.4, this large patch - taken by
itself - does, to be frank, scare the shit out of me. In a complex
system any large change will have side effects impossible to
anticipate. I have seen this hold tru
It seems to me that the corner stone here is the development process.
If the work and review is done openly (e.g. on JIRA or Github) we
wouldn't be having this post factum conversation, because all of the
progress would be visible, so it would make sense to just squash before
committing
if so prefe
Can you start a new thread to build consensus on your proposals for modifying
the commit process?
I do not share your views, as already laid out in my first email. The
community makes these decisions through building consensus, and potentially a
vote of the PMC. This scope of change requires
It seems like one of the main points of contention isn’t so much the the
content of the patch, but more about the amount of review this patch has/will
receive relative to its perceived risk. If it’s the latter, then I think it
would be more effective to explain why that’s the case, and what leve
Since their seems to be an assumption that I haven’t read the code let me
clarify: I am working on making time to be a reviewer on this and I have
already spent a few hours with the patch before I sent any replies, likely
more than most who are replying here. Again, because I disagree on
non-techni
I would once again exhort everyone making these kinds of comment to actually
read the code, and to comment on Jira. Preferably with a justification by
reference to the code for how or why it would improve the patch.
As far as a design document is concerned, it’s very unclear what is being
requ
On Fri, Apr 12, 2019 at 10:15 AM Jordan West wrote:
> I understand these non-technical discussions are not what everyone wants to
> focus on but they are extremely pertinent to the stability of the project.
> What I would like to see before merging this in is below. They are all
> reasonable asks
+1 Thanks for articulating that so well Josh.
Sam
> On 12 Apr 2019, at 16:19, Blake Eggleston
> wrote:
>
> Well said Josh. You’ve pretty much summarized my thoughts on this as well.
>
> +1 to moving forward with this
>
>> On Apr 11, 2019, at 10:15 PM, Joshua McKenzie wrote:
>>
>> As one of
I understand these non-technical discussions are not what everyone wants to
focus on but they are extremely pertinent to the stability of the project.
What I would like to see before merging this in is below. They are all
reasonable asks in my opinion that will still result in the patch being
merge
Well said Josh. You’ve pretty much summarized my thoughts on this as well.
+1 to moving forward with this
> On Apr 11, 2019, at 10:15 PM, Joshua McKenzie wrote:
>
> As one of the two people that re-wrote all our unit tests to try and help
> Sylvain get 8099 out the door, I think it's inaccurate
I don’t have a lot to add to Josh’s contribution, except that I’d like to
really hammer home that many people were a party to 8099, and as a project we
learned a great deal from the experience. It’s a very complex topic, that does
not lend itself to simple comparisons, but I think anyone who pa
On Thu, Apr 11, 2019 at 10:15 PM Joshua McKenzie
wrote:
> As one of the two people that re-wrote all our unit tests to try and help
> Sylvain get 8099 out the door, I think it's inaccurate to compare the scope
> and potential stability impact of this work to the truly sweeping work that
> went in
As one of the two people that re-wrote all our unit tests to try and help
Sylvain get 8099 out the door, I think it's inaccurate to compare the scope
and potential stability impact of this work to the truly sweeping work that
went into 8099 (not to downplay the scope and extent of this work here).
Sorry to pick only a few points to address, but I think these are ones
where I can contribute productively to the discussion.
> In principle, I agree with the technical improvements you
mention (backpressure / checksumming / etc). These things should be there.
Are they a hard requirement for 4.0?
> On Apr 10, 2019, at 9:06 AM, Sankalp Kohli wrote:
>
> I think we should wait for testing doc on confluence to come up and discuss
> what all needs to be added there to gain confidence.
>
> If the work is more to split the patch into smaller parts and delays 4.0 even
> more, can we use time
I think we should wait for testing doc on confluence to come up and discuss
what all needs to be added there to gain confidence.
If the work is more to split the patch into smaller parts and delays 4.0 even
more, can we use time in adding more test coverage, documentation and design
docs to th
There is a lot of discuss here so I’ll try to keep my opinions brief:
1. The bug fixes are a requirement in order to have a stable 4.0. Whether
they come from this patch or the original I have less of an opinion. I do
think its important to minimize code changes at this time in the
development/fre
Here's are my 2¢.
I think the general direction of this work is valuable but I have a few
concerns I’d like to address. More inline.
> On Apr 4, 2019, at 1:13 PM, Aleksey Yeschenko wrote:
>
> I would like to propose CASSANDRA-15066 [1] - an important set of bug fixes
> and stability improvemen
To be fair, even though the patch totals to 20K LoC, the core of the patch
is within reasonable bounds (around net.async.*). There are many changes
because of the code that got moved around. Some parts changes look large
because Java is quite a verbose language (e.g., metric tables).
Unfortunately,
Appreciate everyone's input. It sounds like there's broad agreement that the
fixes need to make it into 4.0, which I'm really pleased to see. The question
seems to be moving towards scope and timing.
TL;DR: This patch is probably the most efficient route to a stable 4.0. The
patch is already re
Let's try this again, apparently email is hard ...
I am relatively new to these code paths—especially compared to the
committers that have been working on these issues for years such as
the 15066 authors as well as Jason Brown—but like many Cassandra users
I am familiar with many of the classes of
*I am relatively new to these code paths—especially compared to the
committers that have been working on these issues for years such as the
15066 authors as well as Jason Brown—but like many Cassandra users I am
familiar with many of the classes of issues Aleksey and Benedict have
identified with t
Given the number of issues that are addressed, I definitely think it's
worth strongly considering merging this in. I think it might be a
little unrealistic to cut the first alpha after the merge though.
Being realistic, any 20K+ LOC change is going to introduce its own
bugs, and we should be hones
Great to see such a significant progress made in the area!
On Thu, Apr 4, 2019 at 1:13 PM Aleksey Yeschenko wrote:
> I would like to propose CASSANDRA-15066 [1] - an important set of bug fixes
> and stability improvements to internode messaging code that Benedict, I,
> and others have been worki
Definitely sounds like it is worth taking a 2nd look here. Given that this is
in relation to brand new code for 4.0, I agree that it makes sense to get it
right the first time, rather than applying bandaids to 4.0 and rewriting things
for 4.next. I think 4.0 should be a solid starting point for
27 matches
Mail list logo
