I want to point out something: https://issues.apache.org/jira/browse/CASSANDRA-6846
"I'm definitively -1 on putting any type of contract on the internals. They are called internals for a reason, and if rewriting it all entirely tomorrow is best for Cassandra, we should have the possibility to do so." Not attempting to pick words apart here. I find this problematic. A large problem is highlighted in this debate. Everything "works as is" or in this case "not at all". It is hard to say "what it ever did" or know what it is "supposed to do". The black box testing and code coverage does not (IMHO) do enough to document what layered internal api's do. For example, in my recent experience. I was recently looking over OutboundTcpConnection. There are a large number of cases where "undroppable" verbs are dropped. There is defiantly no inline documentation (and little/no direct testing) that leads me to believe a contract exists. In the past (and this is just my bias opinion) I have had my attempts to refactor some "works as is" code labeled "bikeshedding". It does make it rather intimidating for someone to pick up an issue. The barrier for entry to code "appears" to black box testing, while the barrier for for make it better "appears" to be "get-off-my-lawn". Technically: I think we could do better with clear components (aka APIs), initialized using clear dependency injection, such that they can me unit and mock tested such that they all directly do some provable thing. For example: When does outbound TCPConnection drop droppable verbs? Is there a test that shows this? If there is no test how can the goto statement be refactored so that the code is more testable. ETC. On Tuesday, October 18, 2016, Benedict Elliott Smith <bened...@apache.org> wrote: > I'm not certain this is the best way to go about encouraging people to help > you, or generally encourage participation in the project. You have seemed > to lash out at the project (and in this case me specifically) in a fairly > antagonistic manner a multitude of times in just a couple of hours. > > Your original question, on zero, predates anything I know about. JIRA is > your best bet, and provides historical context that is never going to live > in comments. I did not imply that the comments were adequate, only that > *this > is where you should probably look to answer your question. *Comment policy > and norms have changed a lot throughout Cassandra's history, and you're > asking about a time that predates the current level of maturity, but JIRA > has always been (AFAIK) the main source of historical context. I attempted > to provide some links into this to save you from the "billion" (handful) of > tickets. > > I don't have time for another flamewar, so I will leave out trying to > assist you in future. > > > > > On 18 October 2016 at 18:28, Michael Kjellman < > mkjell...@internalcircle.com> > wrote: > > > Sorry, No. Always document your assumptions. I shouldn't need to git > blame > > a thousand commits and read thru a billion tickets to maybe understand > why > > something was done. Clearly thru the conversations on this topic I've had > > on IRC and the responses so far on this email thread it's not/still not > > obvious. > > > > best, > > kjellman > > > > On Oct 18, 2016, at 10:07 AM, Benedict Elliott Smith < > bened...@apache.org > > <mailto:bened...@apache.org>> wrote: > > > > This is what JIRA is for. > > > > >
