< bitcoin-git>
[bitcoin] theStack opened pull request #18940: miner: fix off-by-ones in BlockAssembler::TestPackage (master...20200511-miner-fix-off-by-one-in-test-package) https://github.com/bitcoin/bitcoin/pull/18940
< yevaud>
fanquake: I'd suggest someone well known reaches out to them, and amitiuttarwar is removed from the repo.
< yevaud>
there's really no place for someone being told to stop contributing.
< phantomcircuit>
have to agree
< sipa>
i don't interpret it that way; just as an encouragement to focus on more things than just "good first issue" tagged ones
< luke-jr>
yevaud: that's going too far… let's just make it clear we don't agree with that attitude?
< yevaud>
luke-jr: perhaps. objectively the project has lost one of the very few people who have turned up and are prepared to review.
< luke-jr>
yevaud: hopefully he will reconsider when he learns it was just one guy
< luke-jr>
I still wonder to date what happened to Diapolo :/
< phantomcircuit>
is the IsMineInner function still being used?
< sipa>
phantomcircuit: in legacy wallets yes
< bitcoin-git>
[bitcoin] andrewtoth closed pull request #18936: validation: Persist coins cache to disk and load on startup (master...persist-coinscache) https://github.com/bitcoin/bitcoin/pull/18936
< phantomcircuit>
sipa, it's not feasible to generate a list of scriptpubkeys for a LegacyScriptPubKeyMan is it
< sipa>
phantomcircuit: it's possible but nontrivial; for all privkeys you need P2PK, P2PKH, P2WPKH, P2SH-P2WPKH versions of it; and then add all known scripts and watch-only scripts, and filter the whole list with IsMine
< sipa>
i wrote code for that once, not sure where it is
< sipa>
also P2SH and P2WSH versions of all scripts, presumably
< phantomcircuit>
sipa, the one i got kind of stuck (thinking about not doing) is the original multisig support
< phantomcircuit>
cause we don't know the other keys in advance
< sipa>
oh if you support raw multisig it's nontractible (cubic in the number of keys...)
< phantomcircuit>
sipa, yeah ok thanks
< bitcoin-git>
[bitcoin] andrewtoth opened pull request #18941: validation: Persist coins cache to disk and load on startup (master...persist-coinscache) https://github.com/bitcoin/bitcoin/pull/18941
< bitcoin-git>
[bitcoin] fanquake opened pull request #18942: doc: Increase minimum required GCC to 5.1 (master...gcc_5_1_for_codecvt) https://github.com/bitcoin/bitcoin/pull/18942
< wumpus>
FWIW I completely agree with amit
< wumpus>
she's not telling to stop contributing, just that at some point you might want to move on from 'good first issues' and give new users a chance at them
< wumpus>
it definitely wasn't worded in a mean or harmful way
< wumpus>
that brakmic interpreted it the wrong way sucks though, but, calling for "removing people from the repository" for this really goes too far
< wumpus>
please leave the project yourself if you want things to work that way
< wumpus>
I really want to push forward with 0.20.0 so I'm going to triage things labeled 0.20.0 somewhat more strictly
< jonatack>
I passed a similar message to brakmic a couple of weeks ago by private IRC discussion. It went very well and he came out of it with a noticeable commitment to reviewing other contributors' work, where he was seeing new opportunities to contribute off the beaten path. I reckon one further private discussion would have resolved this completely and wish I had done that.
< fjahr>
That's a great approach jonatack
< fjahr>
Amiti's intentions were only positive, absolutely, and removing her from the repo is out of the question. But I have to say I can also feel for brakmic that this must have been demoralizing because he did other things like reviews as jon said and most of his "good first issue" PRs were ~6 months old. If nobody took them by then I think it's fair to assume that maybe they were not so beginner friendly? Amiti's
< fjahr>
post also got a lot of positive reactions, so he must have felt isolated at that moment.
< fjahr>
I think more or less what Marco said in the issue: If beginners think there are not enough "good first issue" issues then we just need to create more. It's not like there is a lack of opportunities in the codebase, beginners just need guidance to find them. I also think we should encourage reviewing more as a way to get started. Traditionally reviewing tickets is more a "senior dev" thing and so many beginners
< fjahr>
seem to think they need to get something merged first before they can be a reviewer. We can see it in the review club too: people say they reviewed the PR and can participate in the discussion, yet don't seem to have the courage to give a Concept ACK.
< wumpus>
I think it's good to reach out to brakmic in any case
< wumpus>
I very much understand how stressful it is to do PRs to bitcoin core in the first place, and this was probably the last straw for him
< bitcoin-git>
[bitcoin] laanwj opened pull request #18945: build: Ensure source tarball has leading directory name (0.20...2020_11_0.20_tarball_prefix) https://github.com/bitcoin/bitcoin/pull/18945
< instagibbs>
She knows full well how it is to be a new contributor, I'm certain it's miscommunication. Let's be extra sensitive to newcomers!
< wumpus>
agreed
< jonatack>
reached out via keybase
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18946: rpcwallet: Replace boost::optional<T>::emplace with simple assignment of T{} (master...2005-rpcWalletOptional) https://github.com/bitcoin/bitcoin/pull/18946
< theStack>
Talking from the perspective of someone who also started contributing to core not too long ago, I can confirm that in the very beginning
< theStack>
1) it can be quite frustrating to repeatedly see that an new interesting looking "good first issue" is taken fast; those are really
< theStack>
_awesome_ onboarding instruments, and it kind of feels disappointing and is against its basic idea of educating if they are tackled
< theStack>
by people which are already way more advanced (not talking about the many months old ones issues here though)
< theStack>
2) there is a strong mindset of "i have to contribute first before i do anything else", as one might feel the need to
< theStack>
first get some reputation, as otherwise one may isn't taken seriously; that's why maybe even more people were kind of
< theStack>
waiting for new "good first issues" (there is even a twitter bot for it!) and Amiti's post did get so many thumbs up.
< theStack>
I think that this was in no way meant rude by Amiti. I'd even go so far and say it can be seen as a compliment,
< theStack>
like "you have advanced to a level where good first issues are too easy for you".
< theStack>
I'm glad to see how fast the reactions were and how everyone tries to clear the issue. A sign for a strong
< theStack>
community actually. Of course, I also hope brakmic comes back soon.
< provoostenator>
I must say I never picked a "good first issue" when I started out. Not saying that was smart of me, but just to add a data point.
< provoostenator>
I just picked something that bothered me and apparently didn't bother anyone else enough to deal with it first :-)
< provoostenator>
But my first PR took several months to get merged, so...
< wumpus>
thanks for weighing in; I think having contributed *something* is good before starting to review, unless you can somehow start reviewing at a deep technical level without having written any code for bitcoin core (e.g. contributor to a similar or adjacent project), but that's rare
< wumpus>
though it's always 'taken seriously' if you point out problems in review, to be clear
< bitcoin-git>
[bitcoin] hebasto opened pull request #18948: qt: Do not call setParent() for WalletModel instances (master...200511-qt-assert) https://github.com/bitcoin/bitcoin/pull/18948
< provoostenator>
When I'm unfamiliar with the code during a review, the first thing I try is to break stuff. Then I can report that, and feel like I at least got something useful done.
< provoostenator>
Though if you're very new to the project you may just find an existing bug, so it's important to compare to master.
< theStack>
provoostenator: for me personally grep-ing for TODOs was quite a good strategy, besides of 'good first issues'
< theStack>
wumpus: definitely agree to both of your points; there are also very good beginners resources out there (e.g. by jimmy song, jonatack, amiti...) that make clear how important reviewing is and that every opinion is considered worthy
< jonatack>
thanks theStack. this is in no way directed at you or anyone, but i feel the phrase itself "i have to contribute first before i do anything else" reveals something.
< wumpus>
the only possible situation I can imagine where someone is not taken seriously is when a new person starts commenting on things like source organization or aggressively pushing their code style preferences
< jonatack>
the definition of "contribute" itself does not necessarily mean opening PRs
< jonatack>
yet for a majority of new contributors it seems to be seen as exactly that: opening PRs
< jonatack>
when one enters a new project repo (this one or another) and sees *hundreds* of open issues and PRs
< jonatack>
it may be a bit ironic that the reflex is "i need to open PRs here!" ... idk how to improve this but am working on it
< jonatack>
it's not easy to strike a good balance
< luke-jr>
reviewing is one of the best ways to start contributing
< luke-jr>
not only are we bottlenecked on review, it helps you learn the code, expectations, etc
< luke-jr>
(another good way is to write tests, but test-writing isn't a skill everyone has)
< theStack>
jonatack: yes, mostly people tend to equate "contributing" only to "opening a PR"; the longer i am here the more i think that the most important contribution is actually reviewing
< jonatack>
:love: :D
< jonatack>
the challenge for me is to get faster at reviewing; all those PRs needing love are a bottleneck, so i don't allocate time to coding... < 5%, certainly... not sure what to do except get faster at reviewing.
< jonatack>
luke-jr: +1
< luke-jr>
MarcoFalke_2: I doubt we'll see the end of boost any time soon… There's no C++ standard alternative to Boost::Process in any version, right?
< jonatack>
(but can't become complacent about reviewing either, or a vulnerability gets through)
< luke-jr>
I've seen quite a few serious issues get through recently, but I don't want to scare off reviewing/merging either :/
< jonatack>
yes, this is a fundamental tension
< yevaud>
reviewing almost always has no real "output", which is obviously offputting.
< luke-jr>
<MarcoFalke_2> luke-jr: At least we can drop the majority of boost. Keeping one or two boost modules might be fine.
< luke-jr>
(he can't speak)
< sipa>
i feel the most rewarding output of review is when both author and reviewer agree that the PR is in a better state due to the reviewers' comments
< instagibbs>
reviewing can be more of a fine art than throwing a PR out there
< instagibbs>
need to know when to when not to nit, etc
< aj>
what, why are my ears burning?
< jonatack>
i see the whole project as a garden or farm... we are gardeners/farmers... the releases are the seasonal harvest
< jonatack>
aj: nah, it was for me :)
< instagibbs>
a seasoned PR writer knows when to ignore and let ACKs stack :P
< aj>
don't stack sats, stack ACKs
< sipa>
stACKs
< bitcoin-git>
[bitcoin] adamjonas opened pull request #18949: doc: Add CODEOWNERS file to automatically nominate PR reviewers (master...2020-5-add-codeowners) https://github.com/bitcoin/bitcoin/pull/18949
< MarcoFalke>
test
< sipa>
fail
< MarcoFalke>
[11:37] [435] MarcoFalke_2 MarcoFalke #bitcoin-core-dev Cannot change nickname while banned/quieted on channel
< phantomcircuit>
gwillen, the way we use bdb is already comically paranoid, iirc every operation results in a complete flush
< MarcoFalke>
[22:09] <luke-jr> [23:47:07] <sipa> MarcoFalke: i don't think issues should be closed because nobody is working on them <-- indeed, some look like "good first issue" material
< MarcoFalke>
Just saw this and I think if someone proposed a gui improvement in 2016 or 2014, and no one has been working on it since, it should be fine to close
< MarcoFalke>
We can't keep every feature request open indef
< MarcoFalke>
For bugs that are reproducible, maybe yes, but for improvements we need to cut them off at some point
< MarcoFalke>
Btw ajonas has been helping me go through all issues. So I might do a second run to pick up those that qualify as "good first issues"
< sipa>
MarcoFalke: if there was a better way to classify/keep track of issues, maybe there wouldn't be as much a desire to keep the issue list clean
< sipa>
i agree with the sentiment; i think many issues are opened once, and then pretty much never looked at... making it useless and cluttering to keep them open
< aj>
i thought the recent issue cleanups were good
< MarcoFalke>
A few of the issues had been fixed long ago, but no one noticed. So I am thinkging that no one is wading through the issues in either case, so I wonder if closing them makes a difference at all
< MarcoFalke>
They can still be searched through and commented on
< aj>
it's good to have IDEAS pages and stuff (like gmaxwell's wiki things) but they don't need to be issues?
< MarcoFalke>
Sometimes it is good to create an issue to have an URL to point to when the topic comes up again. This is harder to to with IRC threads
< jb55>
if we had encouraged more people to use codetriage it might help with the issue backlog. I'm not a fan of autoclosing personally.
< luke-jr>
MarcoFalke: I was thinking more of getting rid of the univalue fork
< MarcoFalke>
The decision to close issues is subjective. When an issue has already been solved, or partially solved, but stale for a long time, or I haven't seen a way that something is going to be addressed any time soon or ever, I closed it.
< MarcoFalke>
jb55: How is "codetriage" different from "good first issue" (the tag)?
< jb55>
MarcoFalke: its tangentially related. I was just commenting on the growing backlog issue. you can subscribe and it sends periodic emails for stale issues to triage. the more people doing it the better.
< jb55>
usually along the lines of "hey, whats the status of this?" "can this be closed" from there perhaps users can triage old issues into "good first issues".
< gwillen>
phantomcircuit: that makes sense and I'm really glad to hear it
< sipa>
our bdb code went through several random mutations as long as problem reports were frequent
< sipa>
and then stopped mutating once those problems went away... so we probably ended up in a very stable (but possible overly caution) way of using it
< gwillen>
that doesn't necessarily seem like a reliable way to get correct behavior
< gwillen>
but it's a reliable way to get almost-always-correct behavior I guess :-)
< sipa>
yes, it's why i don't want to touch bdb with a ten-foot pole
< sipa>
maybe an 11-foot pole is ok, though
< gwillen>
hahaha
< gwillen>
I think many things work better if you fsync() constantly
< gwillen>
but it makes them very slow
< jb55>
so we're replacing it with sqlite right :D
< sipa>
i think it's worth considering
< cfields>
gwillen: which is why macOS's fsync doesn't really fully sync. Flushing is annoyingly platform-specific :\
< theStack>
we are 3 blocks away from the halving <3
< lightningbot>
reardencode: Error: "AntPool!" is not a valid command.
< gribble>
Error: "!" is not a valid command.
< * owowo>
waits for the doubling of price, any moment now
< owowo>
ok, history made, good night, l0ve you all :)
< CubicEarth>
Just 209,999 more blocks to go until the havening!
< CubicEarth>
3.125 - here we come!
< theStack>
the yearly inflation rate has now lowered to <1,8% (if i'm calculating correctly)
< amiti>
hey all, I read through the message history of the last ~day and I’d like to share some thoughts
< amiti>
I feel really sad that I created feelings of an unwelcoming environment for brakmic. That was exactly the opposite of my intent. I was trying to help create space for even more people to ramp up onto the project, but clearly that wasn’t the message that came across and that really sucks. In no way did I intend to discourage him.
< amiti>
I was actually working on a follow up comment to try to brainstorm some good places to search for more work (like looking at up-for-grabs closed issues), but was taken off guard by his response, and spent the rest of the day away from the keyboard. Obviously I’m pretty new around here myself, and oof, good communication is much harder than C++
< amiti>
I wrote some explanation on the issue trying to share where I was coming from. I’m going to repeat some of it here, and share a bit more..
< amiti>
I feel deeply grateful to get to work on bitcoin core on a daily basis. I 100% do not think I would be here if it weren’t for the many of you who have believed in me & taught me so much, even when I doubt myself. I’ve found the bitcoin core community to be welcoming & supportive, and I wish to share that with others who feel intimidated but interested
< amiti>
Several people have been reaching out to me lately about trying to figure out how to onboard, probably because of the different outreach stuff I’ve been doing. Some new contributors drew my attention to this pattern, leading to me leaving the comment. I figured most people who are contributing to the project don’t realize that there are people lurking and searching for an issue to tackle, so I was trying to
< amiti>
share that perspective and make a request. I really didn’t realize my comment could come off so negatively.
< amiti>
In terms of onboarding newcomers, I agree that review is super important, and also that it’s really hard. One barrier to this for newcomers is they see a huge backlog and they don’t know where to start. So something I’ve started doing is choosing test PRs and trying to directly hand them out. Maybe a possible idea here is to create a similar label along the lines of “good first review”.
< amiti>
And another thing that’s becoming more apparent to me is that even after the first issues & first reviews, it can also be tricky to figure out what’s next. I know many people feel like too-much-to-do-too-little-time, but on the other hand there are people looking for work that’s within their skillset and would be helpful. I wonder how we as a community could help better match these together.
< amiti>
This whole interaction has really surprised me with how it’s played out. The nice part of it has been seeing in action how much you all care about creating a supportive environment.
< amiti>
I’m learning a lot and I appreciate your patience with me along the way. Its an honor to work with you all on bitcoin core <3
< jb55>
it's all good sounds like it was just some miscommunication
< sipa>
amiti: communication is hard
< Pavlenex>
Hey. Who's in charge of Transifex? Translated 0.20 in Serbian from scratch but there's no moderator for the language, so it can't be reviewed. Can anybody provide me with a reviewer access so we can proceed? Thanks.
< bitcoin-git>
[bitcoin] andrewtoth closed pull request #18941: validation: Persist coins cache to disk and load on startup (master...persist-coinscache) https://github.com/bitcoin/bitcoin/pull/18941
< gleb>
I was very happy to find "bitpeers" today, the go tool which parses peers.dat in various ways. Not sure people here are aware of it, just wanted to share :)