IRC meeting summary for 2017-02-02

• Link to this week logs
• Meeting minutes by meetbot

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.

meeting comments

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.

meeting comments

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.