< GitHub61>
bitcoin/master 4dc94d1 Alex Morcos: Refactor CreateNewBlock to be a method of the BlockAssembler class
< GitHub61>
bitcoin/master a278764 Alex Morcos: FIX: Account for txs already added to block in addPriorityTxs
< GitHub61>
bitcoin/master c2dd5a3 Alex Morcos: FIX: correctly measure size of priority block
< GitHub4>
[bitcoin] laanwj closed pull request #7598: Refactor CreateNewBlock to be a method of the BlockAssembler class (master...BlockAssembler) https://github.com/bitcoin/bitcoin/pull/7598
< btcdrak>
nice feature from Github! though isnt some of the problem also about getting enough review on patches to older branches?
< wumpus>
well possibly, I mean that's up to the three people that actually use old releases
< wumpus>
:<
< btcdrak>
even for a maintained branch like 0.11, there isnt sufficient interest in backporting CSV despite the backport being done (and subsequently closed).
< * btcdrak>
giggles
< wumpus>
well the developers working on master have no time or interest to maintain them, but if luke-jr wants to pick up that task that's ok with me
< wumpus>
I wonder if this also means that if we give someone write access to the repository, but no push access to any branch, they can only open/close/edit issues and PRs but not the code
< wumpus>
fanquake may still be interested in that
< fanquake>
wumpus sorry I think I've missed something here. Interested in what?
< wumpus>
<wumpus> I wonder if this also means that if we give someone write access to the repository, but no push access to any branch, they can only open/close/edit issues and PRs but not the code
< sipa>
(this is in a branch with 7749 merged, but i don't think that's related)
< sipa>
5 out of 16 runs
< fanquake>
I'll run through a few more times, but I've got 9/9 passing.
< fanquake>
(just master)
< sipa>
trying to bisect
< sipa>
i'm seeing the problem as early as 761cddb
< wumpus>
you do throw away the cache between runs?
< sipa>
the cache is only used when running from rpc-tests, right, not when calling the test individually?
< wumpus>
oh, never knew that
< sipa>
if you're not sure about it, i better check
< sipa>
but the cache is inside the pull-tester directory
< wumpus>
I assumed the cache would always be used, if there is a cache directory in your current path
< wumpus>
I tend to have cache directories all over the place because I call the tests from different places :p
< sdaftuar>
i believe wumpus is right; at least it used to be that the cache would always be used if found, or created if not found (ie if you ran from a different place)
< sdaftuar>
but... is it failing in the sync itself?
< sdaftuar>
or with the same error as before?
< sipa>
same error as before
< sipa>
including a generate: success
< sdaftuar>
ok that's good to hear at least.
< sdaftuar>
the conjecture was that earlier invocations to fundrawtransaction selected coins needed for the failing test... so mining those transactions makes more inputs available
< MarcoFalke>
When the bip32 stuff is merged, we should make sure the test framework still runs the legacy wallet sometimes
< luke-jr>
[11:16:13] <wumpus> I wonder if this also means that if we give someone write access to the repository, but no push access to any branch, they can only open/close/edit issues and PRs but not the code <-- that would be handy
< luke-jr>
btcdrak: stable branches virtually never get enough testing for a release, but it's sometimes possible to do it as a branch with the "not well-tested" caveat