< wumpus>
emilengler_: in general, only open a PR for master then request it to be backported to the old branch (and that will be done when it makes sense), however if the patch doesn't merge cleanly (esp if it is significantly) it's helpful to open a PR against the older branch too
< wumpus>
significantly different*
< wumpus>
DrahtBot does kind of go over the top a bit in adding labels :) I think the approach should be to pick the labels most relevant to an issue, not add an label for every touched source file
< wumpus>
we have two PRs improving the linearize script (#16802, #16431), both are waiting on trivial actions (squashing, commit message changes) from the author, if someone cares about these kind of changes please pick them up
< gribble>
https://github.com/bitcoin/bitcoin/issues/16802 | scripts: In linearize, search for next position of magic bytes rather than fail by takinbo · Pull Request #16802 · bitcoin/bitcoin · GitHub
< bitcoin-git>
bitcoin/master addaf8a Jonas Schnelli: make sure to update the UI when deleting a transaction
< bitcoin-git>
bitcoin/master 8d39c63 Wladimir J. van der Laan: Merge #16952: gui: make sure to update the UI when deleting a transaction
< bitcoin-git>
[bitcoin] laanwj merged pull request #16952: gui: make sure to update the UI when deleting a transaction (master...2019/09/fix_zap_ui) https://github.com/bitcoin/bitcoin/pull/16952
< bitcoin-git>
bitcoin/0.19 57eb126 Wladimir J. van der Laan: build: Bump version to 0.19.0
< wumpus>
if no one complains in the next hours I'm going to label 0.17.2rc2 as 0.17.2 final, I would prefer not to have two rc cycles going on at once
< luke-jr>
has it been tested by anyone much?
< wumpus>
I have no idea
< luke-jr>
that's been a problem in the past: too few confrimed testers of RCs
< luke-jr>
(which leaves them as RCs, never final)
< wumpus>
the people using old releases are very silent, generally
< wumpus>
even more silent than the average normal bitcoin user
< wumpus>
that there's no feedback doesn't really say much
< luke-jr>
well, I don't know why we'd suddenyl start tagging finals without confirmed feedback
< wumpus>
there's no *negative* feedback
< wumpus>
generally if there are no reported issues we tag the rc as final
< luke-jr>
only when there's indication people have in fact used it :/
< wumpus>
I'm also ok with abandoning the release, but I"m not going to continue working on a 0.17 release while 0.19 is in progress
< MarcoFalke>
I think tagging as final is ok
< wumpus>
FWIW I'm getting a bit tired of this, it's always the same discussion with back-releases
< instagibbs>
What's the risk profile for the back release? In general they are very easy to back out of, and the sets of changes are quite limited...
< wumpus>
yes
< instagibbs>
that's a vote for keeping backports super minimal
< wumpus>
there's usually only very few changes, mosttrivial backports which have already been tested on other branches
< instagibbs>
right
< instagibbs>
Would it help if I ran minor releases we don't plan on using in production through our internal integration tests at least
< wumpus>
and I"m okay with that, I'm just tired of always having the same response to these kind of things
< instagibbs>
(we meaning blockstream)
< wumpus>
sure, proposals to help testing are very welcome :)
< MarcoFalke>
instagibbs: That helps
< instagibbs>
Ok that's a low energy thing I can do to exercise a lot of state/RPC/config stuff
< instagibbs>
(provided we haven't ratcheted versions since then, I'd have to check)
< MarcoFalke>
wumpus: let me know when master is clear for merging :)
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #17022: doc: move-only: Steps for "before major release branch-off" (master...1909-docReleaseProcess) https://github.com/bitcoin/bitcoin/pull/17022
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #17022: doc: move-only: Steps for "before major release branch-off" (master...1909-docReleaseProcess) https://github.com/bitcoin/bitcoin/pull/17022
< bitcoin-git>
bitcoin/master 1111170 MarcoFalke: test: mempool entry time is persisted
< bitcoin-git>
bitcoin/master faaa1f0 MarcoFalke: util: Add count_seconds time helper
< bitcoin-git>
bitcoin/master faec689 MarcoFalke: txmempool: Make entry time type-safe (std::chrono)
< bitcoin-git>
[bitcoin] laanwj merged pull request #16908: txmempool: Make entry time type-safe (std::chrono) (master...1909-mempoolEntryChrono) https://github.com/bitcoin/bitcoin/pull/16908
< bitcoin-git>
[bitcoin] Sjors opened pull request #17023: doc: warn that ranged multi() descriptors are not BIP67 compatible (master...2019/10/doc_descriptor_bip67_warning) https://github.com/bitcoin/bitcoin/pull/17023
< bitcoin-git>
[bitcoin] andrewtoth opened pull request #17028: [rpc] Include immature coinbase in listunspent (master...listunspent-immature) https://github.com/bitcoin/bitcoin/pull/17028
< bitcoin-git>
[bitcoin] dongcarl opened pull request #17029: gitian: Various improvements for Windows descriptor (master...2019-10-gitian-win-improvements) https://github.com/bitcoin/bitcoin/pull/17029
< bitcoin-git>
[bitcoin] jbampton opened pull request #17030: Fix Python Docstring to include all Args. (master...fix-python-docstring) https://github.com/bitcoin/bitcoin/pull/17030
< achow101>
oh huh. so Cocoa is recognizing the URI and emitting a signal for it?
< promag>
I think that's the Cocoa way, openFiles is called for command line arguments and dropped stuff on the app (via finder)
< promag>
Qt is catching that and checking if it comes from the command line or not
< promag>
with your change, Qt thinks it's a drag&drop'ed file via Finder
< promag>
or some other open action
< promag>
either way, what should `bitcoin-qt -regtest "bitcoin:bcrt1qu7nl0nxfqwhrrf6v0t60asvq3dympgqdhg03rn?amount=0.00010000" "bitcoin:bcrt1qu7nl0nxfqwhrrf6v0t60asvq3dympgqdhg03rn?amount=0.00010000"` do?
< promag>
also, jonasschnelli, any idea as to why you couldn't reproduce the issue?
< promag>
jonasschnelli: using qt 5.12.2 and testing commit f4a0d27e85