Re: Updating our Code Contribution/Style Guide
It looks like the doc already specified this behaviour for ternary operator line wrapping. For your proposal I’ve also added the following: It is usually preferable to carry the operator for multiline expressions, with the exception of some multiline string literals. Does that work for you? The “usually” at least leaves some wiggle room, as ultimately I would prefer this decision to be made by an author (even if a general norm of carrying the operator is preferable). I am concerned that this starts leaning towards being too specific, though. It opens up questions like whether we should also be specifying spacing for loop guards, conditions, casts, etc? From: bened...@apache.org Date: Sunday, 20 March 2022 at 21:37 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide > We are talking about one extra line, not a dozen or more. I think you are confused about the context. The case I was discussing often means 10+ additional lines at each call-site. > Once the code gets more real, it is faster to read the difference between (a) > and (c) This isn’t a great example, as if you are line-wrapping with multiple parameters you should be assigning any computation to a clearly named local variable before passing the result to the constructor (amongst other things). We can perhaps highlight this in the style guide. We also do not only produce multi-line computations in this context. If constructing into a variable (where there is no such ambiguity), it is much easier to parse parameters first without the concatenation operator preceding them. My point is simply that legislating on this kind of detail is a waste of our time, and probably counter-productive. I don’t want to enumerate all the possible ways we might construct multi-line computations. Ternary operators are pretty clear, so maybe we can just agree to define those, and leave the rest to the judgement of the authors? From: Mick Semb Wever Date: Sunday, 20 March 2022 at 20:56 To: dev@cassandra.apache.org Subject: Re: Updating our Code Contribution/Style Guide > I support this too… leads to more noise in, and less readability of, the > patch. Readability of the patch is not harmed with modern tooling (with whitespace being highlighted differently to content changes). Legibility of the code (not patch) should always be preferred IMO. To aid code comprehension, we should aim for density of useful information for the reader; wasting a dozen or more lines on zero information density, solely to solve a problem already handled by modern diff tools, is a false economy. We are talking about one extra line, not a dozen or more. It also improves the readability of the code IMHO. > I would also like to suggest that an operator should always carry on line > wraps For the ternary operator I agree, however I am less convinced in other cases. String concatenation is probably cleaner with the opposite norm, so that string literals are aligned. IMHO it works for string concatenation too. The example that comes to mind is a) method( "a", "b", "c" ) b) method( "a" + "b" + "c" ) c) method( "a" + "b" + "c" ) Once the code gets more real, it is faster to read the difference between (a) and (c) than it (a) and (b).
Cassandra project biweekly status update 2022-03-21
Congrats Aleksandr Sorokoumov on being raised to a Committer on the project. It's been a pleasure working with you for a few years on the project and the honor is well deserved. [New contributor Getting Started] First off, welcome! As a new contributor we recommend starting in one of two places: Failing tests, or starter tickets we label "lhf" (low hanging fruit). Either category is a great place to get started learning both the codebase and also our processes and the community. Query for failing tests (68 currently unassigned): https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496&quickFilter=2252 Query for unassigned starter tickets (25 unassigned): https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160 As you can see, there's a lot to do around here! [Dev list conversations] https://lists.apache.org/list?dev@cassandra.apache.org:lte=2w: So what have we been up to these past two weeks? Stefan Miklosovic took on the herculean, and perhaps masochistic task ;), of cleaning up our github PR's: https://lists.apache.org/thread/pxc1hcz4hty8m6qfjp156mtqd1vmhz7t. Given these PR's aren't formally tied into our merge process and we haven't documented the right way to perform house-cleaning with them, it's something we should probably discuss further as a project so we don't regress to this state again in the future. Thanks Stefan; that had to have been pretty grueling! Discussion continues about having multiple community groups on LinkedIn, some informal and some formally endorsed by the PMC: https://lists.apache.org/thread/6s8j1mzw81fb0mz81pdyg48v507myrkm. Tibor opened the discussion about the right next steps for our usage of the now deprecated airlift / airline framework used in our CLI tools: https://lists.apache.org/thread/bc15lg79dl29q51w92nn2t0d2v7f5yvx. As a reminder for those that might not know, we restrict API breaking changes to Majors only and qualify CLI output changes as API breaking as we can expect operational tooling to depend on formats for functionality. There's been some back and forth rumblings about ApacheCon, CFP's, and the performance engineering track. Nothing to announce in this status email but expect something soon from the PMC on this front. [CI Trends] Butler dashboard: https://butler.cassandra.apache.org/#/ Pretty rough spot this time. We had a change go into the JenkinsFile that temporarily broke the reporting of python dtest results to butler and the bot I've been running manually. What that means in practice: increased failures showing accurately now. For each branch here's the from -> to for the past 2 weeks: trunk: 5 -> 19 4.0: 9 -> 16 3.11: 20 -> 30 3.0: 16 -> 15 This takes our total from 50 -> 80, a 60% increase. We have a freeze for 4.1 coming up in May and are blocking release on a green run on ASF infra, so the 19 failures on trunk are staring us right in the face. [Release progress] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2175 4.0.4: We closed out 9 issues in the past 2 weeks. Highlights are a fix to an exception when doing an UPDATE on a row using CONTAINS (CASSANDRA-15266), better support for snapshot characters in nodetool snapshot (CASSANDRA-15297), fixing the snapshot true size calculation (CASSANDRA-17267), cleaning up unshared heap size calculation (CASSANDRA-17402), and validating the existence of a DC when repairing (CASSANDRA-17407). A lot of fixing on the 4.0 line this past couple of weeks; good to see. 4.1.0: We've closed out 26(!) issues on the 4.1 line this past couple of weeks. That's 2.6x as many as we closed in the prior time window! Highlights include GossipInfo being available in a virtual table (CASSANDRA-17002), a refactor of schema management to allow for a schema source (CASSANDRA-17044) which should pave the way for optional consistent schema management implementations, Paxos Improvements for CEP-14 (CASSANDRA-17164) which is a large body of work - congrats to Benedict and Blake on getting that across the line, Andres keeps grinding away adding new guardrails at a fevered pace (CASSANDRA-17153, 17187, 17188), some improvements to the messaging from guardrails (CASSANDRA-17430), and a variety of test environment and config environment changes and cleanups. Really too many to mention here so check the link above if you're curious. 6 weeks to go until freeze and things are trucking along. If we manage to hold our test failures on trunk steady at this level before we branch and freeze, that'll give us 8 weeks to hammer out 19 failures or ~2.4 a week. ~Josh
Re: Updating our Code Contribution/Style Guide
> It looks like the doc already specified this behaviour for ternary > operator line wrapping. For your proposal I’ve also added the following: > > > > It is usually preferable to carry the operator for multiline expressions, > with the exception of some multiline string literals. > > > > Does that work for you? The “usually” at least leaves some wiggle room, as > ultimately I would prefer this decision to be made by an author (even if a > general norm of carrying the operator is preferable). > > > > I am concerned that this starts leaning towards being too specific, > though. It opens up questions like whether we should also be specifying > spacing for loop guards, conditions, casts, etc? > > Yes I'm good with that, thanks.
