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
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
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 want to derail the discussion about Stabilizing Internode
Messaging, so I'm starting this as a separate thread. There was a
comment that Josh made [1] about doing performance testing with real
clusters as well as a lot of microbenchmarks, and I'm 100% in support
of this. We've been workin
Hey Jon,
This sounds exciting and pretty useful, thanks.
Looking forward to using tlp-stress for validating 15066 performance.
We should touch base some time next week to pick a comprehensive set of
workloads and versions, perhaps?
> On 12 Apr 2019, at 16:34, Jon Haddad wrote:
>
> I don't w
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
+1
I’m also just as excited to see some standardised workloads and test bed. At
the moment we’re benefiting from some large contributors doing their own
proprietary performance testing, which is super valuable and something we’ve
lacked before. But I’m also keen to see some more representativ
+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
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
Hi Dinesh,
Great question! Unfortunately I don’t have a great definition of what
“alpha” means in the Cassandra community so its hard for me to answer that
directly. However, I am of the opinion that we are not yet at the point of
being able to branch trunk — we are finding too many bugs at too qu
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
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
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
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 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
I'd be more than happy to hop on a call next week to give you both
(and anyone else interested) a tour of our dev tools. Maybe something
early morning on my end, which should be your evening, could work?
I can set up a Zoom conference to get everyone acquainted. We can
record and post it for any
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
17 matches
Mail list logo
