< Luke-Jr> berndj: and if different programs we use use different Python versions?
< Luke-Jr> the language used by external programs really ought to be transparent to us
< Luke-Jr> opaque*
< Luke-Jr> hmm
< Luke-Jr> approaching this the wrong way I think
< Luke-Jr> PYTHONPATH should probably be treated like PATH, which isn't overridden in Makefile at all
< maaku> #7230 is locked with conversation limited to contributors only
< maaku> that's effectively useless given how bitcoin development works...
< maaku> would recommend closing if it is too contentious to oeprate effectively as a PR
< jgarzik> maaku, unlocked. Hopefully vote brigading will not continue.
< Luke-Jr> it would be nice if there was a good migration path to a decentralised development environment :/
< jgarzik> Luke-Jr, you mean off-github?
< Luke-Jr> jgarzik: well, GitHub could probably easily get a better permissions system; more problematic IMO is the concept of rebasing
< Luke-Jr> at least as it works with git, it makes decentralised development basically impossible
< Luke-Jr> since every rebase conflicts with the previous incarnation
< jgarzik> Luke-Jr, in an ideal world rebasing is evil, and git merge should be used instead
< Luke-Jr> O.o
< Luke-Jr> jgarzik: more or less agree; but I don't know an easy way to get to the point where PRs aren't being rebased anymore
< jgarzik> Luke-Jr, (reconnecting) You've rediscovered what Linus tells people every week --
< jgarzik> Luke-Jr, rebasing is evil, and git merge should be used instead. It is more decentralized.
< Luke-Jr> intereting, didn't know he also held such a position
< Luke-Jr> git seemed IMO to encourage rebasing because of git-log's defaults
< jgarzik> git merge is designed for decoupled development, where trees and code and developers (obviously!) move in parallel, at different rates.
< Luke-Jr> contrast with Bazaar, which basically defaults to --first-parent and treats the merge commit message as a summary of all under it
< jgarzik> Luke-Jr, rebasing screws anyone following a tree
< jgarzik> Luke-Jr, if you rebase, in kernel development, you get flamed by Linus for anti-social (anti-dev) behavior :)
< Luke-Jr> jgarzik: well, you have my vote for not asking people to rebase/squash on PRs ;)
< Luke-Jr> would be a nice surprise to find out we all hate rebasing, and were just going along with it to fit in with the norm :P
< jgarzik> Luke-Jr, the main problem on the flip side is devs obsessively git-merge'ing upstream into the current branch
< Luke-Jr> a ready-to-pull-please-merge ACK might work well, provides the merge+pull are timely so they don't overlap with other merge+pulls.
< Luke-Jr> (or alternatively, committers could do the merge themselves, but that might increase their workload and require more)
< jgarzik> Luke-Jr, Yes, correct -- the developer's job is making a PR "merge ready" -- meaning the committer doesn't have a lot of work do during the merge. On the developer side, for long-lived PRs, that means "push a periodic git-merge as upstream tree changes dictate, to maintain the low burden on the committer"
< jgarzik> tl;dr if upstream shit breaks your shit, fix your shit, otherwise leave it
< Luke-Jr> jgarzik: sure; those can be minimised by only doing it when upstream changes *significantly* or when it's ready for pulling
< jgarzik> Luke-Jr, right
< midnightmagic> the real problem is that a scrupulously maintained merge branch can still diverge.
< midnightmagic> not all scm have that problem.
< Luke-Jr> midnightmagic: ?
< midnightmagic> a git merge doesn't always follow refactoring so well; and certainly many forms of git activity simply can't be merged cleanly at all with the native git merge tools. the base-finding mechs for three-way merge are rudimentary and primitive, if they exist at all, and there's no memory of merge credits for past-considered changes.
< GitHub4> [bitcoin] dgenr8 opened pull request #7236: Use createrawtx locktime parm in txn_clone (master...use_rpc_locktime_clone) https://github.com/bitcoin/bitcoin/pull/7236