Main topics

0.14 RC1 release

Coding style

0.14 RC1 release

background

Bitcoin Core 0.14 is scheduled to be released around March 2017. Open pull request aimed for 0.14 are tagged with a 0.14 tag.

RC1 is aimed to be released on 2017-02-06.

BlueMatt thinks #9671 (Fix super-unlikely race) is going to be required for release.

Issue #9027 (Unbounded reorg memory usage) should be pushed to 0.15 as it’s not a regression. It’s slightly worse than it used to be, but not enough that we definitely need to fix it asap.

The importmulti changes can be done after 0.14 or can be disabled for release if it isn’t safe enough in time. It could also be left undocumented, however that would require issue #9491 (Importmulti API is confusing in a way that could lead to funds loss) to be fixed.

meeting conclusion

Discuss the importmulti issue on the issue itself (#9491)

Coding style

background

Stylistic consistency in the code has some benefits:

it aids newcomers in their contributions because it is easier for them to make sure their work is okay on styleistic grounds.

It eases review because the uniformity creates better expectations, however reformating makes looking at the history harder, which harms review.

Good style choices have, at times, been shown to lower defect rates in software, but there is not a universal opinion on what choices are good.

Since C++11 it’s possible to use an “auto” specifier. It specifies that the type of the variable being declared will automatically be deducted from its initializer.

BlueMatt thinks the use of ‘auto’ makes certain review much harder as he often searches for “everywhere X is used”. Sipa proposes a workaround for this by introducing an incompatible change to the type and recompile so all the places it is used become visible. The discussion started here.

Wumpus advises to document specific cases where the use of ‘auto’ is bad or dangerous.

The advantages of using auto, besides where it replaces a lot text to type, is that you don’t need to change things all over the place when you turn a tuple into a struct or add a wrapper.

Gmaxwell adds another negative side is that auto enables you to write code that acts on a type while having no idea of the type yourself, which is safe 99% of the time and dealy the rest, as in C++ not all operations which are categorically unsafe on a type are actually stopped by typechecking. Although an edge case, it’s something to keep in mind.

Auto is interesting when you have some horrible complex signature, however those are the cases where it’s also more of an issue. Sipa notes best practice for those usecases is to introduce a typedef for it, which also lacks the review concerns from BlueMatt.

meeting conclusion

consider the use of ‘auto’ case by case.

Comic relief

wumpus #startmeeting BlueMatt oh thats today? luke-jr BlueMatt: no, it's fake news. wumpus BlueMatt: it's thursday I hope? sipa luke-jr: alternative news BlueMatt wumpus: alternative facts wumpus foremost topic would be what to still include in 0.14, as rc1 release is planned for monday gmaxwell I propose not including any bugs. wumpus no other topics? wumpus I had expected heated debates on what to include last-minute in 0.14 and why to delay the rc, what a disappointment! </s> BlueMatt wumpus: I vote we push it back a month so we can do all the things we wanted to a month ago :p BlueMatt wait, i had something to talk about re: cde style gmaxwell BlueMatt: die sdaftuar i'll get the baseball bat wumpus gmaxwell: it's *easy* but the point is to avoid unnecessary verbosity/typing, not so you can forget the type BlueMatt wumpus: I'm generally 100% in favor of extra verbosity gmaxwell fking java programmers. :P wumpus BlueMatt: go use java BlueMatt lol, i expected that.... wumpus #endmeeting gmaxwell wumpus: your request is a little explicit, you could have just said... for auto meetingstep.

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.